Stuff to finish before release

el_matarife · Post by **el_matarife** » 10 May 2007, 02:26

LuaUI at least should be in a state where it can be turned on by default. You should probably also ship it with a couple more scripts, maybe by adding some of the 3rd party ones to SVN with permission.

Also, I'd hope that new map could be in an SM3 format. Will SM3 be beta still, or ready for mass use?

A few other Lua demos should be included, like a single player map or something like that. Anything that could kickstart a bit of a development community around the Lua capabilities through examples that demonstrate the power available or help people learn would be great.

Critical Mantis entries:
529 UnitRestricted can be circumvented
http://spring.clan-sy.com/mantis/view.php?id=529
443: canassist=0 can be circumvented
http://spring.clan-sy.com/mantis/view.php?id=443
346: You can hear enemy unit sounds if you are in that area of the map, even if you cannot see the units
http://spring.clan-sy.com/mantis/view.php?id=346
430: F2 crashes the game before a unit has been selected.
http://spring.clan-sy.com/mantis/view.php?id=430
526: Mobile cons can only build at half their range
http://spring.clan-sy.com/mantis/view.php?id=526
Most of these are known exploits, crashes, or bugs. That should be the priority order of fixes too, 1. cheats/exploits 2. reproducible crashes 3. reproducible bugs. Tracking down stuff that's not easily reproducible isn't worth it until we get close to the ship revision since more problems will get introduced or fixed in collateral damage before then.

Changelog hasn't been updated in forever and doesn't have half the new mod capabilities. I'm probably going to pick through the SVN log later and link to revisions that should be in there.

Also, I suggest you set a timeline for the final release date so mod/map makers can have stuff ready for release around the same time to show off the new capabilities. That should probably also include a few weekly releases of test versions.

smoth · Post by **smoth** » 10 May 2007, 02:28

It is a matter of the fact that they are LESS of a threat then the other aircraft who are ON COURSE and eating your base. In gundam 20-30 bombers is a small number so all the turrets firing on an already dead bomb is really bad.

Either way, We are talking about when a unit is dead and doing it's death animation. With a death anim, the aircraft/unit is DEAD ALREADY not firing etc. We are not talking about death spirals. At that point it is not good to be a target

el_matarife wrote:Also, I'd hope that new map could be in an SM3 format. Will SM3 be beta still, or ready for mass use?

I WISH!sm3 in the next version is still bad

Post by **jcnossen** » 10 May 2007, 02:37

springs sm3 is not on my todo list anymore, bored with it and i have other priorities.

smoth · Post by **smoth** » 10 May 2007, 02:45

jcnossen wrote:springs sm3 is not on my todo list anymore, bored with it and i have other priorities.

el_matarife · Post by **el_matarife** » 10 May 2007, 03:22

Okay then scratch SM3 requests off the list. At least this makes it less likely the ship date will slip.

smoth · Post by **smoth** » 10 May 2007, 03:25

matarlife, release dates set in stone are all well and good but you have to remember that these guys are not getting paid for this project. So this project is going to take 2nd priority to any real life things.

el_matarife · Post by **el_matarife** » 10 May 2007, 11:34

Oh no, you misunderstand. It's not a "I REALLY NEED IT RIGHT NOW GIVE IT TO ME YOU LAZY BASTARDS" issue like I'm some whiny internet guy. What I'm saying is that there should be a release schedule, so mod makers like you and others can schedule work necessary for releases. It's pretty likely that there will be some balance changes necessary based on bug fixes and other changes. I'm guessing everyone's going to have to do a release, and it'd sure suck for you and others to have a few days without a new version out just because you didn't have a date to shoot for. By coming up with a schedule, even if the dates are just penciled in we can work together a lot better. I'd also suggest beta and final releases on either a Friday or a Sunday, depending on if you think more time spent working on the test release is better (Sunday) or letting others spend more time with the test release is better (Friday). Weekends are probably when most people have the time to spend on this stuff I'd bet. A feature freeze sometime during the testing period might be a decent idea, by only merging bugfixes into the trunk it'll be much less likely there are regressions that aren't caught before they end up a thorn in our side in a non-test release.

smoth · Post by **smoth** » 10 May 2007, 12:28

most of the "mod makers" have a copy of the nightly build matarlife, that allows us to try our "mods" in what may potentially be the next release. :)

Tobi · Post by **Tobi** » 10 May 2007, 13:08

I am working on a better way to test multiplayer with weekly test builds. I consider this a necessary feature to regression-test the new netcode, once finished, because good MP testing was seriously lacking in earlier releases.

My experience with publishing schedules or even ETAs here is that certain people tend to pin you down on it, so I will not do that as of yet. Also, as smoth says, they depend for a large part on (less predictable) RL stuff.

We tried a setup with merging only bugfixes stuff to a release branch a while ago, but that didn't really work out. It took too much manpower and devs/contributor were complaining their trivial but non bugfix patches wouldn't be in the release (where "trivial" was getting a wider and wider definition of course

), which was kinda obvious because the time between start of this feature freeze & release branch and the actual release was too big. But it couldn't really be shorter due to RL stuff & number of regressions/bugs. So at this moment I believe this setup has too much overhead, and I think promoting continuous MP testing of trunk has a (slightly) better chance to reduce overall regression rate.

The way it currently goes (Big features are done as early as possible in trunk and when a release is near it is reduced to small features and bugfixes only.) seems to work fine mostly, and has no/not much overhead. A disadvantage of course is that if you want to start on a big feature/refactor just before the release, you have to wait or use a branch, which may demotivate people, but I haven't really seen that to be a real problem in practice (mostly because I think I can safely say there are only two people who do big features/refactors atm).

smoth · Post by **smoth** » 10 May 2007, 13:21

Tobi, after finals IF I am around outside of what I am already doing... I can try and test a specific build. Is there a certain build # that we should be looking at?

LordMatt · Post by **LordMatt** » 10 May 2007, 19:44

Tobi I'm happy to help test builds for release.

Dragon45 · Post by **Dragon45** » 11 May 2007, 01:18

LordMatt has no life, that's why he volunteers

Btw Tobie:

. I am working on a better way to test multiplayer with weekly test builds.

whats this better way

JC: What needed to be fixed with SM3 anywho? DId it even work?

LordMatt · Post by **LordMatt** » 11 May 2007, 01:48

Dragon45 wrote:LordMatt has no life, that's why he volunteers

Neither does Dragon45, that's why he posts so much.

el_matarife · Post by **el_matarife** » 11 May 2007, 03:56

smoth wrote:most of the "mod makers" have a copy of the nightly build matarlife, that allows us to try our "mods" in what may potentially be the next release.

Nightly builds are decent for some testing, but trying to get 10 or so people to install the same nightly build for multiplayer testing would be a total pain. Weeklies help by providing a platform multiple people have and can pound on for a while, avoiding issues like "hey x feature is broke in x nightly" "oh that was fixed the next day". (Since most people aren't going to bother to spend 10+ minutes every night to grab and set up a new nightly)

Also, I am continually amused by how people call me "matarlife" not only in Vent/Teamspeak but in text and real life too.

Tobi · Post by **Tobi** » 12 May 2007, 12:36

Dragon45 wrote:Btw Tobie:
. I am working on a better way to test multiplayer with weekly test builds.
whats this better way

I'm setting up a lobby server that gets updated with weekly buildbot builds automatically. (ie. fixing up the installer generation code that used to generate installers after every commit and linking it to a lobby server with OFFERFILE functionality, so at update time you get kicked from server and when you reconnect the new build is forced upon you

)

yuritch · Post by **yuritch** » 12 May 2007, 13:30

trepan wrote:The 'isDead' unit parameter could probably be
used instead of doing the floating point comparison.
It also looks like neither method works for units in
the CAirMoveType::AIRCRAFT_CRASHING state.

I've updated my patch in the mantis to use isDead. Also, looks like there is a crashing unit parameter that is TRUE when an aircraft is in crashing state, so my patch now also works for units in that state.

lurker · Post by **lurker** » 14 May 2007, 02:39

yuritch wrote: I've updated my patch in the mantis to use isDead. Also, looks like there is a crashing unit parameter that is TRUE when an aircraft is in crashing state, so my patch now also works for units in that state.

I would think crashing would be best as a badtarget-y thing, rather than notarget, as they can attack and be killed (if I read this thread right).

Caydr · Post by **Caydr** » 14 May 2007, 03:34

Tobi wrote:
Dragon45 wrote:Btw Tobie:
. I am working on a better way to test multiplayer with weekly test builds.
whats this better way
I'm setting up a lobby server that gets updated with weekly buildbot builds automatically. (ie. fixing up the installer generation code that used to generate installers after every commit and linking it to a lobby server with OFFERFILE functionality, so at update time you get kicked from server and when you reconnect the new build is forced upon you )

IMO even monthly updates would be too often. Seriously, a modder (whose work a large number of people may rely on) can't be expected to keep up with changes that are that frequent. You change some random projectile handling... thing.... requires I add two lines to every weapon tdf... well that's fine. But then I get hit by an airplane. Even under ideal circumstances, it would take at least eleven days for me to recover from that, during which time some aspects of AA won't work properly. The world might never recover.

KDR_11k · Post by **KDR_11k** » 14 May 2007, 07:18

Most engine changes are backwards compatible since they're careful to make all tags default to the previous behaviour. Monthly releases wouldn't be monthly breaking and fixing of mods, it'd be monthly new features and you only have to change stuff if you want the new behaviour.

Tobi · Post by **Tobi** » 14 May 2007, 10:13

Caydr wrote:IMO even monthly updates would be too often. Seriously, a modder (whose work a large number of people may rely on) can't be expected to keep up with changes that are that frequent. You change some random projectile handling... thing.... requires I add two lines to every weapon tdf... well that's fine. But then I get hit by an airplane. Even under ideal circumstances, it would take at least eleven days for me to recover from that, during which time some aspects of AA won't work properly. The world might never recover.

You dont need to keep up. The goal of weekly builds which are easily testable because they're linked to a lobby server is to provide (regression) testing of the engine. I'd be happy if at least 1 game is played with it every week, and if regressions found in that game are reported in the bug tracker.

Spring RTS Engine

Stuff to finish before release