Scripting is a mess...

[sinistar]

I can't believe how did you ever get the SG to work correctly with this scripting system. It's working against the modder, and really discourages from doing any modding at all.
For example: I want to make a mod that will add credits for every destroyed asteroid. Why isn't there an event to add my script against such activity. So OK! I used the GainResourSe.sal? where I simply call:

/* cheat */
player AddCredits 1000 ;
/* end cheat */

/* call default */
script Data\Scripts\AsteroidDefault\GainResourse.sal ;

End

And BOOM, the game crashes instantly on asteroid kill! Why? All I get in the LogError.txt is:

Error: Credits were about to be reduced below 0.

What the hell!? How on earth adding 1000 is reducing? I tried various sums and all end with the same crash.
I tried similar things with other scripts, e.g. Data\Scripts\PanelEvents\Any_Panel_OnShow.sal
where I did similar thing as above, but calling the default Any_Panel_OnShow.sal instead, and same thing, BOOM Crash!
How can you not allow for this basic chaining of scripts? But what would be more useful, why isn't there an even to register against. This would allow multiple scripts to work off the same event with priority based on the order.

How can I get the above to work?

[Geek]

Why are you making a script call ?
This looks like an infinite loop to me. No wonder the game crashes.

[sinistar]

Първоначално публикувано от Geek - Gemini Warlord:

Why are you making a script call ?
This looks like an infinite loop to me. No wonder the game crashes.

As I said, so that the default functionality can be called, instead of copy pasting the original script, but even without the call the game crashes with the same error. The problem with copying the original script is that the mods can be invalidated without warning on every game update.

[Geek]

What are you talking about ?

The game only ever use one version of a file. Either the original one, or the modded one if present. Never both. Thus making a script call to the script of the same name results in an infinite loop.

Do this properly (and that means using a mod folder, so no update issue) and it works.

[danijel]

@sinistar
Could you please send the script over to [e-mail] so we can check it out in detail?

Running a script from within the same script will definitely create a loop. Running other scripts is naturally possible.

[danijel]

In general, most scripts are linked to game objects via events, but there are some scripts whose parent event isn't expose, but rather the script is hard-coded to run (the .sal file with that path). I believe Any_Panel_OnShow.sal is one such script. GainResourse.sal is I believe linked in an OnDestroy script of an asteroid field (linked via Data\World\world.ics). The scripting language we use is quite a bit more advanced than it was in Starpoint2, but there are still rules to follow.

[sinistar]

Thanks for suggestions, but I already figured out the problem with crashing - which was down to Math crashing on certain operations with values too large.

But:
My point was that the current system is messed up. The example I gave above was just to point out the problem of not being able to "add" modded functionality on top of the existing one, without having to copy and paste the original code in FULL. The moment the game is updated, the script may have changed, and so it makes my mod useless. My example above just shows how I would like it to work to "at least" make it safe and future proof, by calling the original code, instead of copying it, though it still only supports one mod for the same script at a time which is the biggest issue here.
If I want to write two mods working together, if both are installed, but each one being usable on its own, I can't do it in the current implementation. I can only have one working or the other, or merge them into one.

Sorry for stating this so bluntly, but the scripting is not really advanced at all, it lacks any kind of structure, advanced control blocks or any way to make reusable pieces of code (except for calling script), that proper languages like python/lua/perl/squirell or even vbscript provide. It completely isolates the mod from the rest of the game engine.
I get that it's been with you for 2+ generations but why prevail and keep it now for the SGW? Are you really going to remake SG yet again, just to make it use lua?

Even if we have to stick with the current scripting system, can you at least add another method called: "script2" or something that will call the original code, rather than the one in the mods folder? This would at least make the mods safer and more future proof.

It would be waaaay better though, if you could add a way to register a method in a mod to be called when certain event happens.

Example:

I. Three methods (for simplicity) could be added for event handling:
- OverrideEvent <- this overrides the original event replacing the functionality - current behaviour
- RegisterEventBefore <- this calls the script provided in argument list, before calling the original or overriden event
- RegisterEventAfter <- this calls the script provided in argument list, after calling the original or overriden event

II. Each mod could contain special script MAIN.SAL which would be called by the engine when the mod is loaded.

III. Then:
1. "main.sal" file in the First mod could contain line:
RegisterEventAfter "Any_Panel_OnShow" "MyAnyPanelOnShow.sal"

2. "main.sal" file in the Second mod (in order) could contain line:
RegisterEventBefore "Any_Panel_OnShow" "MyAPOS.sal"

When the "Any_Panel_OnShow.sal" is to be called by the game engine, it would call the:
1. APOS.sal - registered second but as a before event
2. Any_Panel_OnShow.sal - original script if there were no overrides made, or the one from any other mod registered via OverrideEvent method - this also works for backwards compatibility
3. MyAnyPanelOnShow.sal as registered first on After

Do you see my point? Two or more mods can work off the same event at the same time, in order as they registered their interest in handling the event in the mod manager and both can call the original script if the want to via OverrideEvent, or leave it to the engine via Before/After events.
Any chance of getting this minimal functionality added before the release ?

PS> It can be improved further by providing access to the event handlers and event registration lists, but it could make scripting a bit hard on some.

[Karlito]

If i'm not mistaken, we have a "CreatePreScript" functionality, with which you can register a script (method) to an event - and it should fire before the original script for that event.
I'll check with the scripters though

[76561198156207256]

Първоначално публикувано от sinistar:

If I want to write two mods working together, if both are installed, but each one being usable on its own, I can't do it in the current implementation. I can only have one working or the other, or merge them into one.

Sadly, this is correct and current scripting system, at least "advanced" part of it, requires quite some knowledge about the game inner workings.

As Karlito mentioned: we have "CreatePreScript" and "CreateScript" events for some functionalities on some objects but that is for the game objects(like ships, structures etc.) and is not exactly the same what you are asking for and thank you for the nice write-up, your points are spot on. I was thinking something along this lines would be great but unfortunately I am not in charge of it and judging by the amount of other game work that needs to be done I don't think any system besides "script2" and some script exceptions(example: WorldReadyForUse.sal that runs in any mod after the main script) will make it in game any time soon. I will try to put some main programmer attention to it.

[sinistar]

Thanks for the info, I'll have a more detailed look at the two.
Maybe the CreatePreScript and CreateScript could be extended to support a wider range of events? It would be a lot easier to extend existing functionality than to create a new mechanism. I guess we would need to be able to access every game object, including panels, world, etc... and the number of commands would have to expand as well.
Cheers.

[Little Strawberry]

Couldn't there be something like a database file where you define something like this, with the fourth column being your script?

 0 TestKey Data\Scripts\Events\GlobalOnPulse60.sal Data\Scripts\MyCustomPulse.sal

Then just see if a script that is being loaded matches the one in the database and just load that before the original GlobalOnPulse60.sal. This way you could have multiple unique scripts being loaded before the original script, without it having to be modified.

The concept of CreatePreScript seems alright, but you still need to modify a core script in order to fire it off, rather than just a loose file. So the consumer has to be very much comitted to just using one modded script, because it's very likely to run into collisions on scripts like OnPulse.

[Mo¡stDreams]

Tracking this topic for future reference.

I come from various modding scenes, I actually am a little baffeled as to why this scripting language does not have native support for side loading functions of loaded scripts at the very least the ability too override functions within a script on run.

The first is pretty much fundementally the core of extended functionality & modding ease. The later however allows for both developers and modders alike to make minor changes to existing scripts without replacing the entire function or relying on full copy paste. A good example of this is how Starbound uses JSON where a mod can simply override a vanilla scripts function without ever touching the orignal script this allows parts of the script to be replaced and multiple mods to change the same script so long as they do not override the same variable within the script it usually works fine together.

In my case I have extensive expierence working with the SourceEngine and Gmod script.
where if you need to call functions, or register events within another script at the first line of a new or existing script simply do this -

Example: from ULX MOD for Gmod

-- cl.int.lua
-- include some required scripts below
	include( "ulx/sh_defines.lua" )
	include( "ulx/cl_lib.lua" )
	include( "ulx/sh_base.lua" 

-- add functions below
somefunction.name
do-stuff

In example above the script "cl.in.lua" is requesting that the other scripts be included (not run) but they must exist so that this script can call check those scripts and run its own functions which may or may not need to collect infromation from running functions within those scripts.

Another way of doing this is use the "require" method this checks another script or file is loaded and the script functions will do nothing unless that file exists and is loaded.

It would be 200% easier too call a function override it with a priority based system where mods at the bottom are loaded last and override the mods above. It seems tedioud for me to have to update the entire sectors script just to add a few minor changes to existing sectors or add a new sector I should be able to just include the script I want to change then tack on addtional code within my mod that overrides specific lines or adds new lines to the open handle.

[Little Strawberry]

Първоначално публикувано от Misunderstood Wookiee:

It would be 200% easier too call a function override it with a priority based system where mods at the bottom are loaded last and override the mods above. It seems tedioud for me to have to update the entire sectors script just to add a few minor changes to existing sectors or add a new sector I should be able to just include the script I want to change then tack on addtional code within my mod that overrides specific lines or adds new lines to the open handle.

That's what it already does. ModX overwrites ModY if they use the same scripts, depending on priority. Events are hooked through CreatePreScript and CreateScript and you can run external functions by passing a scriptvar or globalvar when executing scripts as functions - if they require data. Kind of like if you're pushing data to a class.

Първоначално публикувано от Misunderstood Wookiee:

It seems tedioud for me to have to update the entire sectors script just to add a few minor changes to existing sectors or add a new sector I should be able to just include the script I want to change then tack on addtional code within my mod that overrides specific lines or adds new lines to the open handle.

Then you're doing something wrong, because new and existing sectors have exactly that luxury by just editing the respective files.

Eg.

Events:	
{	
	OnEnter:	Data\Scripts\SectorOnEnter.sal
	OnExit:		Data\Scripts\SectorOnExit.sal
	OnPulse: 	Data\Scripts\SectorOnPulse.sal
	OnPulse: 	Data\Scripts\MyCustomOnPulse.sal
	etc ...
}

The real issue for me are collisions that come from other mods. Updating them isn't a problem because git basically does that for you, but eventually there's going to be a guy who uses the same file as someone else to initiate his scripts and that's just going to break it. The scripts aren't particular complex to a point where you would absolutely need to include your own script at a specific location. 99% of the times you can get away by just running your logic at the end of other scripts (Although you have to undo some things in your own script then if it's not favourable to have), but even for that there aren't enough diverse events. Ideally, users should be able to attach their own script to any existing script, without the possibility of overwrites happening.

[Mo¡stDreams]

I see the poin. TBH I am just no familier with this API, a lot of the underhood aspects are pretty clouded info still. LUA doesn't have this issue, instead sometimes we just runinto the people using the same logic and it's the two events themselves which conflict with eachother trying to alter the exact same element usually GUI related or something but attaching your code is super simple, you can name the file whatever you want and just call any of the API's events you want to attach a new script too or hook in someway or another.

Feel free to add me so we can learn it together, I am quite interested in understanding this further.