Oolite Bulletins

Dragonfire wrote:

It's a GAME, people. May the next person who brings up how "realistic" Oolite's physics are be tied to a rabid Thargoid.

At least you didn't say it's just a game.

If you ask me, anyone who thinks reality is more important than the game...needs to just get a life.

(That's a joke, think about it...)

I rather agree with KW and McLane's comments. This has got me thinking about something else. Perhaps being able to read the stats of the player and the ship have more application in simply setting a difficulty level for the game generally. Oxp ship makers could put in conditions for their ships so that they only appear when the player is of high enough skill and perhaps also check maxEnergy and maxSpeed. It would be a never ending job to do it from the outside as ship oxp's are constantly evolving and new ones being introduced. This would put some responsibility into the hands of the creators of tough or uber ships.

CommonSenseOTB wrote:

I rather agree with KW and McLane's comments. This has got me thinking about something else. Perhaps being able to read the stats of the player and the ship have more application in simply setting a difficulty level for the game generally. Oxp ship makers could put in conditions for their ships so that they only appear when the player is of high enough skill and perhaps also check maxEnergy and maxSpeed. It would be a never ending job to do it from the outside as ship oxp's are constantly evolving and new ones being introduced. This would put some responsibility into the hands of the creators of tough or uber ships.

Yes, quite interesting statements, because it tells us a bit more about the problem extremes can cause. I'd agree that nothing is wrong with strong entities per se, only when, how often and where they are appearing can be a problem for missions.

We've had such a approach a while back via OXP (see https://bb.oolite.space/viewtopic.php?f=4&t=5618). Could be interesting to defibrillate this thing.

The idea was simple (though the script wasn't). One missionVariable + conditions in shipdata for stronger entities, with a script that sets the level based on incoming requests by OXP scripts. There was additionally a mechanism to 'protect' the native inbuild missions and a cleaning mechanism to help Vista users with the 'out of memory' problem and to get rid of the loading order thingummie. It worked (more or less) with JS and XML/OpenStep scripts.

Today we have a lot more possibilities, but a mechanism can't solve all problems in a wide open engine - only OXPers can help to avoid problems, either by collaborating to a mechanism or by thinking about the needs of other OXPs.

I like the idea of a mission whose difficulty varies depending on your stats. It unfortunately makes more work for the poor mission designer, but their extra effort would be greatly appreciated. As I remain firmly in the camp where anyone is allowed to make anything that is possible into an oxp, I would say that the same control should extend to the mission designers as well, in that they should be able to balance things out so that the mission can proceed the way that they envisioned it. Which is rather hard to do when there are extreme ships about. Whilst still agreeing with both sides, I would have the greatest respect for any designers who build multi-difficulty missions and reckon they would be a good thing to have!

As I said earlier - the easiest way for the Mission designer is (if allowed via js) to spot check certain attributes of the player's ship and if "uber" the mission doesn't start. The player makes their choice, so does the mission designer.

DaddyHoggy wrote:

As I said earlier - the easiest way for the Mission designer is (if allowed via js) to spot check certain attributes of the player's ship and if "uber" the mission doesn't start. The player makes their choice, so does the mission designer.

On the one hand, preventing a mission from starting is a simple solution, but presumably that means there's only one point of ship evaluation. There's potentially nothing stopping a player from upgrading once the mission starts. In that regard, mission writers won't get away from the need to periodically evaluate the player ship (and perhaps write in appropriate mission exits accordingly).

On the other hand, if a player is so intent on cheating, well in a single player game like Oolite, they are only cheating themselves.

I don't think it's practical (or even fair) to expect mission designers to create challenges that can adapt to the huge range of possible OXP mixes out there. Even classing player ships by some calculation of übericity is going to be difficult, because sometimes it's not what the player is flying that's important – it's what else is going on in the player's universe. Various mission scenarios could be interfered with by e.g. a mix of OXPs that provide a lot of easy refuelling opportunities, say, or that plant a heavy Navy presence in a particular area. People will also bring out "wangle" OXPs, too, like the Fuel Collector, GalDrivePod or HyperCargo, which are hard to anticipate. This is not to single out or criticise these and other similar OXPs, or to say that people shouldn't continue to push Oolite's envelope, but – by circumventing certain built-in restrictions in the game – they can make it difficult to write missions which depend on those restrictions to provide a challenge.

I'd favour a lo-fi approach: mission authors could give a brief overview of the sort of ship-and-universe mix they think their missions are aimed at. A bit like the old RPG scenarios: "this scenario is intended for a party of 4-6 players, levels 6-9, with at least one Cleric". If someone insists on doing the mission with the equivalent of a party of 18 demigods, each one with an army of immortal Holy Warriors tucked into in their Socks of Surprise +10, then they probably won't have much fun playing it.

"Socks of Surprise"

sounds like a good OXP right there.

Disembodied wrote:

I don't think it's practical (or even fair) to expect mission designers to create challenges that can adapt to the huge range of possible OXP mixes out there. Even classing player ships by some calculation of übericity is going to be difficult, because sometimes it's not what the player is flying that's important – it's what else is going on in the player's universe. Various mission scenarios could be interfered with by e.g. a mix of OXPs that provide a lot of easy refuelling opportunities, say, or that plant a heavy Navy presence in a particular area. People will also bring out "wangle" OXPs, too, like the Fuel Collector, GalDrivePod or HyperCargo, which are hard to anticipate. This is not to single out or criticise these and other similar OXPs, or to say that people shouldn't continue to push Oolite's envelope, but – by circumventing certain built-in restrictions in the game – they can make it difficult to write missions which depend on those restrictions to provide a challenge.

I'd favour a lo-fi approach: mission authors could give a brief overview of the sort of ship-and-universe mix they think their missions are aimed at. A bit like the old RPG scenarios: "this scenario is intended for a party of 4-6 players, levels 6-9, with at least one Cleric". If someone insists on doing the mission with the equivalent of a party of 18 demigods, each one with an army of immortal Holy Warriors tucked into in their Socks of Surprise +10, then they probably won't have much fun playing it.

You and Gary Gygax (the creator of Dungeon's & Dragons) can sit down and roll a 20-sided dice. You rolled a 1. I'm sorry. Your laser cooling booster appears not to be working at the moment and , what's this, you just noticed a group of 10 more pirate ships approaching. The fuel injectors also seem to be in some difficulty. Oh My! You have the initiative and 1 free attack at -3 to hit due to Trumbles. What do you do?










<Press Space Commander>

The ideas behind such a mechanism could be:
- missions could need some control about the environment. The level of control depends on the type of mission (thanks CMcL).
- not all user are reading documentations, readmes, WIKI pages or onscreen messages.
- most user can't know about the internal interactions between OXPs in all details, means they can't do informed choices.
- BB members are only one part of the users out there (good reminder Ganelon).
- a mechanism can help, but not solve this dilemma without a clear, discussed and agreed approach.

So before we can start to think about the mechanism itself - what makes it so difficult to control the environment?
I mean, if we identify the biggest difficulties we can work out solutions.

Ok, so let's make it more concrete.

1. Strong entities that are spawned without a mission context could use conditions in shipdata.
The checked mV could maybe use 5 different level, the higher the number the more dangerous the entity.

2. Strong entities for mission contexts could use a script_info key that excludes them from the mechanism completely.
This will avoid unwanted things when two or more missions are running.

3. The mechanism could work on a 'per system' base - if the current system is not in the list nothing will happen.
This means that OXPs which are spawning entities in all systems won't be harmed and only dampened for a short period of time.

4. To claim a specific system a script only has to pass a object with a few properties. After leaving that system this entry gets deleted, so the player will get the full set on next visit again.
- Question: What should it do if already claimed? Merge? Refuse? Use the lower settings?

5. The mechanism can be adjusted via the passed obj.

Bear in mind that even if a mechanism is introduced to check ship stats in the shipdata.plist of the player's ship, someone could just go through the javascript and change the variables that the ship's stats need to be under to receive the mission and I don't think it would be any more difficult than editing a .plist in xml format currently is.

Sure, but the idea is not to make cheating/editing unavailable. The idea is to help avoiding clashes between OXPs which are happening mostly silently. If we start thinking about locking codeparts then we are in trouble, so let's keep these things as open as possible - for the commoonity.-)

Svengali wrote:

The idea is to help avoiding clashes between OXPs which are happening mostly silently. If we start thinking about locking codeparts then we are in trouble, so let's keep these things as open as possible - for the commoonity.-)

This problem was discussed here. And the mechanism is used in OresratiChallenge.

It will be nice to have a standard mechanism avoiding mission clashes, but I think most of the OXP authors do not care