PRPL/CRPL Changes

[GoodMorning]

After working through the stock missions and roughly a third of the exchange so far, I have begun to examine scripts, to see what has changed.

Thank you Virgil. A quick read-through of the scripts for planetfall's Decoupler and FlipCannon immeditely showed superficially small but immensely powerful improvements.

Globals: <-*Var and ->*Var
List indexing: <-List[<-index]
Unit attribute access: <-UID.Attribute and ->UID.Attribute

Use of SetScriptVar doesn't yet seem to have followed this convention, so I hope to see something like UID.Scripts.<script>.<var> implemented. "UID.Scripts" to prevent issues if someone creates a script called "UnitEnergy" or some similar thing.

I also noted that the wiki has partial documentation in a form suggesting local saves of the docs, accessible in-game. I'm not sure how well that will integrate with Notepad++ or the other editors, but it holds promise.

Now to see what we can do...

[GoodMorning]

Considering how to make ship PRPL play nicely with sharing:

I suggest a PRPL module. This would be able to have one or more small images attached for graphical states, and one or more scripts.

The entire ship would then have a Core list, with processing order determined by position within the list. Optionally, scripts could be attached to the bridge for pre- and post-processing (Ex: energy). Standard modules would have an entry in the list, all processed at once.

This would integrate the Core module for more neatly into the ship structure, and provide a way to get exactly the behaviour desired within the ship. It would also allow for relatively easy use of multiple custom modules. This is in contrast the the "ship rider" cores which Planetfall has used in some exchange maps.

Each module would need to be saved, with images and scripts, into an extractable file, which could then be shared. Each ship would probably want to maintain a list of modules onboard, either replacing Core modules or "deactivating" them.

A nice additional feature would be the ability to create "families" of modules, which could be exported together.