Another mission editor question (and a possible bug)

[kalnaren]

Still playing around with the mission editor

I guess this is more of a feature request, though I don't know how possible it would be. Right now having absolute mission time as the only way to trigger events can be.. problematic, as you have zero control over how long a player lingers in one area. Would it be possible in the future to add some type of other trigger other than chronological? (such as time elapsed in the vicinity of a waypoint. Like for example, 120 seconds after player first gets within 35k of waypoint). It would help construct some more dynamic missions.

Totally unrelated, possible bug: It appears the Engine/Nav system on cap ships is backwards. Engines are targeted at the front and the nav system is targeted at the engine block.

Great last updates BTW. Love the higher resolution HUD elements.

[Vice]

Not sure on the viability of independent timers per se, the current format is entirely geared around location based and mission time based triggers. So a subsystem using a different approach might be fairly bug risky and may involve conflicts with one of the other systems. You can link things to the absolute mission time (and is generally preferred for the time pressure element of military missions the game is designed to facilitate, including being able to fail the mission if the player fails to arrive in time), but you can also incorporate the appearance of entities once the player gets within range and that can be established with the waypoint system (leaving the time element out of it, if desired, and having the entities hold their position until the player arrives).

I'll set some time aside to explore what may be possible. The approach that could be most feasible might be a delay timer bound to the proximity trigger of a waypoint as you described. That is, the player arrives at a waypoint, then the existing event remains pending until the timer runs out. It would kind of work like the absolute timer already does, but just offer an independent delay where you could stall something like you describe for 120 seconds once they arrive. You'd need to keep track of any successive events you may have queued so they either don't get lost or also operate on the same delay system on their own waypoints to keep things cohesive. Or limit such a mission to just one waypoint and one event with a delay. The player would also need to be aware of the need to remain in a location while they wait for the delay timer to run out (delays can sometimes cause player confusion unless they know they are supposed to stay somewhere). Ultimately though, it still may not offer much more in terms of flexibility or options over the current global timing and waypoint triggers. If put together something testable and you'd like to give it a try, send me a quick e-mail and I can provide a download link to such a test build if/when it is available.

Good catch on the bug, they should indeed be reversed. Fixed for the next update. Glad you like the texture improvements.

[Vice]

Ok, integrating a delay timer wasn't too bad and didn't appear to conflict with anything. I've rolled out an update with that option as well as other improvements, so you can give 2.2028 a try now. I've also updated the editor to indicate both the HH:MM:SS and delay/sec option in the 'Event Time' line. Further details are available in the changelog notes: https://www.starwraith.com/forum/viewto ... 22#p198522

[kalnaren]

Amazing work Vice, as always. Less than 24 hours I made this request and you've already posted an update. I really appreciate it.

I played around with it a bit and once I understood the sequencing it works great. I haven't done extensive testing with it yet, so forgive me if these seem like simple questions.

The "specified waypoint" I assume is considered the current active mission waypoint? (which works fine). This appears to be the way it worked in my testing.

The new editor doesn't appear to recognize the new delay format (unless I misunderstood how to enter it). For example, entering '00030' or '30' for a 30 second delay is interpreted as '00:00:30' mission clock time. Entering '30' in the 'MissionTime#' directive in the text file works as intended. I don't mind editing the text file by hand, just want to make sure this was functioning as intended.

Also good call with 'MissionShowDelay' printing to the screen. Makes testing so much easier.

Thanks

[Vice]

Certainly welcome. Thanks for the feedback and report.

The "specified waypoint" I assume is considered the current active mission waypoint? (which works fine). This appears to be the way it worked in my testing.

Yes, it will be the last specified waypoint that is currently active at the time of applying the delay directive. If the player gets out of range of the waypoint for some reason, the timer will just simply pause, then resume once they are back in range again. The range is the same as it is for other waypoint activations (25K for open space, 12.5K for reduced range caused by nebula clouds/gas giants/etc).

The new editor doesn't appear to recognize the new delay format (unless I misunderstood how to enter it). For example, entering '00030' or '30' for a 30 second delay is interpreted as '00:00:30' mission clock time. Entering '30' in the 'MissionTime#' directive in the text file works as intended. I don't mind editing the text file by hand, just want to make sure this was functioning as intended.

Ah, missed that. I've corrected the editor to accept 1-5 digits as a delay parameter and am in the process of updating the downloads for the installer. You can optionally wait for about 30 minutes from the time I post this for those to update. Or you can grab just the replacement EXE at this link:

https://www.starwraith.com/arvochallian ... Editor.zip

[kalnaren]

Another possible bug: When creating a waypoint using the 'Create Waypoint' event, the waypoint doesn't appear on the ship's HUD. It appears in the Nav console (F1) and you can set your Nav point to it, and likewise events seem to work properly using that Waypoint.

EDIT: Upon further testing, it appears with the first waypoint set using 'Set Waypoint', but doesn't appear with subsequent ones.

[Vice]

Indeed, that applies a nav map only waypoint marker (although it may override an existing waypoint if one is already active to allow it to be visible on the HUD). I'll expand that to include linking to the HUD system (so long as the distance is beyond the activation range of the player at the time the waypoint is set).

[kalnaren]

Another question (I do apologize for the constant questions.. as I play with the editor more I'm coming across stuff I'm curious about).

How is the "Destroy Capital Ship(s) Only" objective evaluated? I had it trigger once when a single transport warped out, but not when 2 transports were present in the mission and one warped out or was destroyed by an event, and the other was destroyed by ships?

[Vice]

No problem on the questions, some important details and descriptions that may not be clearly described. Such questions are also helpful to others who might run into the same things.

The 'Destroy Capital Ship(s) Only' (type 12) checks for any capital ships in the hostile indexes (25-48) after a ship destruction event. If it finds any, it expects that one or more are present and still needs to be destroyed. So if only one is set for the mission, then it should apply the win route as soon as it is destroyed. Warping such ships away (event type 4) could be used to allow one to escape if not destroyed in time (then apply a fail directive to guide the mission path down the losing route, if desired). But generally, it's probably good to keep one or more around until the mission completes to give the player enough time to eliminate them.

There could also be conflicts if you specify one main objective, but then apply other conditions, such as a mismatched 'Required Kills' parameter. If you encounter something you'd like me to review for functionality, you can send me the mission file you are currently working with via e-mail and I can look into it.

Update with the 'New Waypoint' event linked to the HUD and message systems is now available at the usual links. The event will now cause the HUD indicator to appear along with a message line indicating the heading of the new waypoint.

[kalnaren]

Thanks.

It looks like the 'Destroy Capital Ship(s) Only' (type 12)' isn't evaluating for transports.

For testing I set up a very simple mission with a single enemy transport in position 25 with the above objective. No waypoints (or 1 waypoint, tried both) and it doesn't win the mission when the transport is destroyed.

I can send you the mission file if you want a closer look.

[Vice]

Sure, if you'll send it to me, I'll take a look.

[Vice]

Got the file and am looking into it now... If there's a glitch, I'll roll out an update with the fix probably sometime later tonight.

[kalnaren]

Thanks. No hurry.

[Vice]

Ok, I discovered a couple of things. First, your test mission file lacked a waypoint. For the game to queue any event or directive (including mission objective), it requires at least one waypoint. So without the waypoint, the mission objective was never activated. One waypoint is applied by default, but the mission file must have had it removed at some point (set to 0). I've added an alert message in the editor when saving to bring such a condition to the author's attention in case that gets set to 0 somehow.

In addition, the game itself needed to check two parameters and was only checking one, so the mission would often not complete even when one or more capital ships were destroyed as required by objective 12. I've corrected this in the game as well. I need to run through some final checks and will plan on rolling out an update soon. I'll also flip the version number this time since this is a relatively significant fix and change.

[kalnaren]

Thanks for checking into that. I had tested it both with and without a waypoint (the first test had the waypoint set at the starting location) and got the same behaviour both times, so I wasn't sure if mattered.

[Vice]

It would, so it was good to test both ways. I had fixed the issue in the game, but then the win path still didn't trigger with your mission file, so that helped pin down the other possible cause with the waypoint dependency. Should now be all sorted

Updates available at the usual links, now version 2.2048 for the game, 2.0048 for the editor. I also added some highlight boxes for menu and map modes to the editor for better distinction.

[kalnaren]

Very nice! I now have the sequence of events playing out in the mission the way I envisioned it.

Is there a way to trigger an event on mission completion (like playing a message or something)? I might have missed that in the editor.

[Vice]

The new delay timer should work for something like that. After applying the mission complete directive, you could set a waypoint trigger at/near their current location or back where you want them to return (or you could leave it up to the game to set it back to the carrier), then have a message play immediately or when they get in range of a more distant waypoint.

You could also apply the message on a set schedule using the mission time option (events can still apply after a mission is completed).

[kalnaren]

I think I found another bug in the editor.

If you load a mission, then load a different mission without closing the editor, it appears the editor doesn't "clear" the ship missile loadout and will write the loadout in memory to the mission file despite showing the correct loadout in the editor.

For example, in my custom mission, the player fighter is fitted with 4 Starfires (Missile1-4=74, Missile5-8=0). If I load a different mission in the editor with a full missile loadout, then reload the original custom mission and save, it fills the remaining slots with the previous mission's loadout despite the proper loadout being shown in the editor.

Here's a screenshot:



Took me a few tries to figure out what was going on here

The new delay timer should work for something like that. After applying the mission complete directive, you could set a waypoint trigger at/near their current location or back where you want them to return (or you could leave it up to the game to set it back to the carrier), then have a message play immediately or when they get in range of a more distant waypoint.

You could also apply the message on a set schedule using the mission time option (events can still apply after a mission is completed).

Right. I'll have to play around with the some more. Thanks.

[Vice]

Confirmed, I'll be rolling out a fix later tonight.

[Vice]

Ok, update is available at the usual download links. You can also grab just the revised EXE for the editor here:

https://www.starwraith.com/arvochallian ... 20048b.zip

This update properly nulls out any missile values left behind in the menu queue from a previously loaded mission (preventing their application when a new mission is loaded and then saved).