Suggestion: Community Mission Editor

This forum is the ideal place for all discussion relating to X4. You will also find additional information from developers here.

Moderator: Moderators for English X Forum

User avatar
Killjaeden
Posts: 5366
Joined: Sun, 3. Sep 06, 18:19
x3tc

Post by Killjaeden » Tue, 17. Apr 18, 19:50

Dynamic sandbox missions can become really convoluted and messy, compared to linear missions. You can't just spawn stuff or hardcode a specific location (e.g. a station) in a fully dynamic world. The missions need to draw almost everything from the running game by evaluating current state via conditions (Example: Find me a ship that is a trader, has no cargo, is on route to station Y - whereby Y is a factory with ressource deficit in a friendly sector, has no ships landed, etc etc) Lots of conditions. And lots of conditions means it can get extremely nested and complicated.

This is where "node tools" come in super handy to visualize very complex structures in a lot more digestable format than with pure text. Arma uses FSM tools for AI scripts, because AI need to check for a lot of conditions, so a script in pure text form becomes really nested and convoluted -> hard to read.
AI example,Mission logic example

Imagine these examples in pure textform. Yeah you could totally write those. But how long will someone else take to fully understand it then? Or how long will you take until you understand what you did, once you have put the mission aside for a few weeks?
LittleBird wrote:You are mistaken. He meant both. And I disagreed with his last point that the code would be more time efficient.
My point was that the user will use whatever is more time efficient - in accordance with his skill level. If the tool is more efficient than writing code in text editor, most people will use that. If not, beginners will use the tool (most likely) and discard it later on.
[ external image ]
X-Tended TC Mod Team Veteran.
Modeller of X3AP Split Acinonyx, Split Drake, Argon Lotan, Teladi Tern. My current work:
Image

User avatar
Ketraar
EGOSOFT
EGOSOFT
Posts: 11741
Joined: Fri, 21. May 04, 17:15
x4

Post by Ketraar » Tue, 17. Apr 18, 20:33

Thats why there are Libraries where you can define these "search parameters" (or anything else that repeats often) for reusage (I know its not a word, before the spelling police pesters me again). :-)

MFG

Ketraar

User avatar
JSDD
Posts: 1378
Joined: Fri, 21. Mar 14, 20:51
x3tc

Post by JSDD » Tue, 17. Apr 18, 23:43

@littlebird:
without a tutorial, a documentation you can read / get, figuring out how MD works is like going to the pyramids in egypt and trying to read hieroglyphs ;)

you dont know if and how you can insert / remore code words, how to even begin ... where are the possible code words listed, what the hell is "auto-complete" and what is "visual web developer" (maybe a job descriptiion ?? ^^) thats how i started to learn MD ...

whats important:
--> a well documented scripting language (by egosoft)
--> a getting started guide, some little examples / tutorials
--> tools to validate / type-check the mess you wrote (thats where xml comes in handy, but still ... eyecancer-ish to read)


one might say that even the procedural code can be as nested as the MD, stuff, BUT you (often) can re-write that into not-soo-nested code easily:

Code: Select all

while true

if (A and B == C)
{
   if (D or E)
      dosomething();
}
else dosomethingelse();

endwhile
rewritten to:

Code: Select all

while true

// un-nest this case
if not (A and B == C)
{
   dosomethingelse();
   continue; // jump back and ignore the rest ...
}

// un-nest that case
if (D or E)
{
   dosomething();
   continue; // jump back and ignore the rest ...
}

// and so on ...


endwhile
even better, gosub endsub is available to wrap sub functions away from the bigger picture. thats another thing which isnt possible n MD (at least in x3 as far as i`m aware of, library cues arent comparable to that, @call script is another type of wrapping away code parts by reusability [or just to make code readable])

this type of writing code (filtering first all the abort-conditions) is my favourite and allows you to handle each abort case without having to add a new cue which takes care of cancelling all the others (just in case), and hopefully not 2 parallel cues do the same job at the same time resulting in undefined behavior (and debugging that mess afterwards) ... a mess! you cant really use that xml / MD language to build a big & complex system in a way so that a year later, littlebird can modify it in a way she/he wants to (maybe to improve it) because nobody will be able (and willing !!) to read that mess anymore
To err is human. To really foul things up you need a computer.
Irren ist menschlich. Aber wenn man richtig Fehler machen will, braucht man einen Computer.


Mission Director Beispiele

UniTrader
Moderator (Script&Mod)
Moderator (Script&Mod)
Posts: 14571
Joined: Sun, 20. Nov 05, 22:45
x4

Post by UniTrader » Wed, 18. Apr 18, 00:45

@SirNukes
your conversion is very, very inaccurate. <conditions> are very diffrent from a <do_if/> if they are events. Event Conditions dont check something periodically, rather they leave a marker on the Object of intrest that they want to know when something happens and then go to sleep until said object tells them the Event they waited for has just happened. (in case of <check_value/> it might apply in a limited way because these are checked on events or periodically, but you still leave out the cue states entirely which makes any simulation you might try invalid if these are relevant, which is often the case even if not used explicitly)


JSDD wrote:even better, gosub endsub is available to wrap sub functions away from the bigger picture. thats another thing which isnt possible n MD (at least in x3 as far as i`m aware of, library cues arent comparable to that, @call script is another type of wrapping away code parts by reusability [or just to make code readable])
not sure why a lib cue doesnt fit for you, but you also have the option of putting said code in another cue and <signal_cue/>
JSDD wrote:this type of writing code (filtering first all the abort-conditions) is my favourite and allows you to handle each abort case without having to add a new cue which takes care of cancelling all the others (just in case),
If you do a Mission properly each instance of it should have its own root cue instance. cancelling this instance also cancels/removes all sub-cues of it. And you can put as many abort conditions as you want in a single abort cue, no need to make extra cues for that (except maybe the cleanup actions differ wildly)
JSDD wrote: and hopefully not 2 parallel cues do the same job at the same time resulting in undefined behavior (and debugging that mess afterwards) ... a mess!
if you do the same job in 2 cues you do something wrong. as said before you can put said actions in a seperate cue and signal it for each case its needed. if it is not instantiated or resets itself this even takes care that its actions are only performed once if desired.

JSDD wrote:you cant really use that xml / MD language to build a big & complex system in a way so that a year later, littlebird can modify it in a way she/he wants to (maybe to improve it) because nobody will be able (and willing !!) to read that mess anymore
your opinion. i find it really nice that all the conditions for an event are directly next to the actions it causes - which is very diffrent from the lua files for the UI where you have to go to an entirely diffrent section of the file (scrolling down to almost the bottom to find out under what conditions the code in the top third is performed) - that is a mess i tell you...
if not stated otherwise everything i post is licensed under WTFPL

Ich mache keine S&M-Auftragsarbeiten, aber wenn es fragen gibt wie man etwas umsetzen kann helfe ich gerne weiter ;)

I wont do Script&Mod Request work, but if there are questions how to do something i will GLaDly help ;)

SirNukes
Posts: 546
Joined: Sat, 31. Mar 07, 23:44
x4

Post by SirNukes » Wed, 18. Apr 18, 02:50

UniTrader wrote:@SirNukes
your conversion is very, very inaccurate. <conditions> are very diffrent from a <do_if/> if they are events. ...
Interesting. As mentioned, it is just spitballed code by someone who hasn't worked with the Rebirth MD (or much with the X3 MD). That said, I took a look at the short Rebirth MD overview document, and I don't think anything needs to change in the example python representation. Logically, the conditions do map to an If construct.

If you are curious on how simulation might work: the @cue decorator would find the event triggers on function construction (ast parsing probably is the most reliable), and would then handle cue state annotation, registering the cue with the system, etc. Runtime handling of events would briefly set their corresponding value to True while calling each of their attached cues, so that the If conditions evaluate as might be expected by any user who has a breakpoint attached.

The more I think about it, the more compelled I am to put it together for lols. :) (Or to utterly fail and learn from the experience; either is good with me.)

adeine
Posts: 1087
Joined: Thu, 31. Aug 17, 17:34
x4

Post by adeine » Wed, 18. Apr 18, 15:47

SirNukes wrote: The more I think about it, the more compelled I am to put it together for lols. :) (Or to utterly fail and learn from the experience; either is good with me.)
You should! Even if nothing comes of it, this is already way more legible than the xml.

Snafu_X3
Posts: 4472
Joined: Wed, 28. Jan 09, 15:14
x3tc

Post by Snafu_X3 » Mon, 30. Apr 18, 06:32

A thought occurs:

Is it possible for MD to utilise orbital bodies (moons, planets etc) as points, now they're visibly moving? If so, MD could be enabled to create missions with time /constraints/ (ie not simple time /limits/)

Eg mission-giver 'Require xyz <stuff> by date/time <t> as <orbital bodies> align'. If passed goto reward; if failed goto <loss of rep>; if missed goto <next_time> (if mission is not cancelled by <player>, but loss of rep still occurs). <next_time> can be calculated ofc from the bodies' orbits, & a reminder flashed up on <player's> screen (or not :))

--------------------------------

I can see a suitable utilisation of 'instaspawn' missions as OP suggests (sorry GCU!), but /only/ in areas far out of station/ship scan range, & they should have appropriate infrastructure (eg hostile base of appropriate size given game difficulty lvl/size of spawn) to support them nearby.

Patrol groups should be less signifiicantly armed as they're effectively 'scouts' for their base; Marauders should have definite & specific attk/loot orders & Rievers should be targeted appropriately to (their hostile closest) capship/station. This gives a 'living' feel to piracy: a purpose for their ethos if you like. Despite them being 'thin air spawns' out in the uncharted barrens, once spawned at least they have an ulterior direction & motive other than being simple player-bait

Who knows, maybe <player> will fail the first (few?) attacks brought on by their exploration, & the region will suffer continuous <hostile-induced> economic problems until this 'random' spawn is finally reduced to rubble?
Wiki X:R 1st Tit capping
Wiki X3:TC vanilla: Guide to generic missions, Guide to finding & capping Aran
Never played AP; all X3 advice is based on vanilla+bonus pack TC or before: AP has not changed much WRT general advice.

I know how to spell teladiuminumiumium, I just don't know when to stop!

Dom (Wiki Moderator) 8-) DxDiag

ajime
Posts: 335
Joined: Mon, 15. May 17, 09:00
x4

Post by ajime » Wed, 2. May 18, 05:23

I still remembered using FRED2 like it was yesterday. Fun times.

Post Reply

Return to “X4: Foundations”