Modding: Scripting vs Mission Director

[Boringnick]

I recall that during the release of X-Rebirth quite a few veteran modders were angry because the scripting-system apparently changed for the worse.

I am not sure that large plugins like Pirate Guild, ADS or Race Response Fleet can be put into X:R at all. They removed the script engine in favor of the Mission Director system. There’s pros and cons regarding this system. Pros being you can actually type it on a notepad. Cons being that’s it’s the most horrible scripting language i have ever seen (and god i’ve seen plenty) and that it doesn’t scale well with large projects. If someone manage to achieve something along the line of Pirate Guild with it, Egosoft should hire him (or burn him as a witch, i don’t really know).

So yeah, quick fixes from the modding community, sure. Overhauls, and years of additional gameplay not so much sadly.


https://www.anarkisgaming.com/2013/11/x ... ther-news/

This guy made some of the most prolific X3 scripts, I guess he knows what he's talking about. Any comments on that? Was the script engine more powerful than Mission Director, and if yes, will it come back with X4?

[X2-Illuminatus]

Quoting CBJ quoting himself on this one just recently here:

Since all of it still applies, I will quote the answer I gave last time this discussion came up:

Some of the original reasons for choosing XML for the MD were:

- Domain-specific structure (it's laid out in the form of the conditions and actions required for mission progress) and syntax (many of the conditions and actions are directly mapped to mission activities rather than just being generic programming terms)
- Missions can be created with very limited programming knowledge (while it's possible to do programmer-y things like loops, it is also possible to create simple missions entirely without this, which helps with the learning curve)
- Editing comes with built-in self-documentation as well as syntax auto-completion (most self-respecting XML editors understand schemas, and the schemas can also be used to provide the documentation)
- Easy to parse and convert to internal format (it is loaded and parsed very simply using standard XML libraries, then converted into an internal form that is that is, like the raw syntax, closely tied to its purpose, rather than using a generic third party interpreter or JIT compiler)

Now, bearing in mind that we have been working with the MD, in one form or another, for nearly 10 years, the reason we continue to use it is very simple: we have it, it works, and it does what mission developers need it to. The AI scripting system shares some key elements, such as actions and conditions, with the MD, saving a lot of effort in maintenance and development, but is, again, tailored to the task in hand. It would be a very poor use of developer time to throw all that away in favour of something different, with all the issues and unknowns that would come with it, just because some people turn their noses up at it for being XML rather than a "proper" programming language.

[euclid]

........Any comments on that? Was the script engine more powerful than Mission Director.......?

No, it is not.

The XML scripting is easier to handle because you can code outside the game using Visual Studio (that's what I'm using) which provides a better overview even for many lines of code. The command structure has been extended although some commands (like all the key assignments and related features, the menu generation etc.) are missing (yet).

The MD has been vastly improved and is a very powerful tool because it allows scripts to be triggered on defined events only rather than running in the background checking/waiting for conditions to be met.

But those are only my views in this matter

Cheers Euclid

[Skeeter]

I once wrote a mission for star trek legacy using vsb in c#, forgot most of it now but was fun learning how to, tho i used a empty template and had help, dunno if i could write somit from scratch.

Is/will x4 scripting/md be easier than that. Also that helped alot was that i knew terminology cos it was trek stuff. I know x games but not to that extent knowing every single reference u can think of in trek. Is there a sorta bible that people use where it lists what things u can writee it scripts etc.

Think i once opened a xml from somit in a x game to see how it was, i think vsb looked simpler than xml work.

Does x games have a map editor where u can go in the game and straight to empty space so u can make ur own maps in first person and place items like nebula here, a station there, a ship for a mission spawn here and follow this path and do ingame cinematics with camera points and rails. Or is that rather different from stl mission making stuff.

[Sparky Sparkycorp]

Also that helped alot was that i knew terminology cos it was trek stuff. I know x games but not to that extent knowing every single reference u can think of in trek. Is there a sorta bible that people use where it lists what things u can writee it scripts etc.

The Argonopedia has a lot of game lore in it. Not sure if that entirely answers your question though as I am not a modder.

[Skeeter]

I wouldn't have thought so no, not for scripting purposes at least.

[euclid]

No Skeeter, there is not (yet) a tool to create a map like we had in X3. However, all of the modding features are listed and explained on the Wiki site.

Cheers Euclid

[JSDD]

the main problem with the xml-based scripting is its uglyness to write code in a way that you (or another scripter) can understand quickly after a week or so. the code tags make the whole thing more "unclear". xml is not the problem, the way we have to read / write code is. in X3 the msci script editor was also xml-based, but at least the (ingame) editor didnt look like xml. it was procedural code, one line executed after another. very easy. MD was not that easy, you had to write the code with external tools (visual web developer), then testing your code required you to reload the game, code wasnt always executed "line after line" (for example a cue with a <timing> executes its <action> AFTER a child-cue / sub-cue if it hasnt <timing> etc), it was an event-based tree-like structure ... very ugly stuff to overview ...

one solution would be to create a script editor like that in X3, either ingame of external tool, but something that allows to program procedurally (non-event-based) code.

[Kitty]

the main problem with the xml-based scripting is its uglyness to write code in a way that you (or another scripter) can understand quickly after a week or so. the code tags make the whole thing more "unclear".
...

Well... reading and writing xml, as long as it is just standard, simple xml, not a "xml but with only one space there, and a tabulation there, and you cannot have a carriage return over there, because, and..." ... it's just easy now.

So... if this XML language of X4 is a mess, I'll just write my own parser/coder to translate a simpler language to and from XML.

The real question is not about XML, but about what we'll be able to do with it. X2/3 scripting was genious and evilish. Genious because we could do many many things, including change things from within the game just by scripting what we needed on the spot, no need to reload. Genious because of its error-free coding (could not mispell an identifier!). Evilish because just a pain to use, could not be coded from outside, and some limitations (cannot read logbook, cannot access to some sector data (never found the solar exposition), etc).

I hope next one will be better. I know that I will cry for some missing or lost features. I hope that the imrovements will be better than the losts. I'm eager to know.

[iforgotmysocks]

I don't understand it at all. I haven't had that much fun modding any other game. the md and xml based script language are easy to learn and the argument that it's not cut out for large projects is a streight up lie. The fact that he makes those false accusations shows me that he didn't even give it a try.

Ppl were too lazy to adapt and they're missing out big time, cuz it's hella fun.

Oh... and i would never be able to understand why someone would choose a clunky ingame editor over visual studio when a mod may consist out of lots of files... or even the fact that someone might code at places where he can't run the game.

[UniTrader]

@JSDD
well, the Documentation iirc stated clearly that when che <conditions> for a cue are fulfilled it first creates its child cues, then waits its delay and after that performs its actions. if the child cues have to perform after the parent cue completed just put that into the conditions (either as <event_cue_completed cue="this.parent"/> or as <cue_is_complete cue="this.parent"/> ).
Also <actions/> are performed line after line, and in these you have your classic procedural code. i think your Mistake is that you try to force this upon the whole of MD, for which it is not really intended. Also you might have a look into the AIScripts, which are more like the procedural programming you want so much, but also has the option to use events like MD, either globally for a script or as interrupt for each blocking action.

[Xenon_Slayer]

Keep in mind that the MD isn't the only scripting language we're using. The AI variant is also written in XML but is structured in a more traditional fashion. The two are similar in that they use much of the same syntax and functionality, but they are used for different things.

The basic difference is that AI scripts are run on a single entity e.g. a pilot. When the script starts, it executes all the actions until it hits a 'blocking action' which takes time e.g. a move_to action. When that action is done, it resumes the script actions. You also have a 'call-stack' of AI scripts.

MD is not directly tied to an in-game object. Scripts are usually written in a way that they can be instanced for multiple of them to be running at once e.g. multiple Transport Passenger missions in the same area. And because a cue can have multiple subcues, there is branching within the scripts. That means a single MD script could be instanced several times in the game, while each has many cues doing different things at the same time. It's powerful, but yes, may not be the easiest to get an overview on.

There are a few actions which are exclusive to AI (e.g. the blocking actions) and some which are exclusive to MD (e.g. the mission creation actions).

As for editing the scripts, while I did start with the MSCI in X2, I've been working primarily with MD since early X3TC development. I'm comfortable with Visual Studio and the XML schema but I do see how it can be unweildly or ugly to look at. If someone could come up with an editor which hides the XML, that sounds pretty nice. I'm probably just set in my ways at this point

[iforgotmysocks]

I wouldn't change a thing. It's awesome.

For X4 i'd only wish for more transparent OOZ dmg calculations that can be influenced a bit more. Currently is really hard to balance OOZ and IZ combat strengths of new ships, especially if missiles are involved. (it's possible by abusing a bug in the missile dmg calculations, but it's such a hassle)
The ability to adjust more with <get/apply_attackstrength/> would be awesome.

[Morkonan]

I'm no codemonkey. I'm also not an X game modder. But...

Mods are a value-added component for developers. They're extra content the devs only have to pay a one-time cost for, in general. After release, and normal development concerns, the devs can make use of free labor to enhance their game. (Or break it, depending on the quality of the modders and the game's suitability for modding.)

What I would like to see is a launcher/whatever that makes adding and removing mods easier for the player. I understand removing mods from existing games is usually A Bad Thing ™ depending on how the game works and what scripts may be called in the saved game files and all that, but that's not a huge issue, really, for players to deal with . Most understand that removing certain types of mods can corrupted their game's save files.

BUT, the point is that a good mod system can drastically improve the game's appeal to new players and can increase its longevity for veteran players, making it more likely they'll still be playing it when the next DLC pack comes out for purchase.

Mods need to be easy to apply to a new game. Some sorts of mods, like simple ones that add a new ship, should be easily added and removed.

The process should include a way for the user to see, quickly, if there will be conflicts between mods or what the mod actually effects in the game. Applying multiple mods should result in a visual display of how the game will be effected, listing what items have been overwritten/changed.

The launcher/whatever should warn the player when there are mods that contain custom scripts or other immediately noticeable traits that will make it impossible to remove without corrupting the saved game.

Mod files should have full description and flavor text and these should be displayed to the player in the launcher, so they can get important information regarding what the mod does and what they should expect. A gamer applying 1_awesomesauce.xrev098_.mod isn't getting the same initial experience as the gamer who applies "X4: The Revenge of the Split - A long time ago, in a galaxy far away..." That's true even if it's just a description text displayed next to the mod's entry in the launcher.

TLDR: If modding one's game is easier and if the launcher/whatever does some limited troubleshooting and provides good feedback to the player, then it increases the value of mods all-around, both for the player and the developer. Clunky or problematic mod systems or those that offer little or not feedback to the user do not provide the same opportunities. Well polished, user-friendly, mod systems can reap tremendous rewards for all involved.

[X2-Illuminatus]

Installing mods for X Rebirth using the Steam Workshop is pretty straight forward. You just click on the "subscribe" button in the Workshop and the mod will be installed. The Workshop allows to add descriptions and screenshots. The mod description itself can be provided through the mod's content.xml and is displayed in the game's extension menu, too. Dependencies can be defined by the mod author and will be checked together with the game version by the game, when starting it.
Detecting problems in and between mods is not really possible or viable to check, as the possibilites to change things are (almost) endless. Mind though that X Rebirth's file structure is much more modding friendly. You don't have to edit and replace whole files to add or change single items (as you have to in X3), but can patch and replace just parts of them.

[Morkonan]

Installing mods for X Rebirth using the Steam Workshop is pretty straight forward. ....

Thanks for that. I don't have XR, so just have my X3 experience to draw on. I do have a question, though:

Why is it difficult for a launcher/configuration utility to check for conflicts? I don't necessarily mean for conflicts in an ongoing saved game file, but for overwrites, substitutions and resulting conflicts, if any, between mods and the original game files?

I realize, somewhat, what doing that would mean if the game isn't already set up to get that information easily. But, why isn't it "doable?"

[CBJ]

Because, as the previous poster just explained, modding in XR (and X4) doesn't just involve overwriting or substituting files. You can also "inject" changes into existing files in a variety of ways which may or may not conflict with one another. The benefit of this is that it means far fewer conflicts; the downside is that what conflicts do remain are almost impossible for the game to detect.