Page 2 of 2

Re: New package format for upcoming 0.51.0 release (bye bye pk3)

Posted: Thu Feb 15, 2018 8:37 pm UTC
by illwieckz

It looks like there is some misinterpretation. I'm not saying “I'm going to do that, do you agree ?”, I'm asking for comments and suggestions, to do our best together.

Nothing is decided except one thing: I will do the best of myself to track down any trace of cargo cult or things like that. Let's do a fresh start and a clean one! :smile:

That’s why @tvezet's comment is very useful, that was the kind of thing I was expecting:

The sole reason why i included the beta state in the package name was the fact that it seemed common for Unvanquished maps and i'd like them to be versioned as uniform as possible.

This is exactly the kind of thing I was thinking about: people just doing things because others did it and everyone believe there is a good reason since every other else does it but everyone think they are the lone to not knows that reason and believe every other knows.

Even the 0.1b suggestion I did was a kind of silliness like that. Since tvezet put a letter in his version number I wrongly assumed that he wanted to put a letter in his version number, so to make everyone happy I suggested to put the letter at the end. But we now discover that I made assumptions based on tvezet's assumptions. :bugeyes: It can go crazy if we never stop and take a chair around a table to talk.

So let's avoid nested assumptions as most as we can! :grin:

@Viech I really liked your idea about using r for release, a for alpha, b for beta then d for delta for maps that are ported from Tremulous. That's a very clever thing! But if I'm right the time passed since the first release of Unvanquished is now longer than the time between the release of Tremulous and the first release of Unvanquished, so keeping traces of that tremulous legacy does not make sense so much today. And since we change the package format, we don't have to use version numbers that are greater than the one previously used for tremulous.

I did myself the r thing when I released the tremulous map pack, then I discovered it was just useless to add this r everywhere and serves no one purpose. I myself imitated some other maps that were using r letters and I was doing it without thinking to it. Then I discovered I was just following an unspoken forgotten rule that now looked useless and meaningless. :grin:

Do we really need these letters? Well, it's just what were doing many tremulous mappers, and they were doing like quake3 mappers did, and we just blindly reproduce the same operations since decennials.

Also, there is a big issue with this kind of letters : they are not version numbers, they are labels. Alpha/beta/release are not versions, they are labels to tell the status of the project. They are flags, not version numbers. A project can have a 0.1 version that is labelled as alpha and a 1.0 that is labelled as beta and a 2.3 that is labelled as stable and a 4.0 that is labelled as alpha again or everything possible. And even alpha and beta releases are releases.

This comes to the “release early release often” thing. Alphas and betas are releases too. There is a somewhat toxic habit in mapping (and in most artistic stuff) about the psychological injunction of final things. People just never consider their map as released because of that, they just stick in alpha or beta state just to give them the right to improve their work again. And if sometime something is going to be released as non-beta, people just delay to be sure they miss nothing that must be in a final, and once final is released there is two possibilities : the mapper does not want to make a fix on the final because it would mean it was not final, or people just gave up because of the artificial stress caused by this “final” pressure.

I remember when the final version of thermal was published, I discovered a bug (it was possible to fall in a hole in the map without being able to escape from the hole), I made a nice demo to show off the problem and how to reproduce it but it was too late since the final version was published!

We are not a gaming company from the early 2000th that bought an Id Tech 3 SDK license to make a game for the Xbox that will be pressed to thousands of DVD and shipped into sealed plastic boxes all around the world.

Let's release maps and let's them live their life. In fact we don't really know if they are beta or final at all, we just only know they are the maps in the shape we know today. It's impressive to see how Xonotic guys constantly improve their maps and we have a lot to learn from them. It's very nice to be able to report bugs on a map and see someone of the team fixing it like if it was a bug in software. Perhaps in the next 10 years all our maps will be entirely re-textured again, who knows? So what is a final or even a beta?

By the way, I understand that it's useful to tell if a map is beta or alpha, but it's not a version number but a label. :wink:

And since we can do a clean start, why not using version numbers others software are used to? For example I verified that GitHub automatically extracts 1.0 number from v1.0 tag bug don't extract a0.1 number from va0.1 tag. It's not required to put the alpha/beta label in a version number, but if someone wants or needs it, adding it at the end of the number ensures the label does not conflict with the numbering.

The 0.1b number is just a suggestion to show how it's possible to keep the label while using a numeric version number that can be handled well by third party software (and that can be handled easily by software we wrote). I don't mind if the beta version value is 1.0 or 0.1, I don't mind if people prefers using 1.0b instead of 0.1b the point is not there. In fact I don't mind what's the meaning of i and j in i.j version, I'm just saying it looks really better to start a version number by a numeric character, it's not required but it makes things easier to do things likes that, and everyone can put everything he wants after the number (even more numbers :tongue: ).

I just want to be sure we don't keep legacies without being sure these legacies are really better than something else. I want to be sure things we keep makes sense and makes things easier (basically: makes the writing of tools easier).

If @tvezet just want an nice 1.0 number like in map-hangar28_1.0.dpkdir it's really ok, and since I recompressed his map textures using the newer crunch from Unity to repackage his map I would know what he wants to make him happy. I don't want to know if tvezet agrees on my suggestion, but I'm looking for what he prefers. :wink: With a warning though: it looks like adding the b letter looks to be a remain of the path added there just to do like others do (who did like others did etc). :tongue:


Re: New package format for upcoming 0.51.0 release (bye bye pk3)

Posted: Thu Feb 15, 2018 11:40 pm UTC
by tvezet

By the way, where is the point to use the point in version numbers for maps? If there is none i would rather stick to integer numbers: map-hangar28_1.dpk :smile:


Re: New package format for upcoming 0.51.0 release (bye bye pk3)

Posted: Fri Feb 16, 2018 2:43 am UTC
by illwieckz
tvezet wrote:

By the way, where is the point to use the point in version numbers for maps?

Nice catch! You got it :grin:

If there is none i would rather stick to integer numbers: map-hangar28_1.dpk

This is perfectly fine ;-)

Before/after:

Code: Select all

39M	map-hangar28_b1.pk3
31M	map-hangar28_1.dpk