Balance is probably all screwed up

Balance is probably all screwed up

Classic game design, maintained to please you...

Moderator: Content Developer

Post Reply
Google_Frog
Moderator
Posts: 2464
Joined: 12 Oct 2007, 09:24

Balance is probably all screwed up

Post by Google_Frog »

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.
User avatar
Beherith
Posts: 5145
Joined: 26 Oct 2007, 16:21

Re: Balance is probably all screwed up

Post by Beherith »

Could you provide more info on the nature of the bug/engine fix?
User avatar
Johannes
Posts: 1265
Joined: 17 Sep 2010, 15:49

Re: Balance is probably all screwed up

Post by Johannes »

So affected units have more, or less dps now? And is it only when the unit is moving in a specific way or such?
User avatar
smoth
Posts: 22309
Joined: 13 Jan 2005, 00:46

Re: Balance is probably all screwed up

Post by smoth »

what was the change made in wait for turn?
User avatar
scifi
Posts: 848
Joined: 10 May 2009, 12:27

Re: Balance is probably all screwed up

Post by scifi »

interesting how this was just detected now.....

Anyways can you provide more info?
Google_Frog
Moderator
Posts: 2464
Joined: 12 Oct 2007, 09:24

Re: Balance is probably all screwed up

Post by Google_Frog »

Beherith wrote:Could you provide more info on the nature of the bug/engine fix?
No.
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?
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.

Also, no, depends on unitscript but is likely to occur all the time.
smoth wrote:what was the change made in wait for turn?
No idea, a fix apparently.
scifi wrote:Anyways can you provide more info?
No.
User avatar
Beherith
Posts: 5145
Joined: 26 Oct 2007, 16:21

Re: Balance is probably all screwed up

Post by Beherith »

I cant seem to find how to search the github commit log :(
User avatar
Anarchid
Posts: 1384
Joined: 30 Nov 2008, 04:31

Re: Balance is probably all screwed up

Post by Anarchid »

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.
Dunno, seems too old. There is also another with "wait-commands", but that one is dated 2006:

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
Google_Frog
Moderator
Posts: 2464
Joined: 12 Oct 2007, 09:24

Re: Balance is probably all screwed up

Post by Google_Frog »

Don't ask me, do Science.
User avatar
Lord Juzza
Posts: 60
Joined: 20 Jan 2009, 11:50

Re: Balance is probably all screwed up

Post by Lord Juzza »

So I looked into it, googlefrog's wrong, nothing new is wrong with the balance of BA.
User avatar
AF
AI Developer
Posts: 20687
Joined: 14 Sep 2004, 11:32

Re: Balance is probably all screwed up

Post by AF »

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
User avatar
knorke
Posts: 7971
Joined: 22 Feb 2006, 01:02

Re: Balance is probably all screwed up

Post by knorke »

Should have made the thread in games&mod, since it should in theory affect all games. ;)
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.
What makes you think that it is WaitForTurn and not some change to reload times/weapons/targeting?
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
startTimer ()
Turn (piece, x_axis, math.rad(180),math.rad(1))
WaitForTurn (piece, x_axis)
stopTimer()
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?
User avatar
smoth
Posts: 22309
Joined: 13 Jan 2005, 00:46

Re: Balance is probably all screwed up

Post by smoth »

Google_Frog wrote:
smoth wrote:what was the change made in wait for turn?
No idea, a fix apparently.
don't want to sound like I am questioning your honesty, I am not I just want to know:

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.
User avatar
Johannes
Posts: 1265
Joined: 17 Sep 2010, 15:49

Re: Balance is probably all screwed up

Post by Johannes »

If this "apparently a fix to something" indeed is causing such changes I kinda doubt if the something is worth fixing this way.
User avatar
Lord Juzza
Posts: 60
Joined: 20 Jan 2009, 11:50

Re: Balance is probably all screwed up

Post by Lord Juzza »

AF 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
No. :D
Kloot
Spring Developer
Posts: 1867
Joined: 08 Oct 2006, 16:58

Re: Balance is probably all screwed up

Post by Kloot »

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?
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.
User avatar
knorke
Posts: 7971
Joined: 22 Feb 2006, 01:02

Re: Balance is probably all screwed up

Post by knorke »

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? :wink:
Post Reply

Return to “Balanced Annihilation”