X4 - UI and scripting

[Assailer]

As a mod-maker, I really wish for on-screen custom buttons (single and toggle) to control my scripts.

As a player, I find the current X:RB UI requires too much menu crawling. Are you able to improve on that? Like keep certain windows pinned? Multiple target windows? Drop the single window only style, and allow multiple windows visible when mouse is available?

Are you planning to keep the XML based script editing?

Any plans for multiplayer like Avorion? I'm OK with Coop only, no need for PvP, so i could fight against stronger enemies with my friends.

Please leave out the 'Ren' only male avatar idea. We need females too!

[Snafu_X3]

Please leave out the 'Ren' only male avatar idea. We need females too!

Agreed! Make <player> anonymous so they can be any gender/race as players/modders see fit

[jack775544]

Are you planning to keep the XML based script editing?

Please no, Please no, Please no, Please no, Please no, Please no, Please no, Please no...

I don't think they would be dropping it though

[j.harshaw]

Are you planning to keep the XML based script editing?

Please no, Please no, Please no, Please no, Please no, Please no, Please no, Please no...

What would you replace it with?

God, i hate putting up these disclaimers whenever i say anything. Not saying that we're planning to do one thing or the other. Please don't take this as an indication that we are going one way or the other.

I'm really just curious.

[Xenon_Slayer]

I'll be "that guy" to say it then

Yes, we are keeping the XML based scripting for AI/Missions. UI is still lua script.

[j.harshaw]

yes. but i'm still curious.

[ubuntufreakdragon]

As a mod-maker, I really wish for on-screen custom buttons (single and toggle) to control my scripts.

Yes the custom hotkey from X3 need a comeback.

As a player, I find the current X:RB UI requires too much menu crawling. Are you able to improve on that? Like keep certain windows pinned? Multiple target windows? Drop the single window only style, and allow multiple windows visible when mouse is available?

I want this extended:
A menu mode and a flight mode and a single key to toggle between those hitting it hides all menus hitting it again restores them(like clicking the lower right corner on newer windows systems), because every time you get attacked you loose all you progress in these complex menus.
For controlers this should be manageable too.
Just overload the toggle menumode button holding it down allows opening new windows with the left stick or rearranging old ones with the right stick.
Oh and please add other features filemanagers have, too. There no big difference between handing files in OS and comanding you property, e.g. drag and drop, ctrl click and shift click for fast selection.

Are you planning to keep the XML based script editing?

I wish for a shorter syntax as reading sometimes proves very difficult, e.g. a small translation program that tanslates the xml code into something looking similar to c++/java ist you have two formal descriptions of these languages you can generate a compiler for it.

Any plans for multiplayer like Avorion? I'm OK with Coop only, no need for PvP, so i could fight against stronger enemies with my friends.

Coop is fine with me too, I guess a PVP could be rather difficult because of the fleet sizes that could clash, but don't focus it.

Please leave out the 'Ren' only male avatar idea. We need females too!

Subscribe, and Lars

[Assailer]

Thanks for the answers!

XML works fine, just wanted to check if changes are coming.

I'm wondering what performance you get with XML based scripting. Is that optimal enough?

Modders like me would welcome certain profiling tools. Any chance to get some support built-in for this? That could help learning which are the expensive API calls, and would allow easier performance tuning.

[Xenon_Slayer]

I expect the performance would be similar regardless of which format the script is. The XML is parsed on loading the game, so after that point, it doesn't really have any bearing. Our AI and MD systems are very event driven, so not much happens until it is supposed to happen. It's the execution of the script actions which is where performance can take a hit. Of course, there have been optimisations in the script engine to help. One of which was an early-out for expressions e.g.

Code: Select all

<do_if value="$NPC.exists and $NPC.owner == faction.argon"/>

With the early-out optimisation, if the $NPC.exists fails, then the owner check will not occur.

For the most part though, it's what happens withing the expressions/actions themselves which can cause the most performance impact. This usually leads to optimisations elsewhere in the engine rather than in the scripts or script engine.

[Assailer]

Thanks!

API calls like finding entities or pathing will cause most of the slow downs in scripts. Is there any way to measure how much time scripts spend inside these costy functions?

X4 could automatically generate and save variables for all script instances like __minTime, __maxTime, __avgTime, __schedules

Then, loading the save game into an editor to investigate the gathered performance data could reveal issues with custom scripts. This could be behind by a global variable, which by default is off for normal games.

Some simple scripts can get really slow when you have hundreds of ships if one puts loops inside loops and deep inside using expensive functions. What i generally try to do right now, is to count how many times i run expensive calls and voluntarily give up after 20 expensive calls for 1-2 seconds, before resuming the loops for the remaining who knows how many.

Sometimes i'm wondering if that is making any difference at all, and somewhere else is where the slowdown happens. With performance measurement i could fix at least my scrips

[jack775544]

Are you planning to keep the XML based script editing?

Please no, Please no, Please no, Please no, Please no, Please no, Please no, Please no...

What would you replace it with?

God, i hate putting up these disclaimers whenever i say anything. Not saying that we're planning to do one thing or the other. Please don't take this as an indication that we are going one way or the other.

I'm really just curious.

My day job is programming with Python so I am biased in that regard haha.

Honestly though I think something inspired by HTTP servers in most modern programming languages (Python + Flask, C# + ASP.NET or something else along those lines) since they very much have to deal with event driven programming and I think that they do it in a fairly elegant way.

Overall I found the XML scripts in XR to be rather verbose and at times a bit unreadable.
Out of curiosity, did you ever look into integrating a mainstream scripting language like Python as a scripting engine tool instead of rolling your own?

[Ketraar]

The problem most people that are rather trained in programming forget that many modders (like myself) have ZERO programming skills and still would like to keep modding without having to turn it into a full time job or require degree to do it. So I for one am glad they switched to xml verbose, but somewhat "casual" structure and allow non programmers to do stuff.

MFG

Ketraar

[Assailer]

Overall I found the XML scripts in XR to be rather verbose and at times a bit unreadable.
Out of curiosity, did you ever look into integrating a mainstream scripting language like Python as a scripting engine tool instead of rolling your own?

XML allows nice patching features and i think it is important to keep, but adding python besides LUA would be great!

[Moncada]

I agree with Ketraar that the "casual" way it is now good.

[Killjaeden]

it's awefull to look at and difficult to read at a glance due to the excessive use of special characters and pointless repeating...

Another reason why (regardless of me liking/ not liking XR gameplay) i would never consider modding it... xml gives me eyecancer.
Different formatting to basically every other mainstream programming language.

X3 SE code was much more readable than this <comment/> <make_italic/> <text="mess"/></make_italic></comment>

The base principles of scripting one still has to learn, so i dont see how xml is somehow more user or modder friendly there. When you dont expose stuff like pointers and instancing and whatever most mainstream languages are extremely simple to read. (without resorting to spamming the same lines all over and over like xml does.

XML stays readable if you remove all tabs, new lines and spaces. Yes. But who codes or reads like that? Nobody in his right mind. So if you use proper readable formatting anyway, xml is forcing you to carry dead weights through your entire script.

[Sparky Sparkycorp]

even X3 SE code was much more readable than this <comment/> <make_italic/> <text="mess"/></make_italic></comment>

Why would you try to read things like that line when you can stick stuff in something like Notepad++? That makes it look harder than it is.

[Killjaeden]

Why would you try to read things like that line when you can stick stuff in something like Notepad++?

Oh yes it shows the tree view for you. So why did you choose to xml it up in the first place like that? XML is like removing all Text formating and instead describing it with words, so the tools can then interpret your words as formating. Does that sound usefull to you? To me it seems like a giant waste of time and space.

Code: Select all

<reply>
	<sentence>
		<question>
			<string ="why do you need this bollocks when you format it eitherway and therefore context is given already without need for this bollocks"/>
		</question>
   <new line/>
	<sentence>
		<statement>
			<string = "This is a waste of time to write and read and does not help comprehension one bit"/>
		</statement>
	</sentence>
</reply>

[jack775544]

The problem most people that are rather trained in programming forget that many modders (like myself) have ZERO programming skills and still would like to keep modding without having to turn it into a full time job or require degree to do it. So I for one am glad they switched to xml verbose, but somewhat "casual" structure and allow non programmers to do stuff.

MFG

Ketraar

That is a fair enough point, but I think you underestimate the ease of use that some mainstream programming languages have. Python is commonly used to introduce programming to high school students nowadays, but at the same time it is powerful enough to be used by almost every large tech company for some role or another.

[Taleth]

Quite dissapointed with the responses here. XML scripting should be retained as a legacy scripting method. But scripting/modding should be done through a proper programming language like python or even better, C#.

See the most modded game on Steam, Space Engineers, for an example of how this works very well, even for people who don't yet know C# it can be picked up easily. It's not difficult at the outset and the tooling support for it is far and away better for a staticly typed language then for XML which speeds up learning.

There is a game called 'Empyrion Galatic Survival' which supports this style of modding, with it I managed to send the events generated by the game to a message bus (MSMQ) which is read by a webserver that hosts a single page application. Imagine a dashboard like this http://wrapbootstrap.com/preview/WB0R5L90S to get an idea of what I'm talking about. Keeping in mind this is accessible from any browser like your phone, the steam browser or your smart tv. Imagine it populated with data from your ships, stations and warehouses ... yeah.

[CBJ]

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.