Balance is probably all screwed up
Moderator: Content Developer
-
- Moderator
- Posts: 2464
- Joined: 12 Oct 2007, 09:24
Balance is probably all screwed up
To whoever is the BA maintainer.
Between 0.82.7 and 84.0 a bug was fixed in WaitForTurn that has had consequences for the firerates of many units in ZK. As I assume BA uses WaitForTurn in aim scripts the problem is relevant here too.
It may be worthwhile checking units you feel would mess up balance if their DPS changed. The largest change I found was 25% for a unit with 0.4 reload time which is strange given there are many units with less reload time, I think the strangeness of unit script is a large factor.
Here is a gadget I used to test in case you need one.
Between 0.82.7 and 84.0 a bug was fixed in WaitForTurn that has had consequences for the firerates of many units in ZK. As I assume BA uses WaitForTurn in aim scripts the problem is relevant here too.
It may be worthwhile checking units you feel would mess up balance if their DPS changed. The largest change I found was 25% for a unit with 0.4 reload time which is strange given there are many units with less reload time, I think the strangeness of unit script is a large factor.
Here is a gadget I used to test in case you need one.
Re: Balance is probably all screwed up
Could you provide more info on the nature of the bug/engine fix?
Re: Balance is probably all screwed up
So affected units have more, or less dps now? And is it only when the unit is moving in a specific way or such?
Re: Balance is probably all screwed up
what was the change made in wait for turn?
Re: Balance is probably all screwed up
interesting how this was just detected now.....
Anyways can you provide more info?
Anyways can you provide more info?
-
- Moderator
- Posts: 2464
- Joined: 12 Oct 2007, 09:24
Re: Balance is probably all screwed up
No.Beherith wrote:Could you provide more info on the nature of the bug/engine fix?
There is a trend towards higher effects for low reload times. Other than that any unit that uses WaitForTurn can have more or less DPS.Johannes wrote:So affected units have more, or less dps now? And is it only when the unit is moving in a specific way or such?
Also, no, depends on unitscript but is likely to occur all the time.
No idea, a fix apparently.smoth wrote:what was the change made in wait for turn?
No.scifi wrote:Anyways can you provide more info?
Re: Balance is probably all screwed up
I cant seem to find how to search the github commit log
Re: Balance is probably all screwed up
Code: Select all
$ git clone https://github.com/spring/spring.git
Cloning into spring...
remote: Counting objects: 149774, done.
remote: Compressing objects: 100% (28653/28653), done.
remote: Total 149774 (delta 121679), reused 148381 (delta 120521)
Receiving objects: 100% (149774/149774), 117.37 MiB | 394 KiB/s, done.
Resolving deltas: 100% (121679/121679), done.
$ cd spring
$ git log --grep='wait-for-turn'
Author: Tobi Vollebregt <tobivollebregt@gmail.com>
Date: Tue May 12 21:24:29 2009 +0200
UnitScript: revert bug introduced in 9f223596dadeeaa51836ecf0e98e5d05696cfa7d
This has to do with whether threads blocking on an animation are unblocked
or not before it's being replaced. If an existing animation is replaced
by an animation of the same type, then, according to the comment on top
of the method, threads blocking on that animation will now wait for this
new turn/move instead. If however a turn is replaced by a spin or
vice versa, then the original animation should be unblocked, otherwise
e.g. a wait-for-turn could wait infinitely until a spin stops spinning
(which it never does by itself)
The original code implemented this correctly; the bugged code implemented
the above for moves while always unblocking for turns.
As the comment above the method mentions, this behavior is arguable;
however it is still desired to use the same overriding behavior for both
moves and turns.
Hence this commit.
Code: Select all
$ git log --pretty=oneline --grep='wait'
7f701a18482ea1547df17e8f5c208aae204ba679 allow death-wait in games with more then 2 ally teams When the command is in the queue, it uses the normal wait command cursor now.
8ab24019e754e32ed5cc79cbe85516d95b460869 death-wait works again (take Gaia into account) [fix]
a999cf1fe05478f65488016e91997e911414d8a6 Fix mantis #1591 (slow response when releasing wait command) Improve previous commit
4a5f56dc66dc8a3c07f1863d35ad1bf13746b516 fix crash when squadwait squad is complete [fix]
d450ae1fc93bec77d329af9d6400cb56a2e29b96 move sound-initialization to the "waiting for server" idle time
f5c8313bd0d6d4c06ea45b0301f84dc4c8bec321 UnitScript: revert bug introduced in 9f223596dadeeaa51836ecf0e98e5d05696cfa7d
c3bf49830b2ef9e91e62c7622d35dc0344e5a982 don't throw "network unreachable"-exception (wait for regular timeout instead, people may have broken cable clips)
38f6627aab29df2a26eaa60aba632b36a22c271e Prevent decay when the builder or factory is waiting (executing a wait command).
aac6388f4af7f71cda588e86f7ca4f6a8eecfd2d - corrected an issue with std::out in spring and a bad interaction with Java. According to tobi luaUI prints out the name of each wi
bc47989940095c88a837909d6d2b15daa6dc4452 * reenabled traffic tracking in local connection * CPreGame waits till connection is established before continue loading the game *
f2772e5c8aa19c4e5ef62172bc3cb5d83f489769 * Fixed the wait/teleport factory bug
cc08a76edd19b9af7c3f39368b516ba49adb4aca * Oops, better wait till linking is finished before committing: forgot to add one file to the project resulting in undefined ref
00c6033c2133bf91de5d30afeb33cf9d4c0d00a4 fixed builders with area reclaim sometimes going out of their designated circle (closes #580) - added a waiting list of feature IDs
88cec4906be5af1006e9f608d41ca579406c4449 * Changed the code so that units can leave the factory as soon as they are completed (buildProgress >= 1.0), and not have to wait
87be45f5d14dfc0dfd609983d9d4624b8492e44c * Added tools/scripts/obj2lua.lua (WaveFront OBJ converter)
264b173a7c13568fa55993b6f740cc04913b472e * Revert the changes to wait-commands that had been started
75a5e4584e5820fc869cbfa8f738c7fdb2ef22e5 Added class wrappers to Mono wrappers, to provide CSAI-compatible interface.
4d3b1c4cb39a7d7b632cf3367ea726b446a3a496 * Kill remaining spring instance once one unexpectedly quits and the other doesn't detect that itself. (don't stall the test by
16938f70505b0926fc8e05f4dc63440fb91d1e7a * Fix bug where "blah blah ... press enter to start" message didn't appear when running spring as server without startscript. * Ig
bfca444eba4f6c951282696c1e2ee9358820a54e * Modified Sound::GetWaveId() to require a full path (still need graceful failures for the LUA PlaySoundFile())
6f625f8407468bd364f5cfb17cc09b09dd3f4cb7 * improved animation for squadwait cursor
021fa118ae49cc3974aaf46923bdb42092053243 * Added minimap control, with two modes (try setting the config variable "MiniMapFullProxy" to 1, the middle button will adjust
645f7ca0880d242b6a5b32eca773652b4175cdac * Re-indented WaitCommandsAI.cpp * Switched to a networt acknowledgement system for initial wait checks * Added some keybinding conf
4001eb7792022747e85ed1f9153d546323d0bf55 * Added SquadWait command (with "squadwait" binding) * Started some cleanup
f8241497c119edd26f1b52a88ce92fe7a9d3c3d8 * added a new attack mode where you can attack a group of units by selection an area on the map * added "newAttackMode" to ctrlpan
6f949bc782062ec2a3258cd597ce51b4ca5382f5 * During unloading, do not clear a unit's command queue if it was waiting
5b8a4d2f63fc378fadd57efc3c7a41ed184e2be0 * corrected queue build rendering (GL_DEPTH_TEST)
17b37bfe195987df3e6775c81c1b30d40b5e8d4d * fixed command page number being visible even when no units were selected.
7e0a83431fd4490691a83ba209c4329c7d03f86a We really don't need to wait for all these checks if we're just cleaning
0df53b5f15f5585e8363cd283730c3a84d2b03d4 Want to wait in milliseconds, not whole seconds
-
- Moderator
- Posts: 2464
- Joined: 12 Oct 2007, 09:24
Re: Balance is probably all screwed up
Don't ask me, do Science.
- Lord Juzza
- Posts: 60
- Joined: 20 Jan 2009, 11:50
Re: Balance is probably all screwed up
So I looked into it, googlefrog's wrong, nothing new is wrong with the balance of BA.
Re: Balance is probably all screwed up
Lord Juzza wrote:So I looked into it, googlefrog's wrong, nothing new is wrong with the balance of BA.
Please provide non-subjective evidence, and explain the method that lead you to this conclusion
Re: Balance is probably all screwed up
Should have made the thread in games&mod, since it should in theory affect all games.
Shouldn't it be possible to make some test lua to messure how long WaitForTurn takes? Afterall it should mess up all kind of things, not just fire rates.
Something like
shot -wait 5 frames- shot -wait 4 frames- repeat
because of rounding errors I guess.
Maybe WaitForTurn now changes that somehow?
What makes you think that it is WaitForTurn and not some change to reload times/weapons/targeting?There is a trend towards higher effects for low reload times. Other than that any unit that uses WaitForTurn can have more or less DPS.
Shouldn't it be possible to make some test lua to messure how long WaitForTurn takes? Afterall it should mess up all kind of things, not just fire rates.
Something like
Did you ever notice that some weapons shot like this:startTimer ()
Turn (piece, x_axis, math.rad(180),math.rad(1))
WaitForTurn (piece, x_axis)
stopTimer()
shot -wait 5 frames- shot -wait 4 frames- repeat
because of rounding errors I guess.
Maybe WaitForTurn now changes that somehow?
Re: Balance is probably all screwed up
don't want to sound like I am questioning your honesty, I am not I just want to know:Google_Frog wrote:No idea, a fix apparently.smoth wrote:what was the change made in wait for turn?
Where did you hear this? What is the source of this new issue discovery? I am curious so I know what may have changed in spring's unit behaviors.
Re: Balance is probably all screwed up
If this "apparently a fix to something" indeed is causing such changes I kinda doubt if the something is worth fixing this way.
- Lord Juzza
- Posts: 60
- Joined: 20 Jan 2009, 11:50
Re: Balance is probably all screwed up
No. :DAF wrote:Lord Juzza wrote:So I looked into it, googlefrog's wrong, nothing new is wrong with the balance of BA.
Please provide non-subjective evidence, and explain the method that lead you to this conclusion
Re: Balance is probably all screwed up
That is not caused by rounding, it has to do with how the return value of AimWeapon is passed back to the engine and the frequency at which it is called (every 15 frames as of 84.0). There is a WorkAround™ possible, but only for the special case that a weapon does not have to re-aim.knorke wrote: Did you ever notice that some weapons shot like this:
shot -wait 5 frames- shot -wait 4 frames- repeat
because of rounding errors I guess.
Maybe WaitForTurn now changes that somehow?
Re: Balance is probably all screwed up
Yea I meant the update frequency thing. So maybe the correct word is "aliasing" or something else idk.
Anyway, do you know something about the mystical WaitForTurn change?
Anyway, do you know something about the mystical WaitForTurn change?