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.
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.
Flying a Cobra Mk I Cobbie 3 with nothing but Explorers Club.OXP and a beam laser 4 proper lasers for company Dropbox referral link 2GB of free space online + 500 Mb for the referral: good for securing work-in-progress.
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.
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.
Most games have some sort of paddling-pool-and-water-wings beginning to ease you in: Oolite takes the rather more Darwinian approach of heaving you straight into the ocean, often with a brick or two in your pockets for luck. ~ Disembodied
Exorcism! It's the only way. These flashing lights that are not really there are just not natural.
Flying a Cobra Mk I Cobbie 3 with nothing but Explorers Club.OXP and a beam laser 4 proper lasers for company Dropbox referral link 2GB of free space online + 500 Mb for the referral: good for securing work-in-progress.
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
Last edited by Commander McLane on Tue Jul 03, 2012 8:39 am, edited 1 time in total.
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.
From what I saw in my own version, the lights moved but neither the station nor the buoy did. I did have a version for test which spawned the lights relative to the buoy instead of the station, but it didn't make a difference.
I'm just testing an updated version which uses a single ghost entity with a lot of flashers to make the chain (ie the chain is one entity not a string of them). As to whether that will help remains to be seen, and indeed it will still have one zero-poly entity there, so may still be problematic for 1.76.1.
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.
That would be OK for basic game only, but keeping it aligned with OXPs like YAH and probably Buoy Repair would be a nightmare. If that's needed then it'd be easier just to forget the concept I think (with apologies to the brain-in-a-box).
Anyway, I've played around with the script and set-up of my version of this OXP, which is now uploaded as v1.02. It uses a single entity only (which also self-checks for NaN positioning on spawning and corrects if things go wrong), and the lights will go red if ships go near them, either during launching or docking.
Downloads are via the links below as normal, and the wiki and readme are updated with warnings that this OXP can cause interesting side effects sometimes.
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.
![[EliteWiki]](/images/elitewikismall.png){kind=small}
New Cargoes
