mission status query

Freeform discussion about anything related to modding Transcendence.
Post Reply
relanat
Militia Captain
Militia Captain
Posts: 816
Joined: Tue Nov 05, 2013 9:56 am

Mon Oct 14, 2019 3:17 am

A few missions will not complete if the player changes ships after the mission has been started.
I would like to do a patch mod for 1.8 which will register the new playership for any outstanding missions but I am not sure of the terminology.

A modification of the Ship Broker code would seem to be the way to go or possibly using the <OnGlobalPlayerChangedShips> event. Not sure yet. Any opinions? I had considered using the <OnPlayerEnteredShip> event but this needs to be in the ShipClass.


If the player is involved in any missions then the new playership could be registered for those missions. This seems to fix the problem. It probably won't be strictly necessary for every mission, only the ones that register the playership for events, but registering for every mission is an easy thorough way to handle it IMO.

Hopefully community members who are knowledgeable about missions can help with which criteria and properties are relevant.
I suspect active missions, 'a', would cover it but possibly completed missions that haven't been debriefed, 'c', might need to be included? Or are these already covered by the 'a' criteria?
Also I'm not sure about the 'inProgress', 'isActive', 'isCompleted' and 'isDebriefed' properties. Possibly some filtering for one or more of these will be required?

From what little I know, the playership is checked in <OnObj***> events (thanks gc). So a look at the code of most missions to see when in the mission lifetime these events fire will be needed but any general info about which mission states should be covered would be appreciated.

Thanks.
Stupid code. Do what I want, not what I typed in!

NMS
Militia Captain
Militia Captain
Posts: 549
Joined: Tue Mar 05, 2013 8:26 am

Tue Oct 15, 2019 5:25 am

The problem with registering all missions is that missions that don't register the player ship might assume certain things about the registered ships. E.g. they might succeed/fail if any registered ship enters a gate.

So the only fix I can see that doesn't require checking each mission's events is to change the game engine to automatically register the new player ship for anything that the old player ship was registered for when the player changes ships. I'm not sure how difficult that would be.

Without engine changes, the best solution is probably to identify all the missions that register the player ship and give them an OnGlobalPlayerChangedShips event that registers gPlayerShip and unregisters aOldPlayerShip (just in case the player later buys it for a wingman).

relanat
Militia Captain
Militia Captain
Posts: 816
Joined: Tue Nov 05, 2013 9:56 am

Sat Oct 19, 2019 7:19 am

Excellent info as always. Thanks.

Yes, I assume George will find a fix the 1.9 versions. derakon(?) had a good idea about registering gPlayer instead of gPlayerShip which would cover it. But it probably isn't worth updating 1.8 for this.

So it looks like an <OnGlobalPlayerChangedShips> event which checks a list of missions which do register the playership could be used. If any of these missions are active, register the new ship and unregister the old one. I'll have a play around with it and see what happens. You may have noticed missions aren't my specialty! :lol:
Stupid code. Do what I want, not what I typed in!

NMS
Militia Captain
Militia Captain
Posts: 549
Joined: Tue Mar 05, 2013 8:26 am

Sat Oct 19, 2019 8:28 pm

I think it's better to add the event to each mission so that there isn't a separate type that needs to be updated when a mission is added or modified. It's probably easiest if I just do it myself and submit a pull request to George.

relanat
Militia Captain
Militia Captain
Posts: 816
Joined: Tue Nov 05, 2013 9:56 am

Sat Oct 19, 2019 10:47 pm

Nah, it is only a patch for 1.8.3 stable. Wouldn't ever need to be updated unless 1.8.4 stable was released. Even then it would only need updating if the missions changed which isn't likely unless they are changed to fix the bug (then the patch won't be needed anyway).

A pull request would be the better option but I'm not sure how desirable an update of 1.8.3 is. In my limited experience stable versions are only updated to fix major bugs.
1.9 and VOTG are probably a higher priority than retroactively fixing a bug that doesn't do much except confuse the player a bit.

Whatever helps the players.
Stupid code. Do what I want, not what I typed in!

Post Reply