But then it's rather different from the "Mission Editor" of this thread, of which I don't even know the featureset. Afaik I'm lacking triggers, bat videos, multiplayer support, external editors, SpringDownloader and Lobbies integration,.... (but those last points are actually pluses in my eyes! ).
I'm not sure what was your feature request for factory orders, but I can give move/repeat/build/fight/patrol/etc... orders to factories in my mission system.
In fact my system is more about dumping and restoring unit positions and queues than proper scenarised missions. It's done with custom team option tags, such as:
u10= 1760 7672 R180 fedmotor Move 1880 7272 Repeat Build constgtank; // A factory that keeps on building and sending constgtank. u158= goufh Position 409 3824 TimeWait 900 Fight 7323 6809;// Attack after 15 mins.
If you're interested by my mission system: The one is KP3.8 is outdated, get the one from Gundam 1.21 SP4.
Since all the code concerning my mission system is well separated into its own sd7 mutator, integration to another mod shouldn't be too hard.
Licho's Mission Editor includes full support for timers, triggers, state changes, mission messages, and other things that are kind've a big deal, though. It's a bit buggy; usually I have to do manual cleanup and fix event triggers, and I had to customize the Lua to support some specific stuff. I'm guessing that some of this is why this never got widely used. It's not exactly newbie-proof, and the process of getting a game ready to use it, since it was tied into unitsync.dll, is kind've a pain in the ass.
But if you're looking at features people want... I strongly suggest loading up Spring 0.78 and trying it out, zxswg. While it's a pain in the ass in some ways (had to consolidate WB and P.U.R.E. into a single package to use it all together, for example), it does deliver.
But, that said, I can lay out a complete mission, including all the messages (to be replaced with graphics later, as I did in P.U.R.E.) fairly easily and quickly. Stuff like, "go here to rescue the Wumpus, then go there and deliver him, you fail if the Wumpus dies" missions are trivial.
Ideally, I'd like a Mission Editor where I could just run Spring, and use a UI to construct triggers, define timers and messages. Timers and triggers are a must-have, imo, because you just can't build a true scripted scenario without them. Messages are a must-have, because without them, you can't do much in the way of giving feedback to end-users.
I've done a few things with WB variants- an invisible Unit serving as a trigger, for example- but I haven't come up with a good way to do event timing with a UI, yet, other than coding it raw (that's easy enough to do).
I've never had a use for video support. My resources just won't run to that- building video is hugely time-consuming. TBH, I'd rather have support for scripted events, where everything else gets removed, then put back into the gameworld if we need it to be, with camera support.
Because there isn't enough demand for missions/mission editor (nobody has attempted to fix it), It's no longer supported. SD tab and mission server repository and mission editor downloads will be gone too.
I've been thinking about how to do missions, and actually I think Z's approach is the simplest to extend to full missions. For example, an invisible "builder" unit has superfast workertime, infinite range, and a buildlist of every unit in the package. Just order a "wait" and give it a buildlist. Then create a simple widget/gadget pair for drawing "unwait" commands as links in event handling (ie you have a trigger unit, a delay unit, and a spawner unit, and draw a chain linking the trigger to the delay to the spawner).
You could have units that correspond to all kinds of events - just make each unit represented by a simple square icon on a cubic model. Work within Spring as much as possible, and build a simple graphical programming approach out of units.
It worked in Crack Dot Com's "Abuse" - a you just placed logic, monsters, and level elements onto the map and wired them up with event-lines.
Although you'd also need a way to set parameters onto the units (like the timer on a Delay unit) - at first, a simple widget to display parameters and a command-line command to set the parameter values would be enough.
they should be mod version independent if possible
That's straightforward enough, although backwards-compatibility is far from guaranteed. For example, all the Missions that ship with P.U.R.E. refer to P.U.R.E. Complete, not the Core, so the dependency chain is clean regardless of version. But it's quite possible if a game changes enough that it simply won't work- that's the price you pay when you start radically altering the game design.
In regards to structure... I don't like invisible Units, and I don't like fixed timers / Wait. That's clunky and very likely error-prone- various game event logic could screw up your mission very easily.
And a "savegame" is not a mission, except in the crudest sense. It can't handle any novelty, and the win conditions are totally inflexible.
Missions need to be written inside a GameFrame() loop, triggered once every couple of seconds or so. They need to use an offset from the starting frame, so that if you're testing, you can reset the mission and replay it immediately, instead of having to reload.
In terms of broad functionality... we need support for:
Triggers, Timers, and Targeting Updates (i.e., not just canned path-bound stuff). Specific Order states (for when we do want canned stuff). Units whose death / capture can change a trigger state. Presentation of information to end-users.
What I'm thinking in terms of flow:
1. Write out a list of triggers in a config (with some sort of UI tool to facilitate that in-game)
2. Write out really specific events using something like a save-game state writer. Hit a button, it asks for a name of the event, it asks if any defined trigger(s) or count(s) should be true / false / and / or, how long to delay it, is it cyclic once active, if cyclic can another trigger state stop it, then actually perform the events and hit the button again to save the state instructions. I *think* that this can all be presented to end-users as a questionnaire, although it'll get tedious to build long logic chains (oh well, it's always tedious).
3. Have a button that ties death / capture (or perhaps other things, such as build) to a trigger state or count state.
4. Tie game-halting end-user UI presentation (bitmap, text) to a trigger state. Hit button, define graphic used, define trigger state(s) or count(s) to check. OFC, activating any such should mask out others (i.e., if you trip two triggers in between updates, first do one, then the other)
The problem with all of the above is mainly developing a good UI for it.
Scripting a scenario by hand is *not* particularly hard, it's just very tedious. What's hard is presenting all of this in a very simple, bulletproof way.
Personnaly, I force the mod name in the mission startscript to the mod being run in my ingame frontend. Anyway, my missions and savegames are sorted into subfolder named after mod short name.
Initially I wanted to simply use CMD.TIMEWAIT for my time trigger, but it's a client-side unsynced order, so I reimplemented it as synced order. I used it in my exemple missions to make "attack after 15 minutes" surprises. Saving and reloading reset my time triggers atm. I also need to add more kind of triggers, trigger independent of units, and spawning or killing units or other actions when triggers trigger.
Joined: 17 Nov 2005, 02:43 Location: Raegquitting Spring on 04/24/12
It is amazing to me that it worked this well and nobody but me really put it to much use.
Not all of us are to that stage yet. I was planning to do it before our release, but then it r broked and that idea went up in a puff of smoke. I made several missions, but never released them. Be a little pointless to release missions that I made using an svn version now wouldn't it?
However, if it's something that has to be continually maintained, I'm glad I know that now, because if it ever stopped being maintained (like it has) I'd be 100% up shit creek.
Users browsing this forum: No registered users and 1 guest
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot post attachments in this forum