Spring 87.0! 2nd Run!
- Jonny5isalivetm
- Posts: 186
- Joined: 04 Jul 2006, 02:43
Re: Spring 87.0! 2nd Run!
pathing bit messed up but the reclaim I would say is alot more major
Re: Spring 87.0! 2nd Run!
in the old days of 0.82, we had a different versioning scheme. the difference between 0.81->0.82 and 0.82.1->0.82.2 does not exist anymore (we had 3 different version parts for releases back then, now we have only two). 87.1 would have to be a non-sync breaking release. short: a release that would fix these bugs would be called 88.0 (or something higher then 88 even, as it is allwoed to skip numbers, at least in theory).
Re: Spring 87.0! 2nd Run!
Could be, got another 'not saved settings' occurence on third pc with XP. The other two are with Win 7.varikonniemi wrote:So either this is a spring/windows bug, or just related to your setup.
btw the bug with stuck units could be fixable ... easily.
just make a check for current position and queue of the unit in a given check acumulator size. 5 checks are enough to see that queue is still active but the position x,y is changed with some rly small percent instead of that for the queue. After that stop the unit, move it backwards again with small percent and then send it again with the same queue.
Re: Spring 87.0! 2nd Run!
I still think the old versioning scheme was better... Now every sync breaking release is basically equal, whether it fixes 1 bug, or includes year of coding new features...hoijui wrote:in the old days of 0.82, we had a different versioning scheme. the difference between 0.81->0.82 and 0.82.1->0.82.2 does not exist anymore (we had 3 different version parts for releases back then, now we have only two). 87.1 would have to be a non-sync breaking release. short: a release that would fix these bugs would be called 88.0 (or something higher then 88 even, as it is allwoed to skip numbers, at least in theory).
So we can't have a quick bugfix release for the area reclaim bug, because it breaks sync, so it would require a big release, which means people will keep including stuff in it, and we will all wait, and then the version will be released but not live on the server and we will have to wait even longer...
/rant
I am glad GoogleFrog implemented a workaround gadget in ZK for the area reclaim bug. It was becoming very annoying after several games.
Last edited by Rafal99 on 13 Mar 2012, 14:56, edited 2 times in total.
Re: Spring 87.0! 2nd Run!
what? that makes no sense. fixing the area reclaim bug is sync-breaking, with the old versioning scheme a "full" release would be also required to fix it.Rafal99 wrote: I still think the old versioning scheme was better... Now every sync breaking release is basically equal, whether it fixes 1 bug, or includes year of coding new features...
So we can't have a quick bugfix release for the area reclaim bug, because it breaks sync, so it would require a big release, which means people will keep including stuff in it, and we will all wait, and then the version will be released but not live on the server and we will have to wait even longer...
feel free to create a regression-test-suite + add a test-case for area-reclaim to let it not break in the future again instead of ranting.
Re: Spring 87.0! 2nd Run!
In a gadget:
The second line cause an error in Spring 87.
(It had worked fine for five years.)
The error being:
Error: Lua LoadCode pcall error = 0, LuaRules/main.lua, error = 2, LuaGadgets/gadgets.lua, ERROR_TYPE in WeaponDefs __index
Code: Select all
for id,weaponDef in pairs(WeaponDefs) do
for name,param in weaponDef:pairs() do
end
end
(It had worked fine for five years.)
The error being:
Error: Lua LoadCode pcall error = 0, LuaRules/main.lua, error = 2, LuaGadgets/gadgets.lua, ERROR_TYPE in WeaponDefs __index
Re: Spring 87.0! 2nd Run!
We are obviously taking about different mod, I am talking about balanced annihilation where reclaim is 75% + of your eco. You might talk about 64v64 dsd where reclaim does not matter.klapmongool wrote:I disagree. Rez bug is minor issue in a otherwise great release.albator wrote:Rez bug make BA unplayable. Is it possible to switch server back to 0.85 while it is fix ?
There is a reason why there are only 10 people (included spec) playing BA right now.
So is possible to make server go back to 0.85 or shall we see number of player drop till 0.88 and hope they will come back ?
I know you all done lot of work on that version (and congrats) but imo majors bug issue are more important to the players than huge engine impovment.
-
- Posts: 843
- Joined: 13 Aug 2007, 13:19
Re: Spring 87.0! 2nd Run!
albator wrote:We are obviously taking about different mod, I am talking about balanced annihilation where reclaim is 75% + of your eco. You might talk about 64v64 dsd where reclaim does not matter.klapmongool wrote:I disagree. Rez bug is minor issue in a otherwise great release.albator wrote:Rez bug make BA unplayable. Is it possible to switch server back to 0.85 while it is fix ?
There is a reason why there are only 10 people (included spec) playing BA right now.
So is possible to make server go back to 0.85 or shall we see number of player drop till 0.88 and hope they will come back ?
I know you all done lot of work on that version (and congrats) but imo majors bug issue are more important to the players than huge engine impovment.
I think we are talking about the same game here. As you might have noticed I am one of the most unlikely people to play BADSD1000V1000. Maybe we differ in our estimation of the prioritisation of this issue by the devs. I assumed that this would be on the very top of their list and that a fix would be made ASAP. In the meanwhile the bug forces the player to do a lot more microing of cons and rezzers. Aircons are usefull too :)
So I would agree on reverting to 85 if a fix takes longer than two weeks or so.
Re: Spring 87.0! 2nd Run!
Fixes for constructors were ready even before 87 release was set online. So devs please make release ASAPklapmongool wrote:So I would agree on reverting to 85 if a fix takes longer than two weeks or so.

-
- Posts: 843
- Joined: 13 Aug 2007, 13:19
Re: Spring 87.0! 2nd Run!
Yea, sorry I meant the time needed for the fix to be released :)jamerlan wrote:Fixes for constructors were ready even before 87 release was set online. So devs please make release ASAPklapmongool wrote:So I would agree on reverting to 85 if a fix takes longer than two weeks or so.
Re: Spring 87.0! 2nd Run!
IMHO spending resources for reclaim-units are waaaay too inefficient than simply building groups of 3 generators and metal maker. Loosing focus with reclaiming will eat your frontline in early game, and later this could lead to your fall in spam mini battles.albator wrote: We are obviously taking about different mod, I am talking about balanced annihilation where reclaim is 75% + of your eco. You might talk about 64v64 dsd where reclaim does not matter.
There is a reason why there are only 10 people (included spec) playing BA right now.
So is possible to make server go back to 0.85 or shall we see number of player drop till 0.88 and hope they will come back ?
I know you all done lot of work on that version (and congrats) but imo majors bug issue are more important to the players than huge engine impovment.
Re: Spring 87.0! 2nd Run!
As a quick work-around you can set rez/con to patrol. They will then walk near enough to wrecks to reclaim them. Does not help to rez ofc, but well... it's a work-around :)
Also: I hear that someone (g_f?) made a widget to counter the problem for 0-K... maybe that works for BA too, or can be made to work?
Also: I hear that someone (g_f?) made a widget to counter the problem for 0-K... maybe that works for BA too, or can be made to work?
-
- Posts: 843
- Joined: 13 Aug 2007, 13:19
Re: Spring 87.0! 2nd Run!
Actually a rez/con set to patrol will still stop once the next reclaim target is a bit out of its range.dansan wrote:As a quick work-around you can set rez/con to patrol. They will then walk near enough to wrecks to reclaim them. Does not help to rez ofc, but well... it's a work-around :)
Also: I hear that someone (g_f?) made a widget to counter the problem for 0-K... maybe that works for BA too, or can be made to work?
@100Gbps; lets keep focus on fixing 87 instead of discussing tactics :)
Re: Spring 87.0! 2nd Run!
hmm... right... I guess it worked yesterday bc I used air-cons and their range is bigger (and they circle), so they always got to the next target - just luck :)klapmongool wrote:Actually a rez/con set to patrol will still stop once the next reclaim target is a bit out of its range.
Re: Spring 87.0! 2nd Run!
albator wrote:There is a reason why there are only 10 people (included spec) playing BA right now.
So is possible to make server go back to 0.85 or shall we see number of player drop till 0.88 and hope they will come back ?
I know you all done lot of work on that version (and congrats) but imo majors bug
issue are more important to the players than huge engine impovment.
+1
Re: Spring 87.0! 2nd Run!
BA reclaim range thing: http://springrts.com/phpbb/viewtopic.ph ... 6&p=516931
imo first try to fix the game and only if it is unfixable scream for server revert
imo first try to fix the game and only if it is unfixable scream for server revert

Re: Spring 87.0! 2nd Run!
And here rises need of support multiple spring engine versions in the lobby. Personally I would love two releases of spring, stable with backported fixes and current where things might go wrong.
Of course such thing would be bad for packagers, but maybe spring as engine should disapear from packages completely and there would exist only lobbies. Good example would be playonlinux it autodownloads whatever needed version of WINE you need for whatever game from buildbot and no problems.
Of course such thing would be bad for packagers, but maybe spring as engine should disapear from packages completely and there would exist only lobbies. Good example would be playonlinux it autodownloads whatever needed version of WINE you need for whatever game from buildbot and no problems.
Re: Spring 87.0! 2nd Run!
Please revert these so I don't have to explain why:
-isCommander tag
-infolog.txt buffering
-removing ArchiveMover
-GL smoothing ON by default
-wdef[id].areaOfEffect, wdef[id].maxVelocity
-network bandwidth limits
-falling damage(or document workaround)
+similarly braindead changes
"--safemode" is not that safe, it crashes always with my ATI which used to work fine for years, works ok after running springsettings. http://www.opengl.org/wiki/Common_Mista ... d_GL_LINES
-isCommander tag
-infolog.txt buffering
-removing ArchiveMover
-GL smoothing ON by default
-wdef[id].areaOfEffect, wdef[id].maxVelocity
-network bandwidth limits
-falling damage(or document workaround)
+similarly braindead changes
"--safemode" is not that safe, it crashes always with my ATI which used to work fine for years, works ok after running springsettings. http://www.opengl.org/wiki/Common_Mista ... d_GL_LINES
Related to WeaponDef.maxVelocity etc. rename, maybe a leftover from testing what the change affects or highly braindead idea to protect game devs of using the tag.zwzsg wrote: The error being:
Error: Lua LoadCode pcall error = 0, LuaRules/main.lua, error = 2, LuaGadgets/gadgets.lua, ERROR_TYPE in WeaponDefs __index
Re: Spring 87.0! 2nd Run!
why?Pako wrote: -isCommander tag
Re: Spring 87.0! 2nd Run!
Yeah isComander was good and simple. At least for guy who want to create nothing more but simple lua script which creates some sound after com death by mapmod now WWF_RAW is broken and Trololo works for zk only, because that noob dont know and didint detect comander in each mod :)