Page 1 of 1

UPS Courier OXP bugwarning about itself?!

Posted: Fri Jun 06, 2008 7:15 am
by Lestradae
Hi,

As it said I should do so in my mission screen message, I report a bug of UPS Courier here.

First I got a mission screen that offered me transporting some blue parcels to a nearby communist system for 150 Cr.

I accepted.

Then a warning screen came, telling me that the mission had been scrapped due to an internal conflict with another OXP.

THEN another mission screen appeared (also from UPS Courier!) offering me a mission to get back stolen cargo from a boa I think in a system with a number.

I accepted this too, both missions.

When getting back to the 2*F5 - screen, BOTH missions are showing on my mission screen.

So the OXP reports itself as colliding with itself?

OK, will find out if those missions are doable. Perhaps relevant information could be that I had been offered (and accepted) the "retrieve cargo" mission already once in the past, but then didn`t do anything and after "35 days" a message came that the mission had expired.

Hope that helps,

L

Posted: Fri Jun 06, 2008 8:54 am
by Eric Walch
Lestradae wrote:
Then a warning screen came, telling me that the mission had been scrapped due to an internal conflict with another OXP.
Thanks for the report. I had the same thing once but couldn't duplicate it with one of my save files that also gave multiple offers. So I wasn't sure it really was internal or still had to do with an other oxp. I dive into it.

Eric

..

Posted: Fri Jun 06, 2008 9:31 am
by Lestradae
Is UPS Courier supposed to offer two of its missions in a row, though?

Never had that before, and assumed the reported clash was with its own two mission screens.

Thanks for looking into it, will report if the missions worked.

L

Re: ..

Posted: Fri Jun 06, 2008 10:33 am
by Eric Walch
Lestradae wrote:
Is UPS Courier supposed to offer two of its missions in a row, though?
Yes. That is why I started thinking for mission clash code in the first place. I have also had occasions of three in a row. The way it is written it are technically 5 more or less independent working oxp's in one file. Each decides for itself if it offers a mission.

EDIT: Thanks to Lestradae's description I now could reproduce the bugreport. I still do not see what is causing it. I added some logs and see that the second offer is made, than something clears the second mission screen (there is the bug somewhere). This clearing is detected by the oxp and the irregularity is reported in a bugscreen. After this the offer is redone. For the player everything is OK now.

EDIT2: Fount it. A little bit technical but here it is.

I have it. The messages just came in an other order than expected. To be able to do a new offer immediately after the old one I use two event handlers. One is triggered by ending of a mission-screen the other by clearing of the mission-choice. I added logs in the parcel mission and a identical log in the container mission.

Code: Select all

this.missionScreenEnded = function()
{
    log("Parcels: missionScreenEnded in: ")
    this.ups_choiceEvaluation()
    this.ups_missionOffers()
    log("Parcels: missionScreenEnded out: ")
}

this.missionChoiceWasReset = function() // new in 1.71
{
    log("Parcels: missionChoiceWasReset in: ")
    this.ups_missionOffers()
    log("Parcels: missionChoiceWasReset out: ")
}
On accepting the first screen I get following log:

Code: Select all

1)Containers: missionScreenEnded in:   UPS_CONTAINER1, YESCon, GUI_SCREEN_STATUS
2)Containers: missionChoiceWasReset in:    null,        null,  GUI_SCREEN_STATUS
3)Containers: missionChoiceWasReset out:   null,        null,  GUI_SCREEN_STATUS
4)Parcels:    missionChoiceWasReset in:    null,        null,  GUI_SCREEN_STATUS
(offering: UPS_PARCELS)
5)Parcels:    missionChoiceWasReset out: UPS_PARCELS,   null,  GUI_SCREEN_MISSION
6)Containers: missionScreenEnded out:    UPS_PARCELS,   null,  GUI_SCREEN_MISSION
7)Parcels:    missionScreenEnded in:     UPS_PARCELS,   null,  GUI_SCREEN_MISSION
8)Parcels:    missionScreenEnded out:      null,        null,  GUI_SCREEN_MISSION
The order was not what I first expected but after analyse it still makes sense. Just a short analyse so other can benefit from it.

After the first missionscreen is cleared, for all scripts a missionScreenEnded event is prepared but oolite has to call them one by one and not simultaneously.
1) containers get its event. It evaluates the choices, sets its stuff and than clears the mission-choice. This clearing starts:
2) & 3) Containers does nothing on this reset. It was ready.
4) Parcels does not get the screen-ended it was waiting for but it gets the choice-cleared first and that triggers the setting of a new offer.
5) Parcels choice-cleared is ready.
6) It is not until now that containers returns from its screen ended handler 1). And only at this point the system jumps to the next script that also needs this message:
7) Parcels gets its screen-ended event and starts analysing its choices. It detect it has made a choice so the answer must be his one. Now it detects it is an empty choice and issues the bug.
8) Now parcel exits the event.

The but is caused by not giving all scripts the events in the same order. No problem if one knows. It just needs some additional checks and not taking things for granted. I hope this also help others.