Old "maintenance" builds used for BA autohosts

Old "maintenance" builds used for BA autohosts

Classic game design, maintained to please you...

Moderator: Content Developer

Post Reply
abma
Spring Developer
Posts: 3798
Joined: 01 Jun 2009, 00:08

Old "maintenance" builds used for BA autohosts

Post by abma »

a lot of autohosts for BA still use old versions of spring from the maintenance branch. "104.0.1-151-g11de57d maintenance" is most common.

the most recent version is "104.0.1-303-g6a15411f7a maintenance"

is there a reason for using the old version?

it makes debugging / finding + fixing desync difficult.
User avatar
Floris
Posts: 611
Joined: 04 Jan 2011, 20:00

Re: Old "maintenance" builds used for BA autohosts

Post by Floris »

yeah cloaking behavior was removed from engine and dunno how to easily re-implement it.

I wrote a gadget that re-implements cloaking cost, but it doesn't decloak when enemy is in decloaking range or player has insufficient energy to cloak.


Then I gave up because there is no updated changelog for engine and you have to blindly encounter problems/changes as you test. I was told I should look at engine commits to know what changes.
User avatar
Floris
Posts: 611
Joined: 04 Jan 2011, 20:00

Re: Old "maintenance" builds used for BA autohosts

Post by Floris »

desyncs are maybe due to gadget eating too much mem. (dunno which)

Is there a way to see how much mem a gadget uses?


(atm when you connect after a game has started and if you cant catch up withing time, you'll memory rise rapidly until the limit of 800MB is reached and lua gets disabled and sync errors occur)
abma
Spring Developer
Posts: 3798
Joined: 01 Jun 2009, 00:08

Re: Old "maintenance" builds used for BA autohosts

Post by abma »

Floris wrote:(atm when you connect after a game has started and if you cant catch up withing time, you'll memory rise rapidly until the limit of 800MB is reached and lua gets disabled and sync errors occur)
should be fixed by https://github.com/spring/spring/commit ... b8b642aa34 or https://github.com/spring/spring/commit ... e63dbb912e on the maintenance branch.
User avatar
Silentwings
Posts: 3720
Joined: 25 Oct 2008, 00:23

Re: Old "maintenance" builds used for BA autohosts

Post by Silentwings »

Is there a way to see how much mem a gadget uses?
It's impossible to count, unfortunately. Within each lua state, there is no 'formal' division between what is a gadget/addon and what is other stuff, or which gadget/addon is which. There is nothing that tracks ownership/allocation of memory by particular source files, and it doesn't really make sense to try and do it because of libs, includes & massively frequent occurence of files calling each other functions, etc etc.
hokomoko
Spring Developer
Posts: 593
Joined: 02 Jun 2014, 00:46

Re: Old "maintenance" builds used for BA autohosts

Post by hokomoko »

Silentwings wrote:
Is there a way to see how much mem a gadget uses?
It's impossible to count, unfortunately. Within each lua state, there is no 'formal' division between what is a gadget/addon and what is other stuff, or which gadget/addon is which. There is nothing that tracks ownership/allocation of memory by particular source files, and it doesn't really make sense to try and do it because of libs, includes & massively frequent occurence of files calling each other functions, etc etc.
Actually, it is possible. Take a look at the widget profiler in chobby. It has a significant overhead so I'm not sure how accurate it is, but it measures mem consumption before and after every callin of every widget. In the end I think it used to dump the totals in the log.
User avatar
Silentwings
Posts: 3720
Joined: 25 Oct 2008, 00:23

Re: Old "maintenance" builds used for BA autohosts

Post by Silentwings »

it measures mem consumption before and after every callin of every widget
That would be measuring something different to what I said - for example, it would not immediately be enough info to isolate a memory leak occuring within a library function called by one addon but defined within another. But, still useful in many cases, thanks for pointing it out!

Edit: I had a look at the code you pointed too, and all I found was a profiler that seemed to be measuring the amount of garbage that was ready for collection (after each run of each callin) - not mem consumption. Could you link to what you mean?
User avatar
Silentwings
Posts: 3720
Joined: 25 Oct 2008, 00:23

Re: Old "maintenance" builds used for BA autohosts

Post by Silentwings »

So, after some clarification: It is possible to measure the total mem usage of lua states. It is not possible to sensibly define or measure "the amount of memory currently being used by widget/gadget X".

See https://github.com/Balanced-Annihilatio ... n/pull/104 for a version of the widget profiler (for the classic widget handler) that reports allocation rates per callin in Kbps.
abma
Spring Developer
Posts: 3798
Joined: 01 Jun 2009, 00:08

Re: Old "maintenance" builds used for BA autohosts

Post by abma »

atm some hosts use spring 104.0.1-138-gf1944b maintenance which isn't available for download any more. the same for spring 104.0.1-151... maintenance


see https://springrts.com/dl/buildbot/default/maintenance/

(maintenance + develop branch builds are automatically deleted after ~120 days: https://github.com/spring/spring/blob/d ... cleanup.sh )
User avatar
Silentwings
Posts: 3720
Joined: 25 Oct 2008, 00:23

Re: Old "maintenance" builds used for BA autohosts

Post by Silentwings »

I think 120 days is not ideal e.g. if only a little more time had passed between some commit and https://springrts.com/mantis/view.php?id=5992, bisection may well have been impossible without forced re-builds.
abma
Spring Developer
Posts: 3798
Joined: 01 Jun 2009, 00:08

Re: Old "maintenance" builds used for BA autohosts

Post by abma »

120 days is because of the limited disk space.
Post Reply

Return to “Balanced Annihilation”