Scripting requests

[Lestradae]

I would like to have a flag built into the shipdata.plist that simply states:

Can dock? yes/no

It would be very practical to avoid ramming issues with big ships that don't fit through standard docking while still being able to utilise the standard AIs.

If "can dock - no" is switched on, the ship could simply be sent back to it's AI's starting point instead of the (possibly futile) docking attempt.

After a suggestion of DaddyHoggy.

[DaddyHoggy]

Wow - I made a sensible suggestion! Somebody take note of the time and date! It's only taken 1100+ postings!

[Thargoid]

If the ship's AI is written correctly, that's all unnecessary. It's not too hard to write an AI that doesn't try to dock a big ship (look in Aquatics for an example, if I can do it anyone can).

Specifically in your suggestion having the AI go back to its global entry state would just make it (usually) filter back down to the point where it tried to dock. So you'd eventually end up with a cloud of big ships sat around the dockable entities quietly having mental breakdowns as their AIs were stuck in an infinite loop, or crashing into each other anyway or at least just getting in the way of everything.

The ships are only trying to dock because their AIs are telling them to. That's the bit that needs fixing, not shipdata.plist

[Eric Walch]

Can dock? yes/no

If "can dock - no" is switched on, the ship could simply be sent back to it's AI's starting point instead of the (possibly futile) docking attempt.

I see as problem that the AI than hangs as it will not be prepared for such an occasion. And when you write a new AI for this to catch this exception you might as well write an AI that doesn't dock in the first place.

[DaddyHoggy]

Darn - still haven't made a sensible suggestion then! Oh well, time to break out the infinite number of monkeys....

[Commander McLane]

time to break out the infinite number of monkeys....

Someone pointed out that this might be a myth, as in reality the infinite number of monkey already exists and hasn't produced any complete Shakespeare yet. It's called the Internet.

[JensAyton]

Someone pointed out that this might be a myth, as in reality the infinite number of monkey already exists and hasn't produced any complete Shakespeare yet. It's called the Internet.

http://www.gutenberg.org/browse/authors/s#a65

[Thargoid]

Could commodities.plist be made to work in comparison with any of an entities roles, rather than just its primary one?

[Commander McLane]

Could commodities.plist be made to work in comparison with any of an entities roles, rather than just its primary one?

As long as nobody messes with the roles, and for instance gives both roles rock-hermit and Planetary_Capital to the same entity.

Although for your case you need a couple of different commodities.plist-entries anyway. I wouldn't expect prices to be the same in all planetary capitals, regardless of economy.

[Thargoid]

Not really on the Capital front, as the randomness and economy variation should be enough to make that work. It's just a pain that I'm stuck with an all or nothing commodities.plist entry for the planet at the moment.

Or an alternative could be a shipdata.plist key which points at the commodities.plist entry, rather than relying just on the name in commodities.plist itself.

[Commander McLane]

Not really on the Capital front, as the randomness and economy variation should be enough to make that work.

True, should've known that.

Anyway, I still think you can get around the primary role limitation by a different way of calling your 'ports'. Have one entry for each possible port (prices and available goods in the planetary capital would be different from e.g. a penitential colony on the same planet), and then call for one of these primary roles in your random call routine.

[Commander McLane]

Add a new Entity type Wormhole. (Actually I guess it's already there, just not accessible in JS.)

So, to be more precise, and not get stuck with the correct nomenclatura: Make wormholes accessible via JS.

E.g. I'd like to make them available as a property of system (like system.planets).

Wormhole itself should have properties like 'destination'.

What this really is all about: I want to combine this with my request to make misjumps scriptable. So that the player ends up in interstellar space if he enters a certain wormhole.

Practically I imagine something like this:

Code: Select all

// get the wormhole closest to the player with system.filteredEntities first

this.shipWillEnterWitchspace = function (cause)
{
     if(cause == "wormhole")
          {
          if(wormholeClosestToPlayer.position == player.ship.position) // player is actually entering
                                                                       // the wormhole specified before
                                                                       // (actually the position wouldn't be exactly
                                                                       // the same, but you get the idea)
               exitInInterstellarSpace // whatever method this will be
     }
}

Additionally, it would be nice not only to be able to script a misjump, but--in this specific case of entering a wormhole--to script an intergalactic jump as well.

In that case we could script a scenario where the player hunts a NPC and follows him to the next galaxy. Presently not possible, because NPCs can't do intergalactic jumps (or can they?).

[Thargoid]

Some way to add time onto the clock? For example clock.addTime(<param>) or something like that, to put that many seconds onto the clock.

[Eric Walch]

I think we need a way to identify planets by name. Now we only have a planet.isMainplanet and I already say solutions by identifying them by radius.

I suggest two additional properties.

a) planet.name (read only) The name itself should be the key by witch the planet is defined. this makes it also backward compatible with existing planet definitions. e.g. the tianve pulsar would become tianve_pulsar or the planets in assassins would become "rebel_moon", "new_planetA", "gas_giantA", "new_planetE". Maybe not always he nicest names but names within a system will be unique.

b) planet.displayname (read/write) By default is should be the same as the unique key but can be defined in planetinfo.plist

[Thargoid]

And it would also help me make PlanetFall work better, by giving things better names than "prime" for the main planet and just the system name for all other planets