...I have a lot easier time believing that you're actually being totally indifferent to my request and not even trying to take me seriously.
No, it's simply that I'm annoyed this can of worms is being opened again. We already resolved this once. Lying low for two years and then resurrecting the same argument is not going to change my mind.
Oh ffs. The only reason I even looked into this in the first place and changed my mind is because somebody asked me a question, which required me to justify the reason that this got taken out in my answer. I looked back at the bug report, and found that I agreed at the time, but realized that all of the reasons that I could remember were mostly circumstantial and time- and politics- related. I didn't want to hassle with it back then. So I looked at your responses and found them utterly unhelpful, and felt like I'd been suckered into agreeing with the wrong course of action by smooth-talking and outside pressure. I still didn't want to push the issue, so I didn't contact you about it. But when I got the opportunity to give you the benefit of the doubt and justify yourself, I gave it to you.
I haven't done any work on the bug other than to check once if it had been removed or not when somebody complained that the toggle on the scripting functions wasn't working. I resent the implication that I've had nothing better to do for the last two years than to stew about this issue - if I had that kind of luxury, I'd have just implemented the feature and disproven your concerns for good.
I didn't ask for you to write a report on it, I just asked for your reasons. I don't even remember the debate and the "reasons" you gave in the bug report are without substance and what has me doubting the decision in the first place. I remember that I didn't feel it was worth it to try and fix the problems with the code, but I believed that they could be fixed with time and effort, without breaking things.
I've been through the mission management code repeatedly, and its design is very fragile. It works well enough on its own, but when one of its assumptions is violated, it tends to collapse like a house of cards. It was hard enough adding initial multiply docked ships; what you're proposing would require an unreasonable amount of effort for a very small gain.
See my response to your response to my comment about cloaking.
It's the same situation as autogenerating Orion nameplates when texture replacement already does the job. It may be technically possible but it requires an investment of dozens of hours of work to save 30 seconds of graphics editing. It's pointless.
It's not pointless at all. It's an incredibly valuable bit of code that could save us a LOT of headaches later on as features are added to ships. It also saves the FREDder (or scripter) a lot of headaches because they don't have to deal with multiple ships and copying values between them. How do you do that right now without leaving stuff out or using up dozens of variables? How much time would it take to copy all the subsystem data from every single subsystem on a capital ship? How many variables internal to the code are inaccessible using SEXPs?
It also saves coders time, because they don't have to add code to one more function to handle a new variable that they added to the ship. I dislike functions that require you to reference member variables directly because it's very easy to assume that they'll be handled by the existing code, and it's very easy to either forget or simply not know all the functions that you have to add a new variable to for each given class. If a ship-copy function were implemented and it were anything but a memcpy (which it can't be), every single coder on the project would have to know and remember to update that function every time they added a variable. That's doable, but it's a fast way to ambiguous bugs.
If you understand the limbo code, then you should also understand that the underlying idea behind it was to prevent the ship from actually exiting. The idea was to play the warp effect animation, and then prevent the ship from being rendered or simulated in any fashion. So the ship would still remain in-mission; it wouldn't be added to the Exited_ships array and it wouldn't be pulled out of the Ships array. I did add it to the log so that it would appear to have departed, but since that broke SEXPs, it'd also be possible to devise a means of checking if a ship was in limbo or not...
As for the warp code, I remember that I had to add a boolean value to a number of the functions and update the core function(s) with an alternate path to handle if a ship warped out, but not really.
And that's the problem. You have to add dozens of little checks in too many places. It's too disorganized and it's too easy to miss a specific detail. Furthermore, it's too easy for someone to accidentally break it while working on what they would think is an unrelated piece of code.
You need to take into account not only the feature in question, but how it affects everything else. Neither the Law of Unintended Consequences nor Murphy's Law are typically very forgiving in this regard.
Ah, so you're implying that I'm being small-minded now? That's very rhetorical of you.
It's true that you'd have to modify several bits of code to do what I'm saying, but there are other benefits to doing it (if nothing else, by gaining that one aspect of cloaking). It's also not that subtle; it's pretty obvious that if there's a should_this_show_up_on_radar flag and you don't use it, you ought to have a good reason. There are already functions in the FS2_Open code that use functions or flags like that; the only thing I can think of that doesn't have an obvious implementation in retail code is the effects on AI. AI might automatically fly around the object, though given how well the AI is at doing that, you might never notice that it was trying to do anything of the sort. Firing at empty space could be a problem - but there's already circumstances where that would have to be checked for anyway (eg the huge flag) and you could simply add a function, can_this_weapon_be_fired_at_that, which can be used for all cases.
A lot of this is similar to the problem you'd face with a ship-copy SEXP, yes, so it's not an outright improvement in that regard. However, like I said, nearly all the effects of the limbo code already need to be in the code for various other features. It's only the limbo code which would draw all the features together into that particular combination. But since they could be drawn into a number of functions, I don't think it'd require quite so much cross-systems knowledge as the ship-copy SEXP. Somebody working on the radar code would just need to know that they need to use the can_this_thing_be_targeted function, and if they ever modified it, they'd notice that one of the conditions was to check the limbo flag from the object struct. Thus it'd be self-evident in modifying the code that the flag needed to be checked for in the new version.
This is why I have a hard time accepting your explanation; there's no evidence from what you've stated that you understand the idea behind the limbo code. The idea was never to remove a ship from the mission entirely and then put it back in, it was just to make it invisible and intangible.
The issue is not whether one understands the technical implementation (which I do); the issue is whether it's good design (which is what seems to be escaping you). I know very well how it works. I also know that it's a brutal hack and a flawed design. It's so flawed, in fact, that its implementation is tantamount to sabotaging the existing code.
Just because somebody says or thinks that they understand something doesn't mean that they do, and "good design" is a subjective enough term that it seems rather silly to generalize me as not understanding it like you do. Of course, I can't really 'prove' that I'm correct in that sense any more than you can, which makes it a rather worthless argument to make and just more rhetoric.
Also, I'd like to note that you're dipping back into throwing subjective opinion around as if it's some kind of objective analysis of the situation. It's not; and just because your mind is made up about it doesn't mean that it's any more valid for you to do so as a justification or support of your argument.
So the question I'm not asking is whether it's possible or not - I already know it is - it's how much work is needed to actually do it?
To do it properly you'd have to rewrite the entire mission management code with the anticipation that a ship may leave and then return. But as I said earlier, this would be pointless. You'd be using a daisy cutter to swat a flea.
Now we go back down to my explanation of what the limbo code is and what it was meant to be. There's a reason that it was called the limbo code, rather than the code-that-lets-a-ship-depart-and-come-back code.
Actually, I think the transphasic cloaking thing is the best way to approach this. Suppose someone wanted to implement transphasic cloaking - the ship would disappear, drop off of all radars, make no collisions with other objects, no AI-controlled object would respond to its presence. What problems do you see with that?
None. But transphasic cloaking is not the same thing as causing an object to depart and then re-enter. If you want to script a cloak and call it departing and re-entering, that's your choice. I happen to think that ship-copy is closer to what you actually want to achieve, but your mileage may vary.
And here's where I can have some fun and lecture you on engineering and design.
A good engineer or a good designer, whether they're working on code, building a bridge, making a play, or writing a treaty - works with what they've got. They make sacrifices and cut corners because the world isn't perfect. Sometimes they have to fake things. Sometimes you have to bull**** people or make a bluff rather than go the route of lofty ideals.
In this particular instance,
nobody is insisting that it be done the right way, because they can't. Ship-copy is not the same thing as causing an object to depart and then re-enter; it's using an active copy of a ship's attributes to make it appear that way, rather than using a more passive approach to conserve those attributes so they don't have to be recreated in the first place. Ship-copy would have its place in mods, I'm sure. But it's not what people asked for and, frankly, it's a more wasteful solution and has its own downsides that I haven't even talked about yet. How does it keep track of textures? How does it handle position and orientation of a ship, how does it handle names? Does it create the ship for you? How do you handle things like having a fighter depart from a certain ship, if it's possible that that ship will depart in the interim? How do you handle any other SEXPs that apply specifically to that ship if the time that a ship warps is variable?
For a pre-scripted mission, ship-copy would work. But for an RTS or a flexible mission, it doesn't work. You'd invalidate whatever handle you were using each time you used the ship, and if you had a ship make 20 jumps, you'd need to add the overhead of creating and handling the departure of ships (Not 20 different ships, just one ship making 20 jumps; when you assume that all ships in Freespace are capable of making subspace jumps, that number gets pretty large really fast). Future coders would have to constantly be wary of maintaining even mostly-unrelated features in the system, and handling pointers to memory allocated for subfeatures of a ship. You'd have to implement a copy function for ship trails, etc, and whatever else is implemented now with the expectation that a ship won't ever be duplicated in its entirety. For that reason, a perfect ship-copy function becomes a very, very difficult goal to obtain because you either have to spend all that time yourself to create those extra functions and ensure that other coders create them, or sacrifice elements of the ship copy. Again, I'm sure there's a valid use for a ship-copy function outside of this one specific case, but it's not a hard-and-fast better substitute to what I'm suggesting to solve the request.
