View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0002456 | FSSCP | multiplayer | public | 2011-06-18 19:07 | 2019-12-14 00:57 |
Reporter | bigchunk1 | Assigned To | Goober5000 | ||
Priority | normal | Severity | major | Reproducibility | always |
Status | closed | Resolution | not fixable | ||
Product Version | 3.6.13 | ||||
Summary | 0002456: Distance SEXP does not work on respawned player AI | ||||
Description | When AI controlled 'Player' ships are destroyed in multiplayer, it seems their positions are no longer tracked. The following sexp will only work on human controlled 'Player' ships and AI controlled 'Player' ships which have NOT yet been destroyed. (when) and -some event triggered -distance spawnpoint Alpha X ->relocate ship Alpha X The distance operator of this sexp refuses to trigger on AI controlled 'Player' ships which have been destroyed. It will, however, work for human controlled 'Player' ships. | ||||
Additional Information | Lester made a test mission involving the issue which can be found at this url. http://www.mediafire.com/?rrx9d73u7srfrp2 Fixing this error will allow Multiplayer missions to move spawnpoints, which is of great interest for missions which take place over different locations. | ||||
Tags | No tags attached. | ||||
|
I remember this on from the thread on HLP. Was it ever resolved? |
|
Nope, you said fixing this will probably break more missions that it fixes, which isn't much of an issue considering both Kyad and I are fredding for both currently active multiplayer projects and are willing to fix any damage if it occurs. |
|
I probably meant it would break a lot of retail missions and therefore couldn't be fixed. I will look into a solution for this one eventually, probably a new SEXP because I know a lot of people could use this. |
|
After thinking about this for some time, the best solution I can propose is to make a new mission log entry type, called something like LOG_SHIP_DESTROYED_TEMPORARILY. It would be applied only to multiplayer ships. And every single piece of game logic which references LOG_SHIP_DESTROYED would have to be amended to take into account LOG_SHIP_DESTROYED_TEMPORARILY as well. This bug really uncovers exactly the same issues WMC ran into with his limbo feature attempt. There are just way too many assumptions in the code that a ship which is destroyed is going to stay dead, and a ship that is departed isn't going to re-enter. For mission design purposes you can use a new ship with the same name, but that doesn't apply to this situation. |
|
That's probably more trouble than just writing a new SEXP and deprecating the old one though. If we're going to stop relying on the log for multi we shouldn't half-arse it and stop relying on it completely. Leave it on for legacy purposes and come up with a better way of doing things for all the SEXPs. That way we no longer have the (false) assumption that a dead ship stays dead. |
|
I've got an idea, probably inspired by going through sexp.cpp to synch SHIP_DESTROYED with SELF_DESTRUCTED. It looks like the vast majority of those log entries are simply shortcuts to avoid performing a ship_name_lookup call. Of course, they ignore the fact that the mission log is itself a lookup. So I suggest changing all sexps to first perform a ship_name_lookup, then check the parse list, then assume the ship isn't in the mission for whatever reason -- whether exited or respawning. The only exceptions would be the actual is-destroyed-delay sexps which would continue to use the mission log as they have previously. |
|
Good idea. I'd further suggest moving some of that logic to the sexp_get_ship_from_node() function (or a similar sexp_get_ship_index_from_node() function). The amount of unnecessary duplication in sexp.cpp verges on the ridiculous. |
|
Upon further reflection and examination of the code, I'm reluctant to arbitrarily rip out most of the mission log statements. Many of them involve setting NAN_FOREVER or some permanent node flag during their evaluation, so they're not side-effect-free. Now I'm fairly sure that removing them will not affect the ultimate resolution of the sexp value, but I don't really want to invest the effort to prove it. And even if I ripped out most of the mission log checks, the sexp in question -- distance -- checks specifically if ships are exited and short-circuits the logic accordingly. I don't want to inadvertently screw up someone's node departure check by changing that. Fortunately, there is a workaround. Using every-time will clear out the NAN_FOREVER and KNOWN_TRUE/KNOWN_FALSE values, allowing the sexp to be re-evaluated. This should allow the FREDder to check on ships that have respawned. Closing ticket. |
|
I'm not sure I follow you. How is this fixed? Using every-time will clear the NAN_FOREVER and KNOWN_TRUE/KNOWN_FALSE values, yes. But then the SEXP will call sexp_get_object_ship_wing_point_team() which will call mission_log_get_time(LOG_SHIP_DESTROYED.... set the oswpt->type to OSWPT_TYPE_EXITED and cause the sexp to return SEXP_NAN_FOREVER again. |
|
D'oh... you're right. In that case, I can move the mission log check, and the resulting OSWPT_TYPE_EXITED assignment, to the bottom of the oswpt function. That ought to do the trick. |
|
Looking through this again, there is a way the sexp logic is set up the way it is, and moving the mission log checks would require replacement checks of some sort. The proposed solution really isn't doable in any form. The best solution is to supply a new argument type, maybe a string like ShipName#respawnable, which would not trip the mission log checks but at the same time return the correct index from ship_name_lookup. This would then work on any sexp, not just distance. But this requires further discussion and I'd rather punt this until after the more critical multiplayer fixes go in. Closing ticket. |
Date Modified | Username | Field | Change |
---|---|---|---|
2011-06-18 19:07 | bigchunk1 | New Issue | |
2011-08-19 10:12 | karajorma | Note Added: 0012771 | |
2011-08-19 10:12 | karajorma | Status | new => assigned |
2011-08-19 10:12 | karajorma | Assigned To | => karajorma |
2011-08-19 18:41 | Lester | Note Added: 0012773 | |
2011-08-23 00:16 | karajorma | Note Added: 0012776 | |
2012-02-08 07:16 | Goober5000 | Note Added: 0013249 | |
2012-03-08 12:26 | karajorma | Note Added: 0013409 | |
2012-03-08 12:27 | karajorma | Note Edited: 0013409 | |
2012-10-28 13:45 | karajorma | Assigned To | karajorma => |
2012-11-23 03:43 | Goober5000 | Note Added: 0014155 | |
2012-11-23 06:51 | karajorma | Note Added: 0014157 | |
2012-11-23 06:52 | karajorma | Note Edited: 0014157 | |
2012-12-20 02:18 | Goober5000 | Note Added: 0014542 | |
2012-12-20 02:18 | Goober5000 | Assigned To | => Goober5000 |
2012-12-20 02:18 | Goober5000 | Status | assigned => closed |
2012-12-20 02:18 | Goober5000 | Resolution | open => not fixable |
2012-12-22 05:04 | karajorma | Note Added: 0014558 | |
2012-12-22 05:22 | Goober5000 | Note Added: 0014559 | |
2012-12-22 05:22 | Goober5000 | Status | closed => assigned |
2012-12-22 05:22 | Goober5000 | Resolution | not fixable => reopened |
2019-12-14 00:57 | Goober5000 | Status | assigned => closed |
2019-12-14 00:57 | Goober5000 | Resolution | reopened => not fixable |
2019-12-14 00:57 | Goober5000 | Note Added: 0016942 |