Bugs in 1.6


100% reproducible so far (3/3). It’s with current svn .sdd.
Replay attached.

Transport unload must happen on an uneven piece of map, entrance to central pass on SmallDivide is just the right spot for the bug to manifest. Not all of the unloaded inf will fly, but about 1-3 of 10 do.

Edit2: looks like I just fixed it, at least I can’t reproduce it anymore. Please test.
(setting unloaded unit’s y coord correctly does the trick, our truck script was much too simplified)


‘Much too simplified’ seemed to work fine for 5+ years :laughing: Will test when I get the time


woot? yes!


Still flying on Moro with default start pos and a geropel



cleanrock said he’d take a look at it


Now they say it’s too hard to reproduce. Maybe we should rollback the transport script fix so it’s easy to reproduce again? (or just tell them to use latest released S44 where it should be very easy to do)


cleanrock struggles to reproduce it in Most III. IMO the script change was confirmation bias, I don’t think there’s any real change. Abma has reproduced it in S44, XTA and BA.


kloot fixed it. Now we’ll need to grab a test engine build to see if anything is still wrong.

Flying was not only specific to inf, I was able to send AT guns in the air as well (but that isn’t so easy to repeat). Probably the same bug.


I already wanted to do that yesterday, but 95.pre didn’t want to play ball with SL… paste.ubuntu.com/5934136/
I’ll be waiting for today’s new binaries to start tinkering again.
Both guns and mg nests did fly earlier but that was reduced a lot with one of those modside half-fixes.

Oh boy, 12 files changed :D> github.com/spring/spring/commit … 31de8d1770
I cannot enough express my joy over the fact that this problem has been mended at last.

From remaining acute nuisances I remember “Resign doesn’t end game” (and thus no demo, either). I don’t actually know right now whether it is fixed or not, or if it was a modside or engineside problem. I’ve been C-a C-d every time since this bug was introduced 3…4 releases ago.


Tried spring 94.1.1-794-g29ba410 with s44 3835. Got some lua errors

[f=0000000] [widgets.lua] Error: cannot open LuaUI/Config/S44.lua: No such file or directory

/* lines skipped... */

[f=0011070] Error: LuaRules::RunCallIn: error = 2, GameFrame, [string "LuaRules/Gadgets/game_ammo.lua"]:111: attempt to perform arithmetic on local            ^'reloadFrame' (a nil value)
stack traceback:
    [string "LuaRules/Gadgets/game_ammo.lua"]:111: in function 'ProcessWeapons'
    [string "LuaRules/Gadgets/game_ammo.lua"]:353: in function 'GameFrame'
    [string "luagadgets/gadgets.lua"]:946: in function <[string "luagadgets/gadgets.lua"]:944>
    (tail call): ?

,the latter one after selecting inf and “right clicing” them into the german transport halftrack (not vice versa).

S-ESC -> Resign does not end the game, but as I get it now it is not supposed to work that way any more, since the demo is written when you go S-ESC -> Quit.


Was that test started with spring directly? As in not via lobby? Some gadgets tend to break when there is no modoptions available, which happens if spring is started directly w/o a startscript.


(That) lua error with current spring is expected, will be fixed post release of 95. (change of weapon index in lua from 0->1)


Some other indexes have then changed, as unitsync doesn’t play along with SpringLobby and the factions’ selection is disabled. Currently there’s no way to start spring from SpringLobby (tried with the latest git SL). Also, CRAIG doesn’t fire up. Didn’t try with other bots, but did try SL with other mods, which had the same faction problem. BD and koshi have both been on summer holiday so I haven’t been able to contact them.

Spring 94.1.1-794-g29ba410 develop

[f=0000000] [Sound] Error: Unable to open audio file: FailedCommand
[f=0000000] [Sound] Error: CSound::GetSoundId: could not find sound: FailedCommand

[f=0000000] Error: Failed to load: craig.lua  (error = 2, LuaRules/Gadgets/craig/main.lua, [string "LuaRules/Gadgets/craig/main.lua"]:45: Incorrect arguments to DiffTimers())

[f=0000000] Connection attempt from Player
[f=0000000]  -> Version: 94.1.1-794-g29ba410 develop
[f=0000000]  -> Connection established (given id 0)
[f=0000000] Player Player finished loading and is now ingame
[f=0000000] Error: Unknown skirmish AI specified:  
[f=0000000] STATS:plist,Player
[f=0000024] Skirmish AI "Bot1" (ID:0), which controlled team 0 is now dead


CRAIG fixed in r3836


Fixed the other error in 3838, should be ready to play on 95. Please let me know if not!


Only warnings, for now. A bunch of infantry got stuck on an atgun some 4 seconds into the game… they were easily turned loose but that kind of thing hasn’t happened for a while.

[f=0000000] Warning: WeaponDef (.30calproof) The "isShield" tag has been removed. Use the weaponType="Shield" tag instead!
[f=0000000] Warning: WeaponDef (.50calproof) The "isShield" tag has been removed. Use the weaponType="Shield" tag instead!

[f=0000000] Warning: [CCEG::Load] LZflare: Unknown tag heatcloud::agespeed


Latest svn, spring 94.1: scout binoculars projectile causes momentary suppression on inf in target area. As in yellow stars appear and disappear next second (inf doesn’t go prone). May be intentional, but I doubt it.


Latest svn again: water transports can’t load units. Load cursor just does not appear. Tested Soviet inf boat and veh pontoon, GBR inf boat.
Edit: but if land units are /cheat /given into water, water transports CAN pick them up and cursors do appear. But not over similar units placed on land.
Edit2: same happens with v1.62, must be an engine change? Looks like water transports don’t consider units not in water as valid for loading?
Edit3: if boats pick units up from water, they can’t unload them anymore, regardless if on land or in water.


Will do some tests with other games to find out if this is an engine problem or not. *A probably since they tend to have water transports.


After some more tests:

  1. It’s engine problem, with 94.1 sea transports in XTA can’t load ground units as well (unless those units are in the water somehow)
  2. It’s already fixed in 94.1.1-826-g7f6f61d (latest test version available)

So we’ll have to wait for 95.0