Oolite Bulletins

Visibility to the player's reputation has been added with the player.contractReputation and player.passengerReputation properties. Also added are the JS methods player.increaseContractReputation(), player.decreaseContractReputation(), player.increasePassengerReputation() and player.decreasePassengerReputation().

This should give enough control to scripters to manipulate the player's reputation for both cargo and passenger contracts as they see fit.

Thanks, cool

Note that this has no influence at all on the fees you get for the F8-F8-screen passenger contracts.

It just means that a scripter can make missions available depending on the current reputation of the player. Or he can increase of decrease the player's reputation, depending on the outcome of a mission.

But it doesn't make the built-in passenger-carrier career profitable, so it is not the solution Neo_Jesus requested. As I said before, this solution cannot be reached by scripting.

@Cmdr M - surely now, somebody could knock out a oxp that could "enhance"/surplant the in-built alternative career path? i.e. offering alt. passenger jobs that do offer additional rewards - you'd still get the ingame one but they could be ignored in favour of the oxp ones?

DaddyHoggy wrote:

@Cmdr M - surely now, somebody could knock out a oxp that could "enhance"/surplant the in-built alternative career path? i.e. offering alt. passenger jobs that do offer additional rewards -

e.g the oxp deposed.oxp is mainly a passenger transport. When one would write a similar new one, you don't look at the initial hitpoints but at the players reputation. That is a much better criteria to offer a passenger transport mission. You just have to warn people in the readme that the oxp only starts with a good reputation.

Eric Walch wrote:

e.g the oxp deposed.oxp is mainly a passenger transport. When one would write a similar new one, you don't look at the initial hitpoints but at the players reputation. That is a much better criteria to offer a passenger transport mission. You just have to warn people in the readme that the oxp only starts with a good reputation.

Well, it all starts as what seems to be a passenger transport. To be fair, the plot of Deposed does take some development from there.

But of course it would make perfect sense to make it depend on a certain reputation.

And of course I can easily imagine a similar OXP (and you could use the cargo-reputation as well). But not by me (at least not until I get at least one of my currently 4-6 WIPs finished ).

After working hard to get an salvage.oxp working with script generated derelicts, I encountered a major problem with real derelicts. I missed that also the maxSpeed is set back to zero. To resurrect the derelict ships I need a possibility to set maxSpeed back to its original value in shipdata.plist. (I don't want it read/write)

I see two possibilities to do this.

1) Add a new function resetMaxSpeed().

2) Build on the stuff that Giles already put in the code for salvaging purpose. I think special at the function: that is already in ShipEntity.m Declare this an official AI command and add the line to the function declarations.

This would restore the ship completely to a completely working one. A JS script than can give the derelict a new AI file that at some place contains the command: pilotArrived to resurrect the ship.

I think this function original was mend to work this way. Now it is just unused code.

Done – Ahruman

The possibility to access pseudoFixedD100_numbers and pseudoFixedD256_numbers from JS.

This is the last obstacle that prevents Anarchies from being fully translated into JS (about 90% is done ).

Or, if we already can do that, please tell me how to.

Done – Ahruman

Not a request for a new functionality, but for a change in the existing one. I would like the shipLaunchedEscapePod-event handler to fire a little earlier. To be precise: before player.bounty is reset to 0.

Anarchies bypasses the getting-clean-via-using-the-escape-pod by keeping track of the player.bounty all the time and restoring it when the player has arrived on the station after using the escape pod. It would be much easier to just store the bounty in a variable the moment the escape pod is launched. Unfortunately at the time when the script attached to the shipLaunchedEscapePod-event hanlder is run, player.bounty is already 0, so currently I can't store its value then.

If you don't want to change the existing event handler, I would alternatively request a new event handler which is fired before the player.bounty is reset. Something like shipWillLaunchEscapePod.

Commander McLane wrote:

Not a request for a new functionality, but for a change in the existing one. I would like the shipLaunchedEscapePod-event handler to fire a little earlier. To be precise: before player.bounty is reset to 0.

Looking in the code I think there is no problem to reset bounty after the handler. (can't do it myself).

To the pseudoFixedD256_numbers. Yes, I also would like to have a fixed random value based on system. For the location of grs station I now use the plain system number as sort of random number. (the numbers look randomly distributed over the system).

Commander McLane wrote:

Not a request for a new functionality, but for a change in the existing one. I would like the shipLaunchedEscapePod-event handler to fire a little earlier. To be precise: before player.bounty is reset to 0.

Done.

Would it be possible to program a station so that you can fly into it, choose from a list of custom paint jobs and fly out again?

No.

Damn.

ps. I sense doubt.




J/k :p

Done – Ahruman

Javascript

loadSound("sound.ogg")
playSound.("sound.ogg")

whereby sounds can overlap... playMusic will stop any current music playing...

And it seems everyone has a hyperradio these days ...


not sure how much effort there would be in making this possible...