[Aardwolf]

We (Nuke + I) need to be able to warp ships out, wait a prespecified amount of time, and then warp them back in.

One idea I had is to, on warpout, either prevent it from being deallocated or copy ALL of the ship's data into the scripting system, then warp it back in using the scripting system.

Is this (either) possible?

We thank you in advance (or at least I do... )

[Nuke]

the problem is that we are currently copying the ship and creating a new one in its place, which is then warped out, the new ship is moved, given a new orientation and physics vars are zeroed, then warpin() is called. this has some odd side effects. one example is that sometimes the ship will warp in before its temporary placeholder ship fully departs. another is that if the warpout ship is destroyed, its original will still be intact. we want a small delay betwen warpin and warpout.

i think i posted an idea for a limbo state. which puts a ship on hold essentially, where its not rendered and its status isnt allowed to change. probibly through a ship:enterLimbo() and ship:exitLimbo() functions. warpout has a departure bool and i think its supposed to just do the warpout effect and not remove the ship. if thats the way it was supposed to work then it doesnt seem to do that.

[Aardwolf]

On a slightly related note, what could cause a ship to explode when being warped in? It's kind of annoying when your strategy is foiled by the loss of an Orion upon exiting subspace.

[Nuke]

set its hitpoints to zero perhaps?

[Aardwolf]

Uh... I was COMPLAINING that it happened to me randomly, not asking how to do it.

[WMCoolmon]

This exact feature was implemented but was then removed because of conflicts with the mission log. Basically there was no way to tell whether a ship had left for good or not using SEXPs without updating all related functions. Permanent warpout was controlled with a boolean, which was also added to the function for warpOut() in scripting, and a limbo variable was added that would set the ship in and out of limbo.

It is re-implementable, but it's not something I'm going to get around to anytime soon (unless I just plain feel like doing it).

[Aardwolf]

Ah, so the argument to warpOut is indeed disabled...

If we could suggest an optimal solution, that would require the minimum amount of changes to other parts of the code, would that be sufficiently convincing/persuasive? I suspect that if you would have had to change all related SEXPs to make it work, you might have been doing it in a sub-optimal way...

Why couldn't you just say something like, when a ship is told to warpOut(false), as soon as it would normally be removed, instead of classifying it as warped out, just put it directly into limbo, and disable drawing/targeting/attacking/damage/etc.? That way, all you'd have to do (with high priority, anyway) would be:

• Add a limbo state
• Put ships that warpOut(false) into limbo instead of setting them as departed
• Create a SEXP and script function to determine if a ship is in limbo
• Disable all actions of the limbo'd ship until it is told to return from limbo

And lower priority items like:

• Add a way to control whether or not a wapOut(false) ship event appears in the events list

Of course, this is from an outside coder's perspective, I've never really looked at any part of the FS2 code that made much sense to me.

[WMCoolmon]

That's exactly what the code did. The mission log entry code was an addition that caused the trouble. Adding or removing the mission log entry causes problems either way; although I suspect if the mission log entry were removed, the FREDder or scripter would be able to work around it in some way.

The feature was implemented sometime in 2006, but was removed sometime later on.

I think Goober's making a lot of unwarranted assumptions in his comments in the bug entry. But at this point I don't want to have to go back and redo all that work just to have it get removed for a second time, or get in a big argument to even let it have a chance.

[Aardwolf]

This mission log, of which you speak... is it some sort of internal collection of the events that are referenced by SEXPs?

What exactly was the bug in the mission log?




You've got me interested now... I realize the FS2 code may be hard to read/work with, but if I can help in any way, I'd be glad to...

"Not only is it the ethical thing to do, it's also in our own interests"

[WMCoolmon]

The mission log is basically what comes up when you press F4, and get it to list ships that have arrived/departed, been destroyed, and so on.

The bug is that there's an entry type of LOG_SHIP_DEPARTED that's used for when ships leave the area. It's also used for a number of SEXPs to check if they should actually do anything. This is fine, and works well, until 'leaving the area' doesn't equate to 'leaving for good'. At that point, there are a lot of functions that will check for the 'departed' event and, upon finding it, give up and return without doing anything.

Smarter behavior would be to have the functions reliant on a ship leaving for good to check the Exited_ships list, or to check for an arrival event after the departure event.

The main missionlog files are missionlog.cpp, and missionlog.h.

[Goober5000]

It's not just the mission log, it's also the fact that every single function had to have a special case set aside for just this one feature.  But we already have a thread for that.  Aardwolf, check it out and see if ship-copy-damage will suit your needs.