What's up with BOS?

[Argh]

So after fixing some of the big bad bugs in P.U.R.E. and getting it ready for the current Spring engine... I've been testing my maps, and my infolog is full of this:

Code: Select all

[   4147] WARNING: LuaRules stack check: top = 12
[   4148] WARNING: LuaRules stack check: top = 8
[   4149] WARNING: LuaRules stack check: top = 12
[   4151] WARNING: LuaRules stack check: top = 40
[   4153] WARNING: LuaRules stack check: top = 8
[   4163] WARNING: LuaRules stack check: top = 12
[   4164] WARNING: LuaRules stack check: top = 8
[   4165] WARNING: LuaRules stack check: top = 12
[   4166] WARNING: LuaRules stack check: top = 20
[   4167] WARNING: LuaRules stack check: top = 20

It's BOS code causing the issue. I eventually tracked down the worst offender- I had a smokeUnit that was basically:

Code: Select all

SMOKEUNIT_PURE()
{
/*
a bunch of stuff that was commented out
}*/
}

Note that it's just an empty parenthesis.

I was in the middle of removing all that stuff and putting POPS in when I stopped working on things. Now it's reporting an "error" for an empty function call that would've just returned to sender before, without causing an error.

And this isn't the only place where it's happening- I've tracked down a similar error which was caused by this:

Code: Select all

    stop-spin centroid around y-axis;

    show base;
    show body;
    show mushroom;

    play-sound("argh_bombdrop",15);

    move body to y-axis [32] speed [1500];
    wait-for-move body along y-axis;
    
    play-sound("argh_plasmabomb",15);    
    emit-sfx BUILDING_COMPLETE from buildflare1;
    emit-sfx BUILDING_COMPLETE from buildflare2;
    emit-sfx BUILDING_COMPLETE from buildflare3;
    emit-sfx BUILDING_COMPLETE from buildflare4;
    emit-sfx BUILDING_SMALL_COMPLETE from buildflare1;
    emit-sfx BUILDING_SMALL_COMPLETE from buildflare2;
    emit-sfx BUILDING_SMALL_COMPLETE from buildflare3;
    emit-sfx BUILDING_SMALL_COMPLETE from buildflare4;        
    sleep 150;            
    move body to y-axis [16] speed [50];
    wait-for-move body along y-axis;
    
    play-sound("argh_plasmabomb",15);        
    emit-sfx BUILDING_COMPLETE from buildflare1;
    emit-sfx BUILDING_COMPLETE from buildflare2;
    emit-sfx BUILDING_COMPLETE from buildflare3;
    emit-sfx BUILDING_COMPLETE from buildflare4;
    emit-sfx BUILDING_SMALL_COMPLETE from buildflare1;
    emit-sfx BUILDING_SMALL_COMPLETE from buildflare2;
    emit-sfx BUILDING_SMALL_COMPLETE from buildflare3;
    emit-sfx BUILDING_SMALL_COMPLETE from buildflare4;        
    sleep 150;        
    move body to y-axis [0] speed [25];
    wait-for-move body along y-axis;
    
    call-script RandomLandingSounds();
    emit-sfx LANDING_DIRT from center;
    sleep 1;
    emit-sfx LANDING_DIRT from center;    

If this error is related to emit-sfx or conditional waits within Create() (which I'll test soon), then I'm screwed, until I can shove it all out to start-script functions. We're talking 3-5 thousand lines of code here, though, in maybe a hundred BOS scripts, because I do a lot of stuff during Create and I use a heck of a lot of emit-sfx.

Anyhow, I'll get working on fixing my own stuff; I just thought people might want to know about the issue.

[Argh]

Bad news. This gets rid of the errors.

Note what's commented out.

Code: Select all

doCreate()
{
////////////////////////////////////////////////////START BUILD CYCLE
    while( get BUILD_PERCENT_LEFT )
    {
        spin centroid around y-axis speed <300> / get BUILD_PERCENT_LEFT;
        spin centroid around x-axis speed <300> / get BUILD_PERCENT_LEFT;        
        emit-sfx BUILDING_PROGRESSIVE from buildpoint_one;
        emit-sfx BUILDING_PROGRESSIVE from buildpoint_two;
        emit-sfx BUILDING_PROGRESSIVE from buildpoint_three;
        sleep RandomNumber;
    }
    
////////////////////////////////////////////////////STOP BUILD CYCLE

////////////////////////////////////////////////////DROP, FIRE, SMOKE    
    
    stop-spin centroid around y-axis;

    show base;
    show body;
    show mushroom;

    play-sound("argh_bombdrop",15);

    move body to y-axis [32] speed [1500];
    wait-for-move body along y-axis;
    
    play-sound("argh_plasmabomb",15);    
/*    emit-sfx BUILDING_COMPLETE from buildflare1;
    emit-sfx BUILDING_COMPLETE from buildflare2;
    emit-sfx BUILDING_COMPLETE from buildflare3;
    emit-sfx BUILDING_COMPLETE from buildflare4;
    emit-sfx BUILDING_SMALL_COMPLETE from buildflare1;
    emit-sfx BUILDING_SMALL_COMPLETE from buildflare2;
    emit-sfx BUILDING_SMALL_COMPLETE from buildflare3;
    emit-sfx BUILDING_SMALL_COMPLETE from buildflare4;    */    
    sleep 150;            
    move body to y-axis [16] speed [50];
    wait-for-move body along y-axis;
    
    play-sound("argh_plasmabomb",15);        
    /*emit-sfx BUILDING_COMPLETE from buildflare1;
    emit-sfx BUILDING_COMPLETE from buildflare2;
    emit-sfx BUILDING_COMPLETE from buildflare3;
    emit-sfx BUILDING_COMPLETE from buildflare4;
    emit-sfx BUILDING_SMALL_COMPLETE from buildflare1;
    emit-sfx BUILDING_SMALL_COMPLETE from buildflare2;
    emit-sfx BUILDING_SMALL_COMPLETE from buildflare3;
    emit-sfx BUILDING_SMALL_COMPLETE from buildflare4;    */    
    sleep 150;        
    move body to y-axis [0] speed [25];
    wait-for-move body along y-axis;
    
    call-script RandomLandingSounds();
    /*emit-sfx LANDING_DIRT from center;
    sleep 1;
    emit-sfx LANDING_DIRT from center;    */    
/////////////////////////////////END BUILD CYCLE
    return;
}

Create()
{
    hide base;
    hide body;
    hide mushroom;

    RandomTurn = rand(1, 65535);
    turn base to y-axis RandomTurn now;

    RandomNumber = RAND(50,100);
    move body to y-axis [3000] now;

    start-script doCreate();

    RandomNumber2 = RAND (15,35);
    //start-script SmokeUnit_PURE();
    start-script RandomLight();
    spin mushroom around y-axis speed <1>*RandomNumber2;
    return(0);
}

What's weird is that emit-sfx seems to work elsewhere, like flare emissions and suchlike. Oh well...

[Argh]

OK. We have a really big issue here.

Every single emit-sfx event appears to be causing the stack-check problem. I just got to observe it happening with a gun flare. The flare works, but it spits out an error message.

So, er... I'm not seeing stuff in the changelog; surely this got broken everywhere.

What's the fix, folks? Because doing this:

Code: Select all

FireWeapon1()
{ 
    call-script lua_CreateLightMe(light, 255, 255, 64, 128);
    //emit-sfx WHAM_GROUND_FLASH from groundflash;
       //emit-sfx WHAM_LAUNCH_FX from flare; 
    move barrel to z-axis [-9] speed [100];
    sleep 200;
    call-script lua_DestroyLightMe();
    move barrel to z-axis [0] speed [10];
    return(0);
}

Or calling Lua just to do something that worked 6 months ago seems a bit ridiculous.

[smoth]

I know rite, the guy comes in late, bitches about TPS reports and how we are not making enough commits. BASTARD was wearing his golf shoes, I swear he just came off the driving range. He smelled of sweat, young golf caddie and scotch.

oh you meant BOS...

[Argh]

Right now, about 8 hours in, it's more like, "so, I heard u like bugs with your bugs".

This one's my favorite, though- the CEGs work just fine, except for the error message spam

[smoth]

Thing is everyone else is using emits just fine, so unless your cegs are bugged or you have some missing or altered lua files(possible), I have no idea what is going on.

[Argh]

The CEGs have been stable for years, in most cases.

If it's Lua, that's weird. It's BOS, calling CEGs. It shouldn't involve Lua at all.

Read through the infolog. No Lua errors, either, other than this mysterious "stack check", which doesn't give me a clue where it's happening.

Draw and Main just use the same ol' VFS copy they always have been (other than commenting out unsafechanges).

I'm sure there are some Lua errors in some Gadgets, no doubt, but most of the major features are working normally at this point. It's not like I'm getting hundreds of errors here from Lua stuff that's unhappy.

So I'm left with a big fat WTF atm. If it's Lua, it shouldn't be happening in the first place, because it's BOS and CEG, old stuff that has worked forever.

It's not Lua-calling a CEG, it's not "do some Lua and then maybe do a CEG in BOS", it's just plain BOS and CEG.

And the CEGs work... so that rules out the CEG code being bad or whatever.

[smoth]

If your gadgets are shitting the bed then your tdfs etc may shit the bed as well. Lua parses all those files. So if you are causing gadget handler to shit the bed it might be causing a plethora of seemingly unrelated issues.

[Argh]

Sure, but then I'd expect to see a Gadget crash in the log. I don't

And if it was TDF stuff, I'd expect the CEGs to not show, malformed unitDefs, etc.

I guess I can just turn off Gadgets until I've eliminated that as a cause, though- it'll take less time than the alternatives.

[AF]

Not all logic bugs cause crashes

[Argh]

But all logic bugs should at least tell me where they're happening. Anyhow, more when I've had some time to try and eliminate the issue, and have some clue as to why there's a problem in the first place.

[smoth]

No logic bugs are not going to tell you where they are, only errors are. Unless your logic bug causes something serious to error(which something apparently is) then you are not going to get an error. As the coder YOU have to write error checking if you want it.

Logic errors can be simple problems with your execution order of something to entirely not understanding what you were doing due to a complete lack of understanding resulting in spaghetti hack code. It depends on what you did wrong and I don't really have the time to help beyond trying to give you a person to bounce ideas off of.

[TheFatController]

Well something has changed with emit-sfx if you look at the ship and hovercraft water trails in BA they've gone crazy in the last spring update, apparently some other mods got this too..

[FLOZi]

Well something has changed with emit-sfx if you look at the ship and hovercraft water trails in BA they've gone crazy in the last spring update, apparently some other mods got this too..

S44 suffers from that (and btw, our scripts have a pretty hefty 300ms sleep between emits, so it's possible something was actually fixed to respect that), but Argh has reported similar problems to this before, and clearly, it has something to do with lua. My guess is that PURE is doing some lua<->cob work to do with these emits?


http://github.com/spring/spring/blob/ma ... Handle.cpp line 209 is where the error is called. Are you making heavy use of RecvFromSynced?

[smoth]

working fine for me.


(click for larger)

The white parts on the surface are the old emits and the bright glowy shit is ceg

[Argh]

Yeah, I'm making heavy use of RecvFromSynced (POPS). But it's been showing up even when traffic between synced and unsynced is practically zero. POPS doesn't do any communications at all if we aren't calling new events. On a blank map, there's nothing happening, other than the usual synced-->unsynced communications for minor crap like UI, which is not much traffic.

I've tracked down the issue on firing. It's related to a power-management script (that was working just fine before), where the Unit requests the level of a resource before firing, and if we don't have enough Power, then it's supposed to return 0 in the firing script. The script appears to be working fine, yet it throws an error.

Why it's happening... I have no idea yet. It uses the same old GET_LUA to receive the return that have been working forever.

I've found another issue with this, where a script that triggers DestroyUnit is causing the problem. The unit that's supposed to get destroyed works 100% correctly (i.e, kaboom), and there are no other fancy Lua events after that... but I still get the error.

I'm going to test something on that.

And Smoth, I'm not communicating clearly here. CEGs are working; the error spammage is being caused by stuff that used to work, appears to still be functional, but is now throwing console errors left and right. Whatever's going on here is Lua-related, and probably has to do with COB-->Lua issues (or Lua-->Lua now, I guess).

[smoth]

IIRC cob is not parsed by lua.

[AF]

If you look properly, you'll notice smoth merely clarified which part of the effects in his screenshot was CEG, and which was emit-sfx, nowhere did he imply or infer anything more. Assuming that this is him saying that your CEGs are bugged is jumping to conclusions, as his previous 'suggestion' has already been addressed, and despite numerous posts since, he did not elaborate on the suggestion.

As a suggestion, what happens if you rewrite a small script that has this issue into lua and then test to see if the problem is still present? If so then you are likely to gain more information about the problem, and if not then it helps lead towards the location and cause of the issue and perhaps its solution.

Eitherway it would produce an appreciable speed boost to your code by removing the expensive lua<->cob communication overhead, and simplifying what appears to already be a complex and nontrivial piece of programming. This can only be a good thing.

[Argh]

This is a typical case:
COB:

Code: Select all

KnockOver()
{
	var knockTimer;
	knockTimer = rand(500,1500);
	while(amMoving)
	{
		call-script lua_KnockOver();
		sleep knockTimer;
	}
	return 0;
}

Lua:

Code: Select all

function gadget:GetInfo()
    return {
        name = "KnockOver",
        desc = "Destroys Units with the KnockOver tag, if a Unit gets too close (trees, etc.)",
        author = "Argh",
        date = "March 3, 2009",
        license = "(C) 2008, Wolfe Games",
        layer = 1,
        enabled = true,
    }
end

local Gaia = Spring.GetGaiaTeamID()
local sizeX = 0
local GetUnitPosition 
local knockOverTable = {}

local GetUnitDefID = Spring.GetUnitDefID
local DestroyUnit = Spring.DestroyUnit
local GetUnitsInCylinder = Spring.GetUnitsInCylinder
local GetUnitPosition = Spring.GetUnitPosition
local GetUnitTeam = Spring.GetUnitTeam

if (gadgetHandler:IsSyncedCode()) then

function gadget:Initialize()
    for ud,_ in ipairs(UnitDefs) do  -- search all UnitDef entries
        if UnitDefs[ud].customParams.knockover == "yes" then
            table.insert(knockOverTable,ud,0)
        end
    end
end

--////////////////////////////////////////////////////////////////////  SAFE DELAYED COMMANDS
local delayedCalls = {}
function DelayedCall(fun)
    delayedCalls[#delayedCalls+1] = fun 
end

function gadget:GameFrame(f)
    for i=1,#delayedCalls do
        local fun = delayedCalls[i]
        fun()
    end
    delayedCalls = {}
end
--////////////////////////////////////////////////////////////////////

function KnockOver(u,ud,team)
    sizeX = UnitDefs[ud].xsize
    local x, y, z = GetUnitPosition(u)
    unitGroupNum = GetUnitsInCylinder(x, z,sizeX * 6,Gaia)
    for _,me in ipairs (unitGroupNum) do
        if me ~= u and knockOverTable[GetUnitDefID(me)]  then
            DelayedCall(function()
                if Spring.ValidUnitID(me) and Spring.GetUnitIsDead(me) == false then
                    DestroyUnit(me,true,false)
                end
            end)
        end
    end
end
gadgetHandler:RegisterGlobal("KnockOver", KnockOver)

end

Units that get destroyed by this are functioning correctly; they're destroyed, all CEGs are operational, everything works... except for the WARNING error in the console.

Any ideas why? I'm pretty confused about why all of it's functioning correctly, but is spitting out these stack check errors.

@AF: I'll probably just end up suppressing the errors, if the solution isn't faster than that- switching over to all-Lua is not an option, time-wise.

[AF]

I never suggested changing everything to lua at all, I've made a large point in the past of needlessly changing everything on the grounds of time, and that you should use lua for new stuff, and convert only when necessary. I only suggested that you convert 1 single small script that exhibited the error message as a test to shed light on this problem.


Also,

Is this:

Code: Select all

local delayedCalls = {}
function DelayedCall(fun)
    delayedCalls[#delayedCalls+1] = fun 
end

function gadget:GameFrame(f)
    for i=1,#delayedCalls do
        local fun = delayedCalls[i]
        fun()
    end
    delayedCalls = {}
end

Not more convoluted, error prone, and unreadable, than this? :

Code: Select all

local delayedCalls = {}
function DelayedCall(fun)
    table.insert(delayedCalls, fun)
end

function gadget:GameFrame(f)
    for i, delayedCall in ipairs(delayedCalls) do
      delayedCall()
    end
    delayedCalls = {}
end

That and renaming DelayedCall(fun) to DelayCall(call)