Oolite Bulletins

CommonSenseOTB wrote:

... to change the core player ship custom views to 4 different ones representing gun camera/zero parallax views each with one of the 4 weapon facings defined.

I'm still amazed/puzzled by these zero parallax views. The laser entity (as a big flickering cross all over your screen) just looks like s**t, so why anybody would want to optically ruin their game by this is beyond me.

Commander McLane wrote:

CommonSenseOTB wrote:

... to change the core player ship custom views to 4 different ones representing gun camera/zero parallax views each with one of the 4 weapon facings defined.

I'm still amazed/puzzled by these zero parallax views. The laser entity (as a big flickering cross all over your screen) just looks like s**t, so why anybody would want to optically ruin their game by this is beyond me.

The interesting part about my previous post is that I need the views for the 4 different weapon facings only and after the automatic test the scripting takes over and and displays whatever I choose to show. As some people want a straight gun camera with a zero parallax then having the four custom views displayed this way makes sense to me. To each his own Commander.

cim, thanks for adding this.

rev5080:
Allow setCustomView to specify weapon direction
Add resetCustomView to return to normal view

many, many thanks, downloading...

It is now possible to assign multiple docks to a station or carrier.


Docks can be set up as launch-only, dock-only, or the default dual-use, and traffic control will reasonably intelligently route traffic to the appropriate docks for best docking and launching rates. Player docking can be explicitly allowed or disallowed at a particular dock. Docks can be given labels, which will be used when instructing the player on where to dock (unless the station only has one dock).

Docks which are set launch-only will repel and damage ships trying to dock with them.

A quick example OXP which adds the pictured ship to high planetary orbit - beacon M - and has it launch and recall traders.

cim wrote:

It is now possible to assign multiple docks to a station or carrier...

Wow, this is excellent stuff! You could now then, in theory, have a massive space hub orbiting the planet or in deepspace that has multiple docks, with exits and entrances, and a large amount of traffic surrounding it I'm assuming? Would be good to have, maybe in corporate high tech level systems. Good stuff!

Thank you cim, this provides for one idea I have for HIMSN.oxp. Your new formations cover a few others.

Now, how about scriptable systems (sun included), thargoid free, mapable to charts by script, in interstellar space. (Would provide for a few other ideas.)

Gimi wrote:

Thank you cim, this provides for one idea I have for HIMSN.oxp. Your new formations cover a few others.

Now, how about scriptable systems (sun included), thargoid free, mapable to charts by script, in interstellar space. (Would provide for a few other ideas.)

Haha yes please! Though I don't think its possible, can't just spawn suns but I'm sure with enough tweaking of the code it would be possible, surely? In fact, and I've never tried this, can you even spawn planets in interstellar space?

Pleb wrote:

In fact, and I've never tried this, can you even spawn planets in interstellar space?

Yes... there are several in OXPs.

Is it possible to assign categories of ships to particular docks (where “category” could mean roles, or the special cases like defence ships)? For example, you might want, say, a battlestar to launch fighters from quick-launch tubes, transports and general traffic from forward-facing bays, and accept docking in rear-facing ports (fnarr). Just idle curiosity, of course. :-)

Ahruman wrote:

Is it possible to assign categories of ships to particular docks (where “category” could mean roles, or the special cases like defence ships)? For example, you might want, say, a battlestar to launch fighters from quick-launch tubes, transports and general traffic from forward-facing bays, and accept docking in rear-facing ports (fnarr). Just idle curiosity, of course.

Not yet, though it would be relatively straightforward to add, I think.

Though, you could simulate that particular case reasonably well without it:
- set the forward-facing bays launch-only
- set the rear-facing ports dock-only
- set the quick-launch tubes launch-only, and make their dimensions small enough that only fighters will fit.
- place the quick-launch tubes earlier in the subentity list than the forward-facing bays.

If you try to launch more fighters at once than you have quick-launch tubes, it'll start using the forward bays as well. But then, if you need that many fighters launched at once, it probably should...

Further considerations given the battlestar example:

• Ideally, you’d want to be able to disable docking bays and retract the flight decks. Could allowsDocking/allowsLaunching reasonably be made read/write? Obviously incoming traffic would need to be redirected, and you’d need to consider the case where an incoming ship is very close to the bay (there is already a case like this for the player when aborting docking). Possibly disabling docking would have to be a method that takes a callback which is called when it’s safe to consider the dock fully closed.
• When a carrier has its ports disabled like this, it should still be able to consider docking requests. Suggestion: an event handler canOpenDockingPort() : boolean is called if a docking request is sent to a station with no open docking ports. If it returns true, then: if there is now an open docking port, dock as normal. Otherwise, put the incoming ship in shipsOnHold and send it ABORT, then wait for a dock to open up and start processing the hold queue as normal. (Wart: what do to if the ship can’t fit in the opened port? The docking AI would need to be updated to handle a refusal in the aborted state. DOCKING_REFUSED = ( "exitAIWithMessage: DOCKING_REFUSED" ); in the standard dockingAI would probably cover most cases. Alternatively, the event handler could return the port that will eventually be opened instead of a boolean.)

Gosh, it’s fun not being on the receiving end of these.

Ahruman wrote:

Gosh, it’s fun not being on the receiving end of these.

You know you miss it really

Ahruman wrote:

Ideally, you’d want to be able to disable docking bays and retract the flight decks. Could allowsDocking/allowsLaunching reasonably be made read/write? Obviously incoming traffic would need to be redirected, and you’d need to consider the case where an incoming ship is very close to the bay (there is already a case like this for the player when aborting docking). Possibly disabling docking would have to be a method that takes a callback which is called when it’s safe to consider the dock fully closed.

Should be safe to make them read/write. true->false on launching if the launch queue has contents is mostly harmless as the ships just won't get launched. true->false on docking can call the abortAllDockings method safely (as long as allowsPlayerDocking remains true, no-one will get hurt if they're too close to stop, and even if it doesn't NPCs should be travelling slow enough to be bounced off in time to get out of the way)

Ahruman wrote:

When a carrier has its ports disabled like this, it should still be able to consider docking requests.

Temporary reject of docking is already possible, so that should be okay. Just needs a way to convert a permanent rejection for reasons of dock closure into a temporary rejection, which that event handler should do.

Ahruman wrote:

Wart: what do to if the ship can’t fit in the opened port?

That should be fine - it'll come out of the ABORT state, request new docking coordinates, be told TOO_BIG_TO_DOCK, and leave.

Smivs wrote:

Ahruman wrote:

Gosh, it’s fun not being on the receiving end of these.

You know you miss it really

*pokes the young’uns with cane*

Ahruman wrote:

Further considerations given the battlestar example:

Okay, as of r5090:
- allowsDocking and allowsLaunching are read/write
- Station now has ship script event willOpenDockingPortFor(dock,ship) which can return true to convert a permanent reject due to lack of ports allowing docking into a temporary one while the "doors opening animation" or whatever is run.
- Docks now have ship script events acceptDockingRequestFor(ship) and acceptLaunchingRequestFor(ship) which can return true or false to handle requests on whatever rules you want. If no function exists, defaults to 'yes'.