Oolite Bulletins

Commander McLane wrote:

I have most of the stuff necessary for a double row of flashers that rotates with the station. However, I'm hitting a wall currently. Whenever I jump into a system with a Coriolis as main station (which could be from one of several station OXPs), my main entity is taking damage fast and exploding unexpectedly, which of course messes up timers and callbacks. I haven't yet found the cause of this. I also haven't checked yet whether this happens with v.0.92 as well.

It does happen as well, but not because of the station type, but because of spawning from the distance.

As it turns out, I can only spawn my main entity if the player is inside a range of 31620m from the main station. Even if I spawn it while docked, and then leave this range, it explodes. Collision detection, again.

31620m is well within aegis range, thus I can't even use shipEnteredStationAegis for spawning it. Perhaps that's going to be possible if I increase energy and recharge rate.

EDIT: Yes, I can solve the problem with a high energy recharge. Back on track.

Thargoid wrote:

SandJ wrote:

I just thought, the docking lights do not need to be on all the time. They need only come on when a vessel emerges, or a vessel gets within, say, 10km of the station or its beacon. They could just switch off when not needed.

That's what v1.01 of the OXP does, except it triggers on entering the Aegis rather than 10km (to save another timer).

The thought I had was for the lights to appear as one approached the station, almost welcoming the pilot. Thereby turning a 'non-functional requirement' into a 'feature'.

Thargoid wrote:

That's what v1.01 of the OXP (which no-one seems to be using?)

Sorry. I was, but when I flew through a main station without docking, that was too big a problem for me to continue living with. But I'd like it working again.

cim wrote:

What it doesn't explain is why the flashers are slipping, since they do that even after this fix. I can't see anything obviously wrong with the JS code to swap them, either. I'll keep looking.

After very carefully monitoring each flasher in 1.00 to see what happens to it, I have an answer to this. They are being knocked aside by collisions with launching ships or the nav buoy. Sometimes this even deals enough damage to them that they are killed - usually it just knocks them off course very slightly. Eventually the lights change and their replacement does not share their new momentum, so they then stop somewhere out of place.

I saw a few end up with NaN position this way. Probably another oddity of collision behaviour of zero mass objects, perhaps there is a division by zero somewhere in momentum transfer.

Thargoid wrote:

I was planning (at least until all this came up) to perhaps make them detect a close ship when green and turn the string red as a result (ie to change for docking ships as well as launching ones).

If you did this, how would the player know if it was his presence, or an imminent launch, that had caused the string to turn red? Could be kinda confusing.

I'd definitely prefer the simplicity of centerline lights/flashers instead of lights/flashers that rotated with the station.

But...possibly bad new to report?:...Something about too much re-cursed?

Thanks for the report. This particular error is already squashed on my computer.

Switeck wrote:

...Something about too much re-cursed?

Exorcism! It's the only way. These flashing lights that are not really there are just not natural.

Another test case (v.0.93).

Changes:
- shipdata simplified
- known bugs squashed
- for incoming traffic there are now two rows of lights; outgoing traffic is still signalized by single red lights in your face
- due to some precision problems the lights are now only spawned on entering the aegis

This worked fine at the first station (a Coriolis), but failed on approach to a Torus station: After saving there and launching, the lights were working okay. A couple of stations later, the lights had drifted off the slot.

They seem to be coming from the top and bottom of the slot though, rather than from each side (if you know what I mean). Is that intended?

I haven't tested with Tori yet. The error message indicates that the docking lights entity has exploded unexpectedly, maybe due to the Torus' huge mass.

I hoped to have crushed the drifting off the slot by spawning the entity only on entering the aegis. I had observed it when spawning on exiting witchspace. Also, it seemed to me that it was actually the buoy that was drifting, like being kicked off its place by the lights.

Would the drifting/crashing be a problem if the Docklights were actually done by the buoy itself?

Then again, that would make random buoy replacement (such as by Your Ad Here! or Commies) quite problematic.

Switeck wrote:

Would the drifting/crashing be a problem if the Docklights were actually done by the buoy itself?

Then again, that would make random buoy replacement (such as by Your Ad Here! or Commies) quite problematic.

That could be done:
- have a 1-poly minimal entity at the nav buoy position. This does not rotate (it will have to be CLASS_ROCK with custom scanner colours, rather than CLASS_BUOY). No need to mess around with 0-poly entities - I am unconvinced that the fix in trunk is the only bug with them - as this will be hidden from sight within the next item.
- give it a rotating buoy subentity. With a bit of work with shipdata-overrides, the custom buoys from other OXPs can be used here too (override the roles of the original ones, make some new ones with careful use of like_ship and is_external_dependency).
- attach the flasher chain to it.

This is probably the most reliable way to do it, though you'd want to use a preprocessor to write your shipdata.plist or there'd be a lot of copy-paste work to do.

Swapping light colours would require extra care. It would be difficult to do this without affecting the appearance of the nav buoy, especially with YAH or Commies (though in those cases it could be passed off as an intended feature) - you would have to make sure the subentity orientation of the "real" nav buoy subentity was preserved in the swap, which is possible.

Quick (maybe stupid?) question and/or request....
Does this OXP add docking lights to ALL docking ports or just at Main Stations ? If only main stations - would it be a future intention to get them aligned with all docking ports ??
Could there be a split OXP to add the lights to main stations AND/OR 'other' docks...or does the whole thing have to be anchored to the station rather than the 'port' ? (I'm not a programmer so apologies if I appear dense!)

Am currently using Z_Groovy Stations textures 'with ELS' which does a really nice job of white flashing 'runway lighting' to the dock port & rotating with the station - I think it's done as part of the station texture itself. ( I love the textures on the stations & 'extra' small shape stations tetra/octa - I am now fully immersed!).
I'd be keen on using Docklights to get an early bead on eg. entrances to seedy space bars when I approach the lump from distance rather than flying around looking for the way in (I'm not familiar enough with the view of them to pull right round to the right spot....yet....).
I'm not sure I want a clash with the groovy ELS ...although a combination with the coloured lights down the axis of the port might just make the view on approach even more space-age?! Would it, though, be a negative to then be automatically 'highlighting' the entrance to rock hermits ??

I could try it out myself now to immediately get an answer to the very first part of the question for myself....but don't have time to get to an anarchy system 'cos I've got to go to bed for work tomorrow !!! (not school ;-D )
G'night all.

Col W