Did some more testing and found some quirks with $script 0.  Made a new level scripts section, and updated kGame::CallDelayedMapScript().  I'm not going out of my way to verbosely spell out all the preprocessor stuff with examples 'n' such since I think it's kind of academic, but I think I've got all the basic info there.

Thanks for the area flags stuff.  Those function issues are pretty big; I'll probably try to take care of them soon.

I just checked it again, and yes it looks like kSelectionListFloat is exactly the same as kSelectionListInt. And int& Select(const bool = false) has a bool parameter.

Thanks for the confirmation.  The bool was added and the return value changed to a reference in 2.0.  Anecdotally, passing true seems to get results slightly closer to the expected values, but heck if I know what it's actually doing.

Some more info on map scripts. $restart remaps to

Code: [Select]

void Game.CallDelayedMapScript(const int scriptID, kActor @instigator, const float delay)
where scriptID is taken from the last $script <id> value used in the script before $restart. instigator is placed in the instigator actor arg and the delay is 0. So it's calling itself and will execute itself on the next script execution cycle (not immediately). You can do this same thing and call CallDelayedMapScript(const kStr &in funcName, kActor @instigator, const float delay) for your custom map functions in order to loop them.

Did some quick testing 'cause I was curious about how $restart would work in non-numbered level scripts, and inside functions called from other level scripts.  The impression I'm getting is that by "last $script used before $restart," you're talking about the actual topography of the file, not the execution order.

So for example if you had something like this:
$script 1
{
}

void Blah()
{
$restart;
}

$script 2
{
Blah();
}
and then called Game.CallDelayedMapScript( 2, Player.Actor(), 0 ), you'd get $script 2 -> Blah() -> $script 1

I know I can make new actors with custom functionality.  I was trying to avoid actor type ID collisions with Turok+, especially if I reorganize it in the future.  I guess that's kinda silly, considering there are over 4 billion possible actor type IDs, which leaves plenty of room for massive buffers between ranges of values.  I'll probably try to be smarter with my future maps. :b

Shit, you can actually get an actor's script object from a level script?  I tried doing that while making Cliffside Outpost, and as I recall I was getting cast errors, so I thought the game and level script contexts were just so distinct that they each had their own distinct copies of classes or something.  Just did a quick test with a QuakeSource from a level script, though, and I was able to call SetupShake() and mess with its member variables, so apparently I was doing something wrong before.  Really good to know that's possible after all.

Given that, I'm not sure what the purpose of using InteractActorsAtPosition() is?  Why not just get a handle to the dummy actor's script object and call the function directly?

Thanks for the notes.  I'll parse through them eventually, but just skimming through them I'm noting some nice little nuggets.

3DR just announced another new FPS, this time built on the Quake 1 engine.

http://www.wrath.game/