[UPDATED RELEASE] - Escort Contracts OXP - 1.5.6 (07/05/12)

[Fritz]

Perhaps "logical flaw" was not the right choice of words. Of course it was a design decision, because it definitely didn't look like a bug! But for me (as a player) this didn't look right. For a start, it looked as if the OXP wasn't working correctly, because I quickly arrived in an anarchy, and there I didn't get new contracts. It isn't mentioned in the wiki, and it isn't mentioned in the readme text. And probably, only a minority of players will look at the code to see what's happening...

a trader travelling to a system as safe or safer than the one he was already in would not feel the need to hire an escort.

Why not? When I made it to an unsafe system and survived the trip only because of my escort, why shouldn't I feel the need for an escort if I go to another unsafe system from there? Or why should I feel the need for an escort if I go from a democracy to a dictatorship, but no need if I go from an multi-government to the same dictatorship? And why shouldn't an ITHA office exist in anarchy systems, when GalCop can safely operate a giant space station? Apart from this, the office is only needed for buying the license, and this isn't possible in feudal or multi-government systems too. The actual deals could be made in the station bars (as is the payment).

So from a fiction viewpoint, my changes can be justified. But that's not the main point:

If a player installs the OXP, buys the license and has fun escorting traders, why should he be impeded by the "rules" you mentioned? After one or two escort runs, the player will definitely be in an anarchy or in a feudal system without anarchy neighbours, and then he can't go on. And he doesn't even know why, because it isn't in the description.

This is made even more frustrating by the fact, that the few suitable systems in range may be omitted because of the random factor. With a "newbie" reputation of zero, the probability of getting a contract is 0.4 x 0.5 = 0.2 per available target system, and that's why the "0 contracts available" bug appeared so often: The first factor (0.2 to 0.8 depending on reputation) gave its OK, but then the second factor of 0.5 could still rule out all of the (few) available systems. Of course this still can happen in my version, the chances depending on how much I reduce the chance of a possible target system to be actually selected for an offer. This chance should be connected to government type, contracts to unsafe systems having a better chance of being offered.

Actually, the selection mechanism is one of several things I would like to be configurable for the player in a future version (using OXPConfig). Some players probably want contracts to be available every time or at least relatively often, and others want them to be rare. Until then, I'll define and explain the relevant values at the beginning of the code so that they can be easily modified without having to dig deep into the code. If it is wished, I could keep the old selection logic in the code as an alternative (the code changes between both versions are minimal).

It seems to have appeared as other people have started altering the OXP.

Difficult to say, but possible. At some point (I think with version 1.6.0) the user interface was changed completely. This was probably the biggest change in the history of the OXP, and this probably introduced the bug. I think, in earlier versions, the contracts were offered immediately after docking and not on the F4 screen.

[Fritz]

As for the changes I made, they were pretty minor actually. The first change was just to add a screen ID to all the mission screens so that Xenon UI didn't remove all the backgrounds. The screen ID I put in was "escort-contracts".

The other change was to alter the "contract_chart" item in "missiontext.plist"

I hope that helps a bit!

You forgot to mention the HUD switching, but that was very helpful, and it is working already.


Edit: No, it isn't working. The HUD doesn't reappear after leaving the mission screens, but this is probably a bug in my version and not yours.

[phkb]

Ah, yes, sorry, I did forget that. Make sure this code is in the "ec_leaveScreen" function:

Code: Select all

// function used if player leaves mission screens to look at charts.
this.ec_leaveScreen = function()
{
	if (this.$isBigGuiActive() == false) {
		player.ship.hudHidden = false;
	}
	<snip>

That should turn the HUD back on.

[Fritz]

Ah, yes, sorry, I did forget that.

I noticed that after I installed your version and it didn't work either. But strange that nobody noticed - most people seem to use the Xenon HUD!

Make sure this code is in the "ec_leaveScreen" function:

The code was in ec_leaveScreen() already, but this function is only called when you select "Decline all". But the HUD must also be turned on when selecting "Agree" in ec_contractchoice2() and ec_contractchoice4(). Strangely it has to be before the next mission screen is called, otherwise "press space" doesn't work.

[phkb]

most people seem to use the Xenon HUD

Including me, it would seem! I did put my fix together rather quickly, which obviously shows. I'm glad you're taking up the challenge of getting it working, though. Well done!

[Fritz]

50% of my real life job is to find bugs. The other 50% I spend making bugs!

[Fritz]

I'm wondering about a little detail of the OXP: The license you have to buy before getting escort contracts is technically a piece of equipment. Of course, it shouldn't be damaged in battle. To prevent this, the code contains the following:

Code: Select all

this.equipmentDamaged = function(equipment)
{if(equipment === "EQ_ESCORTCONTRACTS"){player.ship.setEquipmentStatus(equipment,"EQUIPMENT_OK");}}

Actually, the license can be damaged but is immediately repaired. This seems to work fine, but doesn't this reduce the probability of other equipment being damaged? And why isn't damage_probability in equipment.plist simply set to 0? The answer to the latter is probably that damage_probability was added to Oolite with Version 1.77, and the OXP is older.

Damage behaviour is difficult to test (and very dangerous! ), but I don't see a reason why the much simpler entry in equipment.plist shouldn't be used in this case. Or do I overlook something?

[phkb]

I think you're correct in your assumptions. I think the damage probability should be set to zero, and the code streamlined to suit.

[Fritz]

I just did some severe testing, and the license seems to be undamageable. (It is amazing how bad NPCs aim if you want them to hit you...)

[Amah]

I just did some severe testing, and the license seems to be undamageable.

license stays intact here too, but I just tried three times.

(It is amazing how bad NPCs aim if you want them to hit you...)

Mylord, I have a cunning plan !

[Fritz]

I'm planning to release the new version tonight or tomorrow night. Should I start a new thread? This one contains the original introduction, and it seems that the first post by Capt. Murphy has been updated with each new release until version 1.5.6. But later changes by other users (versions 1.6.x) are hidden deep inside the thread, because only Capt. Murphy can change subject and original post. So I think, starting a new thread (and closing this one) wouldn't be a bad idea.

[Cody]

<nods> New thread, suitably titled with a link back to this thread, should serve.

[Fritz]

Ok. I'll have to make new screenshots too, because the user interface has changed (with version 1.6.1 already).

Btw, is there any convention which date format should be used? It's a mix of MM/DD/YY and DD/MM/YY in the version history of this OXP.

[Captain Patrick]

YYYY-MM-DD is unambiguous, sortable, and the only one I ever use anymore.

[Fritz]

Yes, I prefer it too, at least when I'm writing something that won't be read in Germany only. We should use it in Germany too (it's DIN EN 28601), but nobody does.