[Nuke]

knowing who the host is may still be useful in some cases. im also asuming that a dedicated servers could handle multiple games simultaneously, which would also add complications. you wouldn't want data from 2 different games getting crossed. the jist of it is you want scripters to be able to explicitly say what code gets executed where, the more information they have about the network state the better.

[AdmiralRalwood]

im also asuming that a dedicated servers could handle multiple games simultaneously, which would also add complications. you wouldn't want data from 2 different games getting crossed.

I don't see how you'd get data from 2 different games "crossed" unless the script was somehow running only one instance for every game, rather than one instance per game, which sounds like a bad idea to begin with.

That, or you're writing your data to a file, which is named the same regardless of which game it is, which also sounds like a bad idea to begin with.

[Nuke]

im also asuming that a dedicated servers could handle multiple games simultaneously, which would also add complications. you wouldn't want data from 2 different games getting crossed.

I don't see how you'd get data from 2 different games "crossed" unless the script was somehow running only one instance for every game, rather than one instance per game, which sounds like a bad idea to begin with.

That, or you're writing your data to a file, which is named the same regardless of which game it is, which also sounds like a bad idea to begin with.

i was just trying to point out that you need multiple instances. inter-instance communication should be avoided and should keep their namespaces separate. you might have a global stats database on the server that handles player information for multiple games, but that would just be a matter of checking to see if the file was open, and if it was, wait for it to close to write the stats (scripts would need to be careful not to leave it open for too long).

[karajorma]

Standalone servers can only host one game actually. So that's not a problem.

[Tomo]

The underlying concept of this thread is quite widely used in other circumstances.

Basically, all the logic (SEXPs) is implemented by small scripts, which comply with some basic structure:

• Basic script "type" (defines parameters and return type(s) of evaluate function, and how it gets called)
• Input parameter definitions
• Output parameter definitions
• "Hooks" to call other scripts
• Functions to return a name, description, and short help text
• "evaluate()" function that's called at runtime

The editor uses everything except "evaluate()" to build up what parameters etc to offer the user (Ship list, integers, floats, bools, vectors etc), how to display it in the editor, the 'hooks' for sub-operators (eg what to do when True) and finally to offer the user help on what it does and how to use it.

I don't think the current scripting system bears much resemblance to this though.

[Iss Mneur]

What you outlined is more or less how the sexp system already works, but it is not "object-orientated" as you outlined.  That is, rather than asking the sexp class (object) what the input types are (for example); the current system runs the global "tell me the input type" of sexp number x.

[Tomo]

Indeed, and I think that's necessary.

If this is to happen, then it would need to transparently replace the existing SEXP engine with identical functionality using the existing mission files, without needing to 'upgrade' them - whether automatically or not.

So it needs the structure to be very similar to the existing SEXPs, but easily expandable by writing LUA scriptlets to add custom functionality to mods.

As far as I can see, the key gain from this idea is to make it really easy to share and re-used custom scripted functionality without those other FREDders needing to know how to write scripts, all they need to know is how the event editor works.

[Nuke]

way i see it you could set up your mission events in one of two ways. Legacy mode, which is needed to support vanilla and all prior mods, where you have the pseudo-lisp code you have now, which would be compiled to either textual lua or lua byte code. Then you have pure lua mode where you can write lua based events entirely (possibly with some kind of gui).

This has some cool possibilities, like global events, which will effect every mission in a mod. you can stick event code in a somefile-sct.tbm (in an $On Event Evaluation: hook), and it will run for every mission. if you dont know or have no desire to learn the new system, fine, just use legacy mode, have the game dump the lua code generated for the mission, and from there its just a cut and paste job.

another thing is seamless integration with other scripts. communication between events system and the rest of the scripting environment is simplified. you can call global functions, you can access global variables and tables, etc. this also means that scripters can create new libraries of events that fredders can put to immediate use (they would register with fred and show up in the events window).

having two modes also simplifies learning of lua. you can set up your mission events in legacy mode and immediately see what that same code looks like in lua just by dumping the code. so progressive minded fredders can ease into the new environment.

probibly the best reason for this is you can discuss game events with outsiders without sounding like a pervert