Death Event Timing

[Argh]

It appears that any call-script during Killed() that involves a sleep will not execute any instructions after the sleep. Sleeps within the main death-script will execute normally, it's just when you use call-script that it fails.

For example:

Code: Select all

Killed()
{
  call-script Blah();
}

Blah()
{
 Do Stuff;
 sleep 1000;
 Do More Stuff;
}

Only seems to execute Do Stuff, but skips Do More Stuff entirely

I'd much rather that Units weren't removed until all calls from Killed() have returned, so that I can do layered behaviors and have a lot more flexibility in terms of timing.

[Argh]

Ugh, it's even worse than that!

A script like this:

Code: Select all

Killed()
{
  call-script(Blah);
  sleep 1000;
  call-script(Blah2);
}

Never calls script Blah2.

Moreover, I've just tested While loops, and they don't work, either:

Code: Select all

Killed()
{
var N;
N = 5;
While(N > 0)
{
Do Stuff;
N = N - 1;
}
}

This executes the while loop once, then quits! This really sucks, for building decent death animation code.

[Argh]

GRRRRRRRR...

Ok, something is seriously fubar'd. I'm still not sure what, but this is really, really fundamentally bad.

Code like this will run:

Code: Select all

Killed()
{
Call-Script SomeThingFast();
Do Stuff;
}

Code like this will not run correctly:

Code: Select all

Killed()
{
Call-Script SomeThingFast();
Do Stuff;
Sleep 60;
Do More Stuff;
}

The above never executes Do More Stuff.

I'm starting to think it has to do with how many IF layers there are, after checking some monstrously complex death animation code I've written for some other stuff, which uses very little logic, just a sequence of hardcoded events. The problem here is that I need to use logic.

[Argh]

Hmm. Check this out. The following code prints the value of Point up until it reaches a value of 2, then quits. It doesn't crash, it doesn't give me an error... it just acts like the code's not even there

Code: Select all

Killed(severity, corpsetype)
{
var Point;
SomeNumber = 4;
Point = 1;
GET PRINT (Point);

	if(SomeNumber == 4)
	{
		Point = 2;
		GET PRINT (Point);
		sleep 60;
//////////////////////////////////
		sleep 60;
}
}

I see Point go to value 1, then value 2... then nothing. It's not the logic, it's apparently the sleeps within an IF that are doing this.

[Argh]

This just returns 1, then does not return any more.

Code: Select all

Killed(severity, corpsetype)
{
	var Point;
	Point = 1;
	GET PRINT (Point);
	sleep 60;
	Point = 2;
	GET PRINT (Point);
	sleep 60;
	Point = 3;
	GET PRINT (Point);
}

This returns nothing at all:

Code: Select all

Killed(severity, corpsetype)
{
	var Point;
	Point = 1;
	sleep 60;
	Point = 2;
	sleep 60;
	Point = 3;
	GET PRINT (Point);
}

Clearly, something is majorly wrong here. The UnitID must be getting removed from the game during the death event, well before Killed() completed. I'm going to compare this with my giant animated death sequences and see if I can find a pattern... aha! I have a wait-for-turn statement in my big thing... <tests>

[FLOZi]

There's nothing in that code to make point anything greater than 2? (in your previous post)

[Argh]

@FLOZi: Er, yeah, you're right... editing error, I was cutting out huge swatches of code there.

Code: Select all

Killed(severity, corpsetype)
{
	move flare_r to y-axis [-5] speed [0.01];
	var Point;
	Point = 1;
	sleep 60;
	Point = 2;
	sleep 60;
	Point = 3;
	GET PRINT (Point);
	wait-for-move flare_r along y-axis;
}

No good. Lemme check Scriptor, make sure of the output... <checks> Nope, it's ok. This is really turning into a strange mystery.

My giant, complex, but completely linear death animation scripts work, even with sleeps. However, three simple changes to a var and two sleeps seem to fail

[Argh]

Rebooted, reinstalled Spring 0.76b1... same results. Checked Scriptor settings, same results.

Anybody else want to test this stuff? I can make a quickie script, but meh, this should be trivial to verify, just use that last test script to replace Killed() in, say, a Peewee script, tell me if you see Point return any values at all...

[lurker]

Why don't I make you a nice cob debug build, that will output every single thing it does with a particular unit type's script.
Would you like 76b1 or svn, and what is the unit's name?

[Argh]

For this, I might as well use 0.76b1, I don't think anybody's been messing with COB lately, and it failed this test as well. The unit's name is "Bomber"- it's what I was testing this with, before I realized that I'd run into a major snag.

Before you take the time and trouble, though, you wanna just try a CA peewee script? I can just modify it and compile a COB, these results are so baffling that I keep thinking there has to be something simple behind it.

Hey... maybe... maybe it's BECAUSE IT'S AN AIRCRAFT... <tests>

[Argh]

Yes! Finally! Results that make some sort of sense! I thought I was going crazy there, for a minute. It's because it's an aircraft! The script works perfectly when applied to a building!

Arrrgh. Is it the stupid crashing code? Must be the stupid crashing code, that's the only place I can remember seeing COBhandler stuff, aside from StartMoving.

At least now I know what the heck is wrong...

[lurker]

if (beingBuilt || dynamic_cast<CAirMoveType*>(moveType) || reclaimed) {
uh->DeleteUnit(this);
}

Well then, looks like a 5 second fix; let's see if it works.

[Argh]

I hope so. I invested all night into coding this stuff, and aircraft were one of the specific places I wanted to use it. Was tearing my hair out, thinking I was missing something really stupidly obvious, but the simpler the tests got, the more puzzling this was...

[lurker]

Well, it's compiling, and I'm going to go get breakfast. I'll probably have a test build up in 20 minutes.

[Argh]

Great! Hope this works...

[lurker]

http://evolutionrts.info/random/76b1+test1.7z

Okay *now* I go to breakfast.

[yuritch]

I've stumbled upon this one too (when I was trying to use set CRASHING in Killed() for planes). Good to know it'll be fixed now (I see no reason NOT to put this one in svn once it's tested)

[Argh]

It works

[lurker]

It looks like this code makes units currently in killed() instantly stop completely, even if in midair. Is that true?

[Argh]

Yes. And it sucks, for lengthy aircraft detonation sequences.

Once Killed() begins, the Unit is in a stunned state, IIRC (the bar turns blue) and leaves that state only when deleted.

The only exception is Aircraft, with their !*@#*!* crashing state, which turns them into invulnerable objects that will only die when they collide with a building or the ground. Otherwise the Unit just sits there, doing nothing except what Killed() tells it to do.

It'd be nice if Crashing was just something that when it occured used the current velocity of the aircraft (it doesn't- like the fact that aircraft don't use specified acceleration values, it's just a hardcoded preset), immediately invoked gravity (it does, but doesn't seem to take MyGravity into account, which can have hilarious results on maps with low gravity), some specified amount of drag per frame, and let Killed() run normally during that time, so if you want to blow it up in the middle of a crash, you just call LUA and say, "delete me, NOW!", instead of the current system.

It'd also be nice if it was entirely optional, instead of being mandatory.