How to get rid of these last pieces of ACS code?

[gwHero]

A while back I migrated most of my ACS code to ZScript, and only recently I discovered that action specials can be called from ZScript too, so at this moment actually all scripting in my project is moved to ZScript.

Except for.. triggers from the map. Since it is only possible (at least to my knowledge) to call ACS scripts from linedef triggers, and not ZScript, my remaining ACS consists only of a long list of functions that are all called from the maps with absolutely nothing more than ScriptCalls to ZScript:

---

Code: Select all

Script "ExitLevel" (void)
{
	ScriptCall("MCommon", "ExitLevel");  // Leave current level and go to next level
} 

Script "ReturnLevel" (void)
{
	ScriptCall("MCommon", "ReturnLevel"); // Leave current level and return to previous level
}

Script "ShowBat" (void)	// map01 cave
{
	ScriptCall("MMapThinker", "MapRequest", 502);
}

Script "relblind" (void)	// map01 barn
{
	ScriptCall("MMapThinker", "MapRequest", 503);
}

Script "LowerLadder" (void)	// map01 bridge
{
	ScriptCall("MMapThinker", "MapRequest", 504);
}

Script "RaiseCDoor01" (void)	// map01 exit mine
{
	ScriptCall("MMapThinker", "MapRequest", 505);
}
 
Script "OpenDoorBarn" (void)	// Map01: request to open door to the barn
{	
	ScriptCall("MMapThinker", "MapRequest", 506); 
}

Script "OpenDoorClosetM" (void)	// MAP01: request to open door to the closet in the mine
{	
	ScriptCall("MMapThinker", "MapRequest", 507);
}

etc etc 

Now is this a problem? Not really, and certainly not for the time being, but it feels kind a stupid to have ACS only as a parsing through library. So my question is: how to get rid of these? Is that already possible? Or could ScriptCall be promoted some way that it would be possible to use it as an action special directly on the map? Or is there more fancy event handling planned in ZScript for maps and linedef triggers that in future releases they all can be handled in ZScript classes/event handlers directly?

[Arctangent]

Well, uh, ZScript isn't really meant to replace ACS for individual map scripting, the whole big "move to ZScript" was about game system scripting. This is exactly why; there's no good way to call ZScript from a map nor attach ZScript behavior to an individual map, but ACS is specifically designed for that.

So, yeah, the reason this feels stupid would be due to using the wrong tool for this job - at least as far as the last three scripts go, based on what I can infer from their names and stuff. The other two sound generic enough to possibly be fit for ZScript hooked into by ACS.

[gwHero]

So, yeah, the reason this feels stupid would be due to using the wrong tool for this job - at least as far as the last three scripts go, based on what I can infer from their names and stuff. The other two sound generic enough to possibly be fit for ZScript hooked into by ACS.

Thanks for the reply. Well actually, six months ago I would probably have agreed with you. I've used ACS for years and I was very pleased with it, but now that I've worked with ZScript, I really can't say that ACS is better equipped for certain things at all. In fact, there is nothing (as far as I know) in ACS I can't do in ZScript, and most often even better or with a lot more possibilities. So I'm not convinced that ACS is a better tool for certain stuff.

[gwHero]

there's no good way to call ZScript from a map

Maybe my post was not clear enough; that is indeed what I mean what is missing: if that was added by for instance adding Scriptcall as a special so that one could call a Zscript function from the map, there would be not much limitations left.

[Nash]

I still leave map scripting in ACS. It's too clumsy to move EVERYTHING to ZScript. ACS has tight integration with the map editor, and timing stuff concerning level scripting is still the tightest in the ACS realm.

[gwHero]

ACS has tight integration with the map editor

Yes, that's true, for ZScript it's still missing, that's why I have this ACS script left. Well, I was hoping somebody had already found a way to bypass that. I think I've read somewhere on this forum that someone had added Scriptcall himself as a special, but I could not find the post anymore. Actually, if it's a gross hack to achieve, I wouldn't want that, and in that case I could consider adding a feature request.

[Graf Zahl]

ACS was specifically designed for map scripting, including having latent scripts that can wait for events.

ZScript is designed to interact with the engine internals. It also doesn't have any ability to suspend a script, so you'd have to write a state machine yourself to manage timed map events.
Ultimately there's little point moving this stuff out of ACS.

[gwHero]

ACS was specifically designed for map scripting, including having latent scripts that can wait for events.

ZScript is designed to interact with the engine internals. It also doesn't have any ability to suspend a script, so you'd have to write a state machine yourself to manage timed map events.
Ultimately there's little point moving this stuff out of ACS.

Indeed I do the timed events myself with a basic Thinker class that checks things like when a platform has stopped moving, and handles queued callbacks to the child map thinker. This gives me more control, it gives me more possibilities in a far better and modern language. Also I experienced pleasant side effects of the removal of acs code, like reducing the need for tags and tids in my maps, not to mention the fact that all Decorate actor stuff and migrated ACS stuff is now close together in classes with neater code than in the past.

So actually I have no regrets to have moved all the code, not even the hud stuff (i have no sbarinfo anymore in my TC). Maybe because I'm stubborn to have this personal preference of wanting all code in one environment, so if nobody else sees the benefit of making possible to remove te last remnants of acs, I certainly would not wanted this to be added just for me, because it's not a big deal of course.

[_mental_]

How about addition of fallback to ZScript in P_StartScript() function?

For named script its number converted back to string, split into class and method names, build argument list and match their types. After all these succeed the actual call will be made.
Implementation will be pretty similar to ScriptCall() function but with no relation to ACS string pool and fixed point math.

[Graf Zahl]

No, that's a hack, and a hack feature is just not acceptable. You also have to consider that ACS is run asynchronously, aside from ACS_ExecuteWithResult, and silently remapping to a synchronous fallback is bound to cause problems down the line.
If this is done it needs to be an explicit and separate feature.

[gwHero]

How about addition of fallback to ZScript in P_StartScript() function?

For named script its number converted back to string, split into class and method names, build argument list and match their types. After all these succeed the actual call will be made.
Implementation will be pretty similar to ScriptCall() function but with no relation to ACS string pool and fixed point math.

Sounds good; if I understand the implications correctly: would this be without a new special and just using the existing ones like 80 (Script Execute)?

Edit: ah, I see Graf has answered in the meantime

[gwHero]

Found a temporary solution using the recently added WorldLinePreActivated event. In this way it's possible to replace the ACS execute line special by acting
in the ZScript event directly. In this example action will be taken on the value of args[2] of the line special, which is the first argument of the script execute.

Code: Select all

override void WorldLinePreActivated( WorldEvent e ) 
	{
		// request from the map; special 80 = ACS execute; args[2]: 1st arg of the script execute
		Line l = e.ActivatedLine;
		if (l && L.special && L.special == 80 && L.args[2] && L.args[2] > 0)
		{			
			e.ShouldActivate = false;	// cancel ACS execute request, we will handle it here
			// --> perform ZScript code depending on L.args[2]...
		}
	}

It's a bit of a hack, but not one that's bound to be broken in future releases, so it's useful until there's a better solution implemented.

[Edit] credits to Marisa Kirisame/MajorCooke for adding this event to ZScript and _mental_ for pointing out the e.ShouldActivate boolean