if you have scripts running that may interfer with others this trigger will go off with a right click load script or from a hotkey etc.
Thought Id pass it along.
btw the parameter requirement stated in the script.html is incorrect so dont bother to mention it.
:start
killtrigger scriptstarted
setEventTrigger scriptstarted :scriptstarted "SCRIPT LOADED"
pause
:scriptstarted
ECHO "*STARTED*"
goto :start

So that will fire with any script load. Didn't we find the correct usage for that command, so it would fire for a specific script? Wasn't the Parameter the full path or something? I'm hazy on the details.

+EP+

I assume this is the same for startup as for shutdown. Here is a little snippet of code I use to know when an external bot script has died for some reason. Hopefully this helps.
Obviously this is not an entire working script. I just included the usage of the command.

MD

the problem with the command for most usage was the need the have exact syntax for a particular script and the way the twx vs windows handles file names........._ck_sdt.cts....will not work ...._CK_SDT.cts does it has to be what shows on the screen which varies depending on how you load it at  least on my machines....right click load vs load "scripts/_ck_sdt.cts" vs load _ck_sdt....if path is included then path must be in trigger parameter.
So for each script that a bot loader script i wrote i did a $script variable for both the startup and terminate command then feed it into a subroutine to ensure..yes it started..then yes it terminated..else i had the script force a termination.The command doesnt have a lot of uses with the parameter in 2.04b or before because of this issue except for making sure u dont have 15 callsaveme's running...I hate that.
But its use as a generic trigger that fires every load command combined with the new activescripts command can solve many issues such as turning on and off triggers with certain scripts running...an IG check on xport for example when you start a red cashing script .Well you get the idea.
:btw the parameter requirement stated in the script.html is incorrect so dont bother to mention it."
I was refering to the statement in script.html that you MUST have a parameter to work not that parameter statement didnt work it does as long as syntax is exact.
 
 

Ok, but I am not really seeing the purpose of using this, if you start a script it will start, if you stop a script it will stop. If it does not do that then this function will not do it for you either because the script is either A. self terminating from error or B. the script is was not found; therefore you have potentially placed yourself in an infinite loop of trying to start/stop a script. It does not serve any real purpose a redundancy checker either, as this is a very basic task for the script to handle quickly.

The snippet from MD, that one has a purpose, it waits for a script to stop, then it takes corrective action, it could even potentially be used to run through errorlevels and send macros to possibly get itself out of the script terminating predicament.

Ok rexx one more time....
Simple example below
Script A checks status of IG on Xport to another ship.This is a good thing.
Script B is a SST script. See the problem?
using the above snippet in conjunction with the active script commands
suspend IG check till SST is finished.
 
Triggers dont cause unending loops rexx read the snippet again.
 
If you dont write complicated multi layer/function scripts that interact it will of little use.If you or your corpies have never started a cashing script with saveme running ok I agree with you however this will allow for almost unlimited error checking before someone warps out of sector and get Sd'd

If you've designed and developed all of your own scripts, the above is possible.

For most however it isn't, as they use a patchwork of scripts. It's impossible to stop a script when you don't know about it.

I, personally, have never ran worldSST while running a saveme. Why? Because I check what I'm running ($si) before running anything new. Part of me thinks that it's a user's job to check their own stuff, instead of relying on a script to do it all... which is inherently dangerous.

Ok, I think I see were you are going with this idea, but I also think you are over complicating it. I know triggers do not loop, though the only practical way that I could see using that code would be in (again) a "POTENTIALLY" looping situation, otherwise just include the basic code and send it in the script you are firing up, whenever a potential conflict may occur, you would want to run a check to ensure conflict is not going to occur, if so then you handler it. But, that code snippet just runs a echo (or whatever code) whenever any script is loaded... how does this do any of the things that you aforementioned?

Laff... if you set a start trigger that loads a script and resets the triggers, but one of those triggers triggers on a script that's being loaded then you'd have a loop... as the load would load another, and another, and another.

Yes if you're a bit of an idiot and code yourself into a corner like that, you can expect bad things to happen. There's a simple solution tho: Don't write bad code.

What's this nonsense about triggers not looping? Of course triggers can loop.

:hello
setTextLineTrigger hello :hello "Hello"
send "'Yo, Hello*"
pause

LMAO, yea Sing when you put it like that. heh

 
Quote  "It's impossible to stop a script when you don't know about it. "
             of course you can.
I am not here to debate where the trigger works and / or the idea is viable.It does and it is.Already done it so arguement to the contrary is moot.Just passing on info to those who might use it.
Dont want the information? Dont use it.

 

Ok, so basically whenever a new script is loaded you have a bot or whatever that is say 'systemscript' and that then runs through the script menu as below and then array's all active scripts if more then one match is found then the last on the list working it way upward is halted, and doing it this does not effect active scripts as it is being accessed through the internal TWX submenu's. I offered a very simple alternative that checks a variable to see if it already active if so then it is to self-terminate; but you discarded it stating it was not an appropriate method to use... which of course I very much disagree with, BTW.

Though to terminate a certain script that you do not want running in conjunction with another script you have to tell it which script to terminate, the script will not know that on its own. It sounds like you are trying to make it somewhat automated by going through the submenu's and looking for script A and script B if so then terminate script A, when all you need to do is put that stop code into the script B, so much easier.

You cannot stop a specific script if you don't know it's function, otherwise you risk killing the wrong script. I figured I didn't need to explain that, but I guess I do.

Given the names of scripts these days you can't possibly hope to predict every single script variation. Take a simple ptorper as an example. Do you want to be running that if you're not in the citadel? No. But can you stop every single ptorper under every single name? Of course not. You really want to even try? And then do you want to stop every single other script that could possibly be out there that runs from the citadel?

As for why you're here, that's up to you. Of course the trigger works. And it has it's uses, like waiting for 1 script to end before resuming a main script's function. If you're going to be passing out info tho, please make it info that's accurate. I hate cleaning up other people's messes.

If you know what a script does and that script's name you can always terminate it. Now if there are duplicate scripts you can terminate it. Heck, you can always just terminate them all. But how are you going to terminate a specific script if you don't know what it does and what it is without possibly killing another non-harmful script?

ok rexx your idea is to save a variable when a script starts then check it.I see where this will work unless you have an abnormal termination that prevents the resetting of the variable.The activescripts command that EP added works very well take a look.Your variables are internal now and abnormal termination is not an issue any longer.As for dupe scripts I posted a subroutine to handle that issue in another thread.
 
ok Sing I didnt get your point before.I believe you were speaking of the total realm of scripts out their and all their names.I use the function within the limited subset of what I use which are 90 percent my own scripts at this point so I know the names and I also know what my corpies are running i.e. ck public scripts and so forth.So in this limited use the trigger allows for error checking to some degree and as the scripts I use the most are becoming multifunctional I perfer as much error checking as I can get before handing them out.The information origanally posted was on the syntax of the command and of course was completely accurrate.Any discussion about its possible use only furthers my own very limited knoweldge of the subject at hand.
 
Example of one possible use however.Red is running TurboSST...Hunter warps in.Red hits his escape hot key which starts a mini escape script.Turbo sees that another script (any script) has started and suspends pending shutdown.Just an example of function.no need to go on and on about how this or that is better etc.

Yea abnormal termination is a potential problem that calls for the need for a reset script, unless you also 'systemscript' a trigger to watch for the termination of that script, if so set and save that variable. I do not not yet know how 'listActiveScripts' functions, although I just tried to it in both an array and as an echo several times, and all it is doing is echoing "listActiveScripts", I also tried to use 'getScriptVersion' and it is doing the exact same thing, is it working for anybody else, if so in what context?