Escort mission : bug report
Moderators: winston, another_commander
Escort mission : bug report
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 !
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 !
Re: Escort mission : bug report
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.
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.
Re: Escort mission : bug report
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 :
although every variables are saved.
Well, I'll take some time for seeing what can be done here…
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.
Well, I'll take some time for seeing what can be done here…
- Cody
- Sharp Shooter Spam Assassin
- Posts: 16081
- Joined: Sat Jul 04, 2009 9:31 pm
- Location: The Lizard's Claw
- Contact:
Re: Escort mission : bug report
All the OXPs available via the in-game manager can be downloaded from here.Chimrod wrote:I've seen some zip to download from box.com, but is there a source repository for all of them ?
I would advise stilts for the quagmires, and camels for the snowy hills
And any survivors, their debts I will certainly pay. There's always a way!
And any survivors, their debts I will certainly pay. There's always a way!
- Norby
- ---- E L I T E ----
- Posts: 2577
- Joined: Mon May 20, 2013 9:53 pm
- Location: Budapest, Hungary (Mainly Agricultural Democracy, TL10)
- Contact:
Re: Escort mission : bug report
http://www.oolite.org/oxps/ - this is used by the in-game expansion manager. If you make a fix then I can upload it.Chimrod wrote:is there a source repository for all of them ?
Re: Escort mission : bug report
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
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
- ---- E L I T E ----
- Posts: 2577
- Joined: Mon May 20, 2013 9:53 pm
- Location: Budapest, Hungary (Mainly Agricultural Democracy, TL10)
- Contact:
Re: Escort mission : bug report
Which provide a chance to get 60 times speedup if cached in a local variable.cim wrote:missionVariables
can also be used for storage
Re: Escort mission : bug report
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)Norby wrote:Which provide a chance to get 60 times speedup if cached in a local variable.cim wrote:missionVariables
can also be used for storage
Re: Escort mission : bug report
Got it !
The variable missionVariables.ec_payment where not initialialized when loading a game.
I've added in shipWillLaunchFromStation function and it seems enougth for correcting the problem.
I ll try to package the correction on sunday.
The variable missionVariables.ec_payment where not initialialized when loading a game.
I've added
Code: Select all
missionVariables.ec_payment = this.ec_payment;
I ll try to package the correction on sunday.
- Wildeblood
- ---- E L I T E ----
- Posts: 2446
- Joined: Sat Jun 11, 2011 6:07 am
- Location: Western Australia
- Contact:
Re: Escort mission : bug report
Does anyone have a link to the last OXP version Capt. Murphy made of this?
Re: Escort mission : bug report
That would be 1.5.6, and it's linked (twice) on the [wiki]Escort_Contracts_OXP[/wiki] page.
Re: Escort mission : bug report
Are you sure ? Readme declare 1.6.1 and this match the wiki page…That would be 1.5.6
Re: Escort mission : bug report
1.5.6 was the last version made by Capt Murphy, the original author. 1.6.1 is the latest available version.Chimrod wrote:Are you sure ?
Re: Escort mission : bug report
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.
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.
-
- ---- E L I T E ----
- Posts: 591
- Joined: Sun Jul 12, 2015 2:30 pm
- Location: Bavaria, Germany
- Contact:
Re: Escort mission : bug report
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...
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...
"You wouldn't kill me just for a few credits, would you?" – "No, I'll do it just for the fun!"