Page 12 of 56
..
Posted: Sat Dec 13, 2008 12:50 am
by 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.
Posted: Sat Dec 13, 2008 12:52 am
by DaddyHoggy
Wow - I made a sensible suggestion! Somebody take note of the time and date! It's only taken 1100+ postings!
Posted: Sat Dec 13, 2008 9:33 am
by 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
Re: ..
Posted: Sat Dec 13, 2008 1:33 pm
by Eric Walch
Lestradae wrote: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.
Posted: Sat Dec 13, 2008 8:25 pm
by DaddyHoggy
Darn - still haven't made a sensible suggestion then! Oh well, time to break out the infinite number of monkeys....
Posted: Mon Dec 15, 2008 6:28 am
by Commander McLane
DaddyHoggy wrote: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.
Posted: Mon Dec 15, 2008 9:38 am
by JensAyton
Commander McLane wrote: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
Posted: Mon Dec 15, 2008 10:41 pm
by Thargoid
Could commodities.plist be made to work in comparison with any of an entities roles, rather than just its primary one?
Posted: Tue Dec 16, 2008 6:19 am
by Commander McLane
Thargoid wrote: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.
Posted: Tue Dec 16, 2008 7:17 am
by 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.
Posted: Tue Dec 16, 2008 8:11 am
by Commander McLane
Thargoid wrote: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.
Posted: Wed Dec 17, 2008 8:26 am
by 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?).
Posted: Thu Dec 18, 2008 10:57 pm
by 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.
Posted: Sat Dec 20, 2008 11:35 am
by 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
Posted: Sat Dec 20, 2008 12:17 pm
by 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