Escort mission : bug report

[Chimrod]

Hello everybody,

This is my first post in the oolite comunity, and this post is about a bug I've found in the escort mission pack ( http://wiki.alioth.net/index.php/Escort_Contracts_OXP ). (Feel free to move the thread in another forum if the place is not apropropriate…)

Yesterday, I was ending a long trip with my passenger, the final destination was here, only 10h to flight throught wichspace. I've found a cargo going to the same destination and requiring an escort. Why not ? Let's go.

They where 5 to wait for us ; the combat was short, deadly (for me). My passenger and me exploded in big light in the space.

The bug : I'm back in the station (game reload), the escort contract is still here. Nobody's waiting for us this time, we fligth without trouble to the station, and my escort say me to wait in the bar for my pay. I've been credited for my mission by « [very big number]NaN » credits, which gave me the incredible amount of 0cr cash !

Did someone else experienced this ? I'm using Oolite 1.80 in linux amd64.

Thanks to all !

[cim]

Hello and welcome to the forums, Chimrod.

Unfortunately this is a known problem with the latest version of Escort Contracts - if you save the game between accepting the contract and completing it, the contract payment amount is lost when you reload. The OXP doesn't currently have an active maintainer, so there is no fix for this at the moment. For now, you can work around this by only saving before you take on the contract, rather than after.

[Chimrod]

Hello cim, thanks for your reply.

How are organised the OXP ? I've seen some zip to download from box.com, but is there a source repository for all of them ?

I took a look in the code, and it seem good documented ; indeed only the reputation seems loaded from the save :

Code: Select all

	else {this.ec_escortrep = missionVariables.ec_escortrep;} // otherwise load value from save game.

although every variables are saved.

Well, I'll take some time for seeing what can be done here…

[Cody]

I've seen some zip to download from box.com, but is there a source repository for all of them ?

All the OXPs available via the in-game manager can be downloaded from here.

[Norby]

is there a source repository for all of them ?

http://www.oolite.org/oxps/ - this is used by the in-game expansion manager. If you make a fix then I can upload it.

[cim]

A few people do have source repositories separate to the OXP downloads, but for most the files in the OXP download are the entire source anyway.

My guess about what the bug is might be useful for fixing, as might the  OXP code documentation (especially the  Javascript reference[/url]). Good luck!

Any value in missionVariables will automatically be saved to the save game (as a string) and reloaded from it, though they can also be used for storage (of any data type) while the game is running.

[Norby]

missionVariables can also be used for storage

Which provide a chance to get 60 times speedup if cached in a local variable.

[cim]

missionVariables can also be used for storage

Which provide a chance to get 60 times speedup if cached in a local variable.

Definitely. Whether that matters or not depends on how often you access them, of course. (And there are some uses of mission variables - string substitutions in missiontext expansion, for instance - which require them to be set that way)

[Chimrod]

Got it !

The variable missionVariables.ec_payment where not initialialized when loading a game.

I've added

Code: Select all

missionVariables.ec_payment = this.ec_payment;

in shipWillLaunchFromStation function and it seems enougth for correcting the problem.

I ll try to package the correction on sunday.

[Wildeblood]

Does anyone have a link to the last OXP version Capt. Murphy made of this?

[cim]

That would be 1.5.6, and it's linked (twice) on the [wiki]Escort_Contracts_OXP[/wiki] page.

[Chimrod]

That would be 1.5.6

Are you sure ? Readme declare 1.6.1 and this match the wiki page…

[cim]

Are you sure ?

1.5.6 was the last version made by Capt Murphy, the original author. 1.6.1 is the latest available version.

[Chimrod]

I've created a source git repo for the correction ; the last commit can be download here : oolite_escort_oxp-Payment.zip

This is my first try with oolite scripting, it seems good for me, but any feedback will be apreciated.

Next step : allow the other escort ship to use whichdrive when the mother ship use its own.

[Fritz]

The problem is something different. I don't know why your fix worked, because it didn't work with me. But there is some randomness involved, so the bug doesn't show up every time.

The root problem is that during contract creation, this.ec_contractactualprice and this.ec_killsbonus are initialized and used as arrays (one value for each target system). But these are the same properties that are used as integers for storing the mission variables and for price calculation! This looks very suspicious, because the strange not-a-number payments actually looked like comma-separated arrays (e.g. "1305,570,1039,814"). That was definitely a trail worth following.

The bug would obviously only show up when (randomly) at least two target systems are chosen for contract offers, and with one system we would only get paid the wrong price. But why are offers created after a game including an accepted contract has been loaded?

Depending on the version of the OXP, contract offers are created on loading a game and after docking. When I started to tinker with it, based on version 1.6.2, the latter didn't work. I changed this - did this make the bug (re)appear?

No. I first thought so, but the payment for the finished contract is calculated before creating new contract offers. False trail...

This means that the integer properties are turned into arrays somewhere between loading the game and ending the mission successfully. And this actually can happen: After loading a game, the creation of new contracts is started. And it is started even if the saved game includes an accepted contract! So the values for payment and kill bonus are destroyed immediately after loading the game.

Of course the creation of contract offers shouldn't even be started in this case. If this is fixed, the double usage of the properties doesn't matter anymore, but I'll still change the array names to be safe...