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

[Captain Patrick]

Captain Murphy, I'm glad you're finding my comments useful.

Your idea of the mother getting into trouble when left alone is very reasonable – like lions watching gazelles on the African plains, pirates are always around, looking for their chance at an easy victim (which would be why the player, in a lone ship, is attacked as often as he is).

Lately I have indeed noticed that I'm being offered Viper escorts at 750 cr apiece, so you're right there. I could see a good-rep lone escort being offered somewhat more than that, but not as much as two whole reasonably competent ships together – he's not the only game in town.

As to whether players would take advantage of these offers: there's nothing stopping them from _also_ trading on the same run, or accomplishing some other mission over that way. Indeed, having a full tank for fighting is alone a big inducement when contemplating a long jump into an Anarchy. I'd take the deal for much less if I was going that way anyway – especially if, as I've noticed, unless one starts a fight oneself (ex. just for the kills, or the bonus – though if I were the mother, I wouldn't pay bonus unless I or my escort had been fired on first), more often than not there's no combat at all.

25% less would give a maximum of 1200 cr for a lone escort with a champion reputation into a hazardous system. Given what you've said, I think that's a credible figure, all in all.

By the way, how difficult would it be to implement the presence of one or more other escorts, or even other traders to make entire caravans (with correspondingly more pirates, if there is an attack)? What about ships from other OXPs?

[Capt. Murphy]

No problems Patrick. I'll reduce the prices by 25% for the next release, add the code to limit kills counted for the kill bonus and the tweak to increase the chance of the mother encountering hostiles if the player is gallivanting out of scanner range for to long.

A good way of increasing the difficulty of these contracts is to add Pirate Coves to your installed OXP's. You'll often get into a very satisfying furball as it's not uncommon to find one or two on route to the station, especially in the more dangerous systems.

With regards to increasing the scope to include other NPC escorts, it's not something I intend doing in the near future (and maybe not at all) and would be a lot of work to get all of the AI and balance right. You could hire some hired guns if you wanted to beef up the team, but the money will be coming straight out of your fee. The OXP includes code that should make hired guns play nice with the mother. It was tested a good while ago, but I don't generally use hired guns.

As to including other OXP ships as mothers, yes it can be done, but it means adding a reference for all the potential OXP ship mothers to the shipdata.plist in escort contracts. The release does include this for the Griff versions of the core ships as it stands. An end user could expand the number of potential ships by editing their own copy of shipdata.plist. The snippet below is the section that references Griff's anaconda model. To use another model you could copy and paste in an additional entry and (in general) just change the first two lines to reference another model from another OXP.

You might need to play with the figure in roles = "ec_mother(1)"; for all the entries including the ones for the core ships depending on your exact mix of OXPs, as this affects the probability of a particular model be used.

As is stands the core models have a very low probability compared to the Griff models. This basically ensures that if Griff's is installed, those models are used 99.99%+ of the time, but if not installed the core ones are used instead.

Code: Select all

"griff_normalmapped_anaconda_NPC_ec_mother" =
{
	like_ship = "griff_normalmapped_anaconda_NPC";
	escorts = 0;
	roles = "ec_mother(1)";
	script = "ec_mother.js";
	has_ecm = 1;
	has_escape_pod = 0;
	has_fuel_injection = 1;
	beacon = "M";
	scan_class = "CLASS_ROCK";
	cargo_carried = "PLENTIFUL_GOODS";
	pilot = "oolite-trader";
	scanner_display_color1 = "yellowColor";
	scanner_display_color2 = "magentaColor";
	forward_weapon_type = "WEAPON_BEAM_LASER";
	aft_weapon_type = "WEAPON_BEAM_LASER";
	is_external_dependency = yes;
};

would need to be

Code: Select all

"caduceus-alpha_ec_mother" =
{
	like_ship = "caduceus-alpha";
	escorts = 0;
	roles = "ec_mother(1)";
	script = "ec_mother.js";
	has_ecm = 1;
	has_escape_pod = 0;
	has_fuel_injection = 1;
	beacon = "M";
	scan_class = "CLASS_ROCK";
	cargo_carried = "PLENTIFUL_GOODS";
	pilot = "oolite-trader";
	scanner_display_color1 = "yellowColor";
	scanner_display_color2 = "magentaColor";
	forward_weapon_type = "WEAPON_BEAM_LASER";
	aft_weapon_type = "WEAPON_BEAM_LASER";
	is_external_dependency = yes;
};

to make the caddy available as a potential mother (assuming the OXP is installed). The is_external_dependency entry stops Oolite throwing an error if the target OXP is missing.

[sdrubble]

I'll reduce the prices by 25% for the next release, add the code to limit kills counted for the kill bonus and the tweak to increase the chance of the mother encountering hostiles if the player is gallivanting out of scanner range for to long.

May I add another couple suggestions... add some randomness for the price reduction, and add randomness also to the chance of more hostiles when the player is out of range.

The logic behind the price randomness would be, the contract price MIGHT still be up to the standards the player was previously used to - so some players might accept some contracts and reject others.

The randomness on the lone-mother-pirate-encounters would encourage the player to run the RISK of wandering off a bit, picking up some additional cargo containers from blown-up enemies, all the while being aware of the possibility of losing the contract if he can't reach the re-attacked mother in due time (or, in my particular case, believing I MIGHT have just enough time to collect back the stray Drones and Captured Thargons previouly released... ).

Cheers

[Captain Patrick]

Certainly, any change generally takes some getting used to, particularly if it ends a cash cow. But many players would accept it, if the reasons are good. And if they prefer, they can always tweak it themselves, or stay with an older version.

But I agree that attack on the mother need not be inevitable, if the escort goes out of range. But it should be high, and checked again periodically so long as the situation lasts: when the cat's away, the mice will play.

I have been using Pirate Coves, and agree they do add spice, indeed.

Thanks for the code for alternative mothers. I was thinking especially of of ACDK's Bulk Haulers.OXP . The way that OXPs work, could this code as easily be included in a ship.OXP that the author wants to make compatible with yours?

Would multiple mothers be similarly more complicated (maybe just added at the witchpoint, and their only action is to follow the prime mother, who remains the one paying the salary, and revert to single trader behaviour if she's killed; but maybe a financial penalty for each member of the convoy lost)? Fees could then be higher, so the Player Character could then afford to hire help; ditto perhaps for single moms like the Anaconda that are fatter and slower, and therefore more tempting targets. Pirate bands would then be larger and/or more frequent, of course.

[Capt. Murphy]

Thanks both; Unpredictablility is good and that was my intention with regards to the mother getting into trouble when left unsupervised. Good call on adding a bit of random variation to the pricing as-well.

Patrick, another OXP can include in it's shipdata entries for escort contract mothers, ensuring that the keys I've listed are included.

Multiple mothers? Mmm the whole convoy thing is doable, but I think would need a big rework, particularly on the AI front. I don't think the synchronising jump drives hand-wavium can stretch to more than than a couple of ships so that kind of escorting would have to be either slow or TAF assisted to avoid boredom (which is an option as TAF will now be present in the next stable release, for a good while we thought it would be disabled in the the official release version as a debugging feature). I'll not write the idea off, but don't expect anything in that direction any time soon.

[Switeck]

And with multiple npc ships in a convoy, you risk the faster types running off and leaving the others. The player can at least attempt to match speed either using/not using injectors or even the regular torus if too far behind. The convoy would pile up at the first enemy it stops to fight, but against a large enemy group it would arrive piecemeal and likely die the same if it doesn't stick closely together.

[sdrubble]

@Capt. Murphy,

I just happened to remember a glitch involving Escort Contracts and Save Anywhere. Can't remember for sure which version of EC I was using (I'm currently at 1.4.2, but it *might* have happened with the previous one). As for SA, it was 3.1 (SA 3.2 is still waiting to be tested here, as I haven't been playing much lately).

The glitch was: frequently when saving at a Rock Hermit, and just upon being quickly whisked to the main Station in order to perform the save, the contract offer screen from EC was the first screen shown after docked to the Station, and I had to select the 'Not Interested' option in order to proceed with the save (and the subsequent immediate teleport back to the Hermit).

I didn't actually try to select a contract option in the EC screen, so I can't tell what would have happened next if I did. But my understanding is that, since the docking at the Station under the direction of SA is just some form of quick and temporary voodoo in order to allow the actual gamesave, no EC screen should be allowed to appear and offer options to the player on such an occasion.

While the glitch might have been already solved with SA 3.2, I can't tell for sure as I haven't used that version yet. OTOH the problem might be in EC itself.

Sorry for not giving more precise info - all of this is from memory, from a number of weeks back, since I haven't been playing very frequently. Hope you can find and fix the glitch.

Cheers

[Capt. Murphy]

Thanks SDrubble. Interesting find - I don't use Save Anywhere but will install and see what happens.

[Eric Walch]

Thanks SDrubble. Interesting find - I don't use Save Anywhere but will install and see what happens.

I don't think it will be solvable. You can only save at a main station, so SA launched the player from the special station and docks it at the main station for saving. At that moment any pending mission info can pop up as the code just thinks the player has docked at the main station.

Generally, I think you should not use SA when doing missions as there is a potential risk it will corrupt a mission. e.g. when the player is not supposed to dock at the main station before he has done a special action.

[Thargoid]

SA sets (or at least used to set) a mission variable when it's active, which can be used to suppress some things like mission screens (but not transport contracts or escape pod pick-up rewards). That kind of check is already implemented within Planetfall for example to stop the re-orientation and relocation which otherwise happens on planetary launch.

[Eric Walch]

SA sets (or at least used to set) a mission variable when it's active, which can be used to suppress some things like mission screens

Yes, but not all missions want to use that. I remember the big fight at the end of Cataclism.oxp. During that battle in deep space the player has to dock 3 times at the remote station before he is able to dock at a main station again. That is part of the charm that it takes about one hour of fighting/exploring before the player can save his game. If he fails in one of the steps, he has to start all over, what brings an extra excitement in such a final battle. So its not likely to be changed in allowing to save a game in between and if the player tries with SA, he probably has lost the mission progress because of the visit to the main station in between.

And there might be more missions with similar restrictions, so my warning to use SA on your own risk during a mission.

[Smivs]

And there might be more missions with similar restrictions, so my warning to use SA on your own risk during a mission.

Worth a mention that this is also the case for the end-game in Xeptatl's Sword. When you jump to the target system you MUST go to the 'mission' station. You must NOT dock at the main station, or you'll break everything

[sdrubble]

@All,

some thoughts on the above...

Generally, I think you should not use SA when doing missions as there is a potential risk it will corrupt a mission.

Indeed - but I hope you have noticed that the case I've presented is actually the exact OPPOSITE! I get OFFERED a new mission right in the middle of SA's magic.

SA sets (or at least used to set) a mission variable when it's active, which can be used to suppress some things like mission screens...

... which is actually the method I thought that Capt. Murphy would use to block EC's mission offer in this case.

...suppress some things like mission screens (but not transport contracts or escape pod pick-up rewards)

Well, to me the mere presentation of rewards for accomplished stuff would be OK, even if in the middle of an SA operation... after all, it's only a pause for presenting info, and in these situations all the player can do is "Press Space" and proceed as usual.

Which is NOT what is happening with EC, which presents a choice of new missions and actually LETS the player [attempt to] start a new one in the middle of an operation by SA.

I remember the big fight at the end of Cataclism.oxp. During that battle in deep space the player has to dock 3 times at the remote station before he is able to dock at a main station again. That is part of the charm that it takes about one hour of fighting/exploring before the player can save his game. If he fails in one of the steps, he has to start all over, what brings an extra excitement in such a final battle. So its not likely to be changed in allowing to save a game in between and if the player tries with SA, he probably has lost the mission progress because of the visit to the main station in between.

...this is also the case for the end-game in Xeptatl's Sword. When you jump to the target system you MUST go to the 'mission' station. You must NOT dock at the main station, or you'll break everything

Well, thank you both for the heads-ups... I'll try to remember to be careful with this stuff when doing long and involved missions. But OTOH... there isn't really anything that would break SOOOO badly that a previous savegame wouldn't fix (coupled of course with some hours of oh-dammit-lets-do-this-final-stuff-all-over again... ) - unless of course we proceed with play and do a lot more saves before even realizing that something broke waaaaay back.

Cheers and thx all

[Thargoid]

The reminder was simply for OXP makers who may not be aware that Frame already thought of this kind of scenario and put it into SA for others to use. I know about it as SA and PF are of roughly the same vintage, but authors of newer ones may not be (given SA's rather unusual history).

[Capt. Murphy]

Without testing it looks fairly straight-forward to include a check for missionVariables.framesave === "MoveToOxpStation", or for the presence of "EQ_FRAME_SAVE" in the players equipment both of which appear to be true just prior to Save Anywhere's scripted docking with the mainStation, and then suppress Escort Contract's mission screens if it is set to that value.

I bet it conflicts with Illegal Goods Tweak as-well....

edit to add - I've PM'd Frame to request that he include a list of other OXP accessible variables and their states throughout the SA process in the SA read-me to assist OXP makers to avoid conflicts.