damage int energy expressed as a percentage of maxEnergy
I've no idea if it could be used to control the mixing in of a 'damage' texture map though - from that description it also sounds as if the damage level would decrease back to 0 as the ships energy climbed back up to full power making it look like the ship was repairing itself - and it that case i think the 'energy' binding would work better
energy float The current energy level of the entity.
Griff, you did the fab burning alloy shader demo for us, rather than it being a one shot wonder and all reds and oranges, perhaps, if possible, it could flicker reds and oranges and blues and whites, indicating perhaps, severed cables and electricals and plasma conduits, slowing burning in vented atmosphere, reset on docking when a ship's energy was fully restored.
Like Frame, and with no real knowledge of the bindings, I too could just be rambling...
i was thinking it could be tied to equipment demage, which is (?) the only stuff that gets recorded as being damaged and needing repair. after all, we can assume that if your docking puter or scoops have been knackered, your ship must've taken a bit of a pounding, so doing a damage graphic until these bits were repaired would be appropriate.
or, could we add a "hull integrity" element to your equipment screen? bit like Hardwar, perhaps, and you get charged at the stations say 25Cr per percent damage.
that's a great idea - some sort of subentity swap between a healthy and a damaged version? - i do remember Eric and Thargoid doing something like this in their oxps - is this how the bulk hauler in Aquatics works when it releases its cargo pods and they fly themselves into the station?
The aquatics hauler works by initially having the sleds as sub-entities of the hauler, and when it's time to release them those sub-ents are removed and new separate versions are spawned in their place (in exactly the same position and orientation).
I'm not sure you can add sub-ents back onto a ship once they're destroyed (I've never tried it), but certainly damaged panels could be simulated by having sub-ent panels with the damaged ones underneath the undamaged ones, and then just remove the undamaged ones to "reveal" the damaged ones.
It would be going back the other way that could possibly cause problems.
I'm not sure you can add sub-ents back onto a ship once they're destroyed (I've never tried it), but certainly damaged panels could be simulated by having sub-ent panels with the damaged ones underneath the undamaged ones, and then just remove the undamaged ones to "reveal" the damaged ones.
Sounds similar to the way the Dark Wheel Cobra works. So it may be a good idea to look into that OXP for inspiration.
I still think the DW Cobra is an awesome ship to look at, and it was created way before we had shaders. Now if I imagine it combined with shader effects...
I'm farily certain that subentities are repaired on docking, or at least on reloading, I'm not seeing anything in the save-file about damaged subentities being saved... But I could be wrong.
I still think the DW Cobra is an awesome ship to look at, and it was created way before we had shaders. Now if I imagine it combined with shader effects...
Does your Anaconda have a cargo door you can blow off, like Ramon's one?
No, mine's not so advanced, if i remember correctly those 'yellow doors' on the lower hull of Ramon's ship are escape pods, not sure if he's added in the scripting to get them launching yet though, but when he does it's going to be really cool!
I'm farily certain that subentities are repaired on docking, or at least on reloading, I'm not seeing anything in the save-file about damaged subentities being saved... But I could be wrong.
That one misses a "requires.plist" Also the Griff moray is missing it. Trying to launch my old Oolite 1.65 it crashed. After searching for the cause I found at least two of them:
Feb 9 17:24:23 cc999323-b Oolite[808]: 'ERROR - model griff_moray.dat has too many vertices (model has 605, maximum is 320)'
Feb 9 17:20:19 cc999323-b Oolite[793]: ERROR - model ramon_anaconda_engine_pipes_part1.dat has too many vertices (model has 360, maximum is 320)
Older Oolite versions are not always able to cope with oxp's created for newer versions. Therefor the requires.plist is needed. It prevents older Oolite versions from loading such oxp's ad than crash on it.
Does your Anaconda have a cargo door you can blow off, like Ramon's one?
No, mine's not so advanced, if i remember correctly those 'yellow doors' on the lower hull of Ramon's ship are escape pods, not sure if he's added in the scripting to get them launching yet though, but when he does it's going to be really cool!
No, I never did get round to scripting that (although I did at least texture the escape pods). I just wanted to release it in the end, it took so long to do - with rl getting in the way.
I am working on some more ships but I tend to post WIPs and then nothing for months on end so I'm keeping the ships to myself for the moment. You're doing a great job on the remakes Griff that I've started some new designs now - but keeping in the spirit of Elite.
@Eric. Do I need to redo the Anaconda (at some point) with less Vertices, or add a 'requires.plist'?
.
