Joined: 01 Jun 2005, 10:36 Location: The Netherlands
Actually, I do not think *this* weekend is entirely realistic (I only have tonight and sunday to do spring stuff, and I don't think all others magically fix everything before sunday ), but it really should be in xmas holidays.
I would vote at least one more week, not this weekend. We have a lot of new features, most of which... er... have not been really tested thoroughly.
That, and I'm hoping that maybe the new AirTransport movetype stuff might get done before release
Oh... and before release... I can't emphasize this enough... the documentation in the Changelog needs to improve. I have captured a fair amount of the COB changes in my "STANDARD_COMMANDS" file, which is in PURE, but that's not exactly... documentation... just my own FYI...
Changelog is changelog, not huge random order documentation.
Ok... then, um... do we need to have a new document concept for releases? The last three have been so chock-full of new features, I suspect anybody who wasn't watching SVN would be quite overwhelmed. Moreover, certain things in the COB interpreter need more documentation than a one-liner, for example, here's my documentation for GET PLAY_SOUND (one of the more important things in the next release, imo, although it may take people a minute to realize what this means):
Code:
#define PLAY_SOUND 101 //GET only. Plays sounds via these instructions:
/* 1) Adds a new get call, PLAY_SOUND, to play a sound that can be heard only by allies, enemy, in los, etc. 2) changes get health to allow a unit ID to be passed 3) adds a call to create() at the end of ReloadCOB
GET PLAY_SOUND(sound number, volume, who hears the sound, where to play the sound)
To set up sounds to use with GET PLAY_SOUND, put a function like this near the top of your bos: Sounds() { play-sound ("movement", 10); play-sound ("pew", 10); play-sound ("reporting", 10); } The sound number is based on the order the sounds appear, staring from 0. To call the songs by name, add #defines like this: Sounds() { play-sound ("movement", 10); #define movement 0 play-sound ("pew", 10); #define pew 1 play-sound ("reporting", 10); #define reporting 2 }
To actually call the sound, you use a line such as this: GET PLAY_SOUND (pew, 655360);
1) sound number - as above
2) volume - similar to the volume for play-sound, more affecting the distance where it is audible than actual volume - given as a float multiplied by 65536
3) who hears the sound 0 = anyone with the unit in ALOS 1 = anyone with the unit in LOS 2 = anyone with the unit in ALOS or radar 3 = anyone with the unit in LOS or radar 4 = everyone 5 = the unit's allies 6 = the unit's team 7 = the unit's enemies
4) where to play the sound - if 0, the sound is played from the unit's position - if 1, the sound is played directly from the speakers, the same way unit replies are*/
The changelog, however, says nothing about this commit! That kind of thing is a problem. If nothing else, stuff needs to be documented in Changelog.txt before being committed, imo...
Joined: 01 Jun 2005, 10:36 Location: The Netherlands
Multiple structured documents about certain parts of the engine (e.g. COB, LuaUI) would be a better idea yeah.
Quote:
If nothing else, stuff needs to be documented in Changelog.txt before being committed, imo...
I don't see how that makes sense?
Usually you document something around the same time you code it (most people document after coding, or in Spring, don't document at all), so you can as well commit both implementation, documentation and changelog changes at the same time (which is the best we can get I think.)
Tobi what are the specific issues outstanding? This weekend I want to play a bunch of real games with spring SVN (if I can get people to play with me) to find bugs.
Argh, the changelog wasn't updated since that commit (that's the text Lurker wrote BTW, you make it sound like you did). AFAIK Tombom is in charge of that. The commit logs are more up-to-date than the changelog.txt.
I would argue that while we should preferably release with all or most of our bugs gone like we have been doing, we should instead release based on how many bugs there are in comparison to the current stable release.
thus the new release rule would be:
if bugCountSVN < bugcountStable then release
and not
if bugCountSVN == 0 then release
At least that way we have a larger user base to find issues we have more updates and we have a steady level of progress rather than large jumps every 5-6 months followed by 1 or 2 minor fix releases.
Joined: 01 Jun 2005, 10:36 Location: The Netherlands
AF wrote:
I would argue that while we should preferably release with all or most of our bugs gone like we have been doing, we should instead release based on how many bugs there are in comparison to the current stable release.
thus the new release rule would be:
if bugCountSVN < bugcountStable then release
and not
if bugCountSVN == 0 then release
At least that way we have a larger user base to find issues we have more updates and we have a steady level of progress rather than large jumps every 5-6 months followed by 1 or 2 minor fix releases.
That's way to formal, I don't intend to wait till bugCountSVN == 0 but I only intend to wait till majorGameBreakingBugCountSVN == 0, where I personally decide for each bug whether it's major game breaking.
I don't think having released a half broken release earlier is an excuse to release a half broken release again (as your rule suggests). (And yeah I realize it would get better by one bug at least every release due to the < instead of <=)
That said, almost everything is finished.
I've one outstanding patch here that should fix jerkiness, and the only other thing that really needs some love is choose in game start positions. There are reports that suggest in 1v1 with spec as host colors/positions of teams are still borked in choose in game startpos mode.
Blocking one is specs/players that disconnect during load crash the game host, that really should be fixed. Would be very cool if someone could do that tonight
Users browsing this forum: No registered users and 0 guests
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot post attachments in this forum