Oolite Bulletins

Ahruman wrote:

getSystemName()

Done, as System.systemNameForID(ID : Number) : String. There’s also a System.systemIDForName(name : String) : Number. Note that that’s System for systems in general, rather than system for this specific system. Except that, due to the way JavaScript’s prototype-based inheritance works, the two are interchangeable. Whee!

Ahruman wrote:

Done, as System.systemNameForID(ID : Number) : String. There’s also a System.systemIDForName(name : String) : Number. Note that that’s System for systems in general, rather than system for this specific system. Except that, due to the way JavaScript’s prototype-based inheritance works, the two are interchangeable. Whee!

Thank, that makes great things possible for random missions. certainly better than my current UPS messages: go to system nr 56.

Ahruman, in the Wiki with: function resetMissionChoice() you write:

(Open issue: why not just make choice read/write? --ahruman)

You are looking for a reason to make it read/write? There is a very good one. see: https://bb.oolite.space/viewtopic.php?p=47746#47746

Ahruman wrote:

In principle, you could do that by redefining EQ_FUEL to have a tech level of 99, then set missionVariables["TL_FOR_EQ_FUEL"] to control availability. Not entirely elegant, I admit.

I tried to do that in Salvage Gangs. The idea was to make second-hand equipment available instead of ordinary equipment, not additional to it.

But it didn't work. For some reason set: mission_TL_FOR_EQ_ECM 99 has no effect on the availability. So the ECM was still offered at the low TL station. The same goes for all the other equipment.

wait, if I understand it correctly, you first need to overwrite the ecm inside your oxp's equipment.plist

What I did, I put this inside my own equipment.plist
so now EQ_FUEL has a standard tech of 99. Then I lower it as required using set missionVariables["TL_FOR_EQ_FUEL"] (well, the javascript equivalent, really... )

It seems to work here. The way I understand it, it only works if you lower the tech level from 99 to a lower value, not the other way round.

edit: if this works for you, does it mean we'll see a new updated anarchies. oxp?

This should work for the trunk version, but the 1.70 one does not substitute same entries in equipment.plist, it adds them on top of the standard equipment instead.

mission_TL_FOR_EQ_FOO is only consulted if the tech level in equipment.plist is 99. Y’know, just like I said. ;-)

another_commander wrote:

This should work for the trunk version, but the 1.70 one does not substitute same entries in equipment.plist, it adds them on top of the standard equipment instead.

Ahh, the man makes a good point.

Does it mean we'll have a 1.71 test release in the near future, to appease the baying crowds?

Kaks wrote:

edit: if this works for you, does it mean we'll see a new updated anarchies. oxp?

Would you like to see one? Any specific wishes for increased functionality? Or bugs to be squashed? (Actually I haven't received a single bug report concerning Anarchies1.0. Would that in the end mean there are none? )

But yes, sooner or later there will be an updated version. Although it will rather deal with typos in the ReadMe, and a few cosmetic additions to the asteroid models (flashers).

another_commander wrote:

This should work for the trunk version, but the 1.70 one does not substitute same entries in equipment.plist, it adds them on top of the standard equipment instead.

Does the first part of this sentence mean that in 1.71 equally named equipment will substitute same entries? In that case I could use a different approach for the salvaged equipment items, and make them available alternatively to the standard ones.

By the way: Has anybody had bad experiences with salvaged and refurbished equipment yet?

Commander McLane wrote:

another_commander wrote:

This should work for the trunk version, but the 1.70 one does not substitute same entries in equipment.plist, it adds them on top of the standard equipment instead.

Does the first part of this sentence mean that in 1.71 equally named equipment will substitute same entries? In that case I could use a different approach for the salvaged equipment items, and make them available alternatively to the standard ones.

In 1.71, the reference key for equipment is the EQ_* string. Any equipment will be substituted by same EQ_* tagged equipment that gets loaded after (e.g. an OXP EQ_FUEL will substitute the default EQ_FUEL). Basically, the equipment.plist will behave like any other game dictionary, where merging same data results in substitution, although the equipment.plist itself is not a dictionary, but an array.

Kaks wrote:

Does it mean we'll have a 1.71 test release in the near future, to appease the baying crowds? :D

Hrm. The primary blocker would be the JavaScript object hierarchy, which has turned out to be comprehensively broken. I think I know how to fix it, but it will require a migraine-free weekend. Such as the one possibly coming up.

Then there’s all that leaking it seems to do on other people’s computers… but at least we’ve fixed the systemData one.

Request for new function in the mission object: showSystem(systemNumber : Number)

Without systemnumber it should just display the long-Range chart and with a parameter it sets the cursor at this planet like the find command does. This is the same way as the contract screen displays the destination systems.

In UPS I started using this using the markSystem() function for this. One major drawback of that function is that when the player decides to not go to that system, the system is unmarked at the end, even when it was marked before by an other OXP. For UPS this is not a real problem as missions are rare and there is not a choice offered. The player is likely to go to that system anyhow. But when the player can choose from several options like HandomHits, the chance becomes larger that one of the destinations was already selected by an other oxp and will be deselected by an unmarkSystem()

The new function showSystem() just should set the cursor at the system and not select it yet as destination. (find system) For switching between missionscreen and the long-Range screen this is enough as the other part is already functioning in UPS and with the new GUI-screen-switched handlers in 1.71 switching between mission- and long-range screen will even be easier than in 1.70.

The use of a long Range screen as part of a mission offering does enlarges the chance of a minor mission clash. In my original proposal for clash-free programming I not only proposed to do nothing when the missionscreen was on display but I also insisted on the use of a second variable ("mission_offering") to protect multi-screen offerings from clashing. I already witnessed the first clash with UPS on this screen. A oxp that only looks for the missionscreen will put up his own mission screen at the moment the player goes to the long-Range screen. It is not a severe clash as the first oxp gets control again when the second OXP leaves the missionscreen. To prevent this type of minor clashes it must be made clear to al OXP writers to not only check for the missionscreen but also don't make an offer when there is an active mission.choice.

Eric's suggestion from Emancipate the Slaves thread:

Request for a function like: amount = player.hasCargo("cargoName").

Also a removeCargo() counterpart to awardCargo() would be useful.

In addition to removeCargo() a function like sellCargo() could be just as friendly: same as removeCargo() but now refunding the removed cargo against local prises.

Sounds fair to me!

Mind you, instead of .hasCargo('cargo name') I'd have .cargoQty('cargo name')