All Projects FSSCP  wxFRED

View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0002456FSSCPmultiplayerpublic2011-06-18 19:072019-12-14 00:57
Reporterbigchunk1 Assigned ToGoober5000  
PrioritynormalSeveritymajorReproducibilityalways
Status closedResolutionnot fixable 
Product Version3.6.13 
Summary0002456: Distance SEXP does not work on respawned player AI
DescriptionWhen 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 InformationLester 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.
TagsNo tags attached.

Activities

karajorma

2011-08-19 10:12

administrator   ~0012771

I remember this on from the thread on HLP. Was it ever resolved?

Lester

2011-08-19 18:41

reporter   ~0012773

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.

karajorma

2011-08-23 00:16

administrator   ~0012776

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.

Goober5000

2012-02-08 07:16

administrator   ~0013249

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.

karajorma

2012-03-08 12:26

administrator   ~0013409

Last edited: 2012-03-08 12:27

 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.

Goober5000

2012-11-23 03:43

administrator   ~0014155

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.

karajorma

2012-11-23 06:51

administrator   ~0014157

Last edited: 2012-11-23 06:52

 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.

Goober5000

2012-12-20 02:18

administrator   ~0014542

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.

karajorma

2012-12-22 05:04

administrator   ~0014558

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.

Goober5000

2012-12-22 05:22

administrator   ~0014559

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.

Goober5000

2019-12-14 00:57

administrator   ~0016942

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.

Issue History

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