[penguin]

Originally posted by ZylonBane
Regarding the issues with turning the lights on and off, how hard would it be to add an untargetable "Lights" subsystem?

WMCoolMon started putting some sexp stuff together that would do this...

It's not a separate subsystem, but a (glow-lights-on "Delta 2") type of thing.  I forget the actual sexp he was using, but I started adding a flags in the ship struct to indicate if lights were on or off.

This was before all the "blinking lights" stuff started to surface, though... any ideas how to implement that?  Maybe:

Code: [Select]


(glow-lights "Delta 1" 0)    // turns off lights
(glow-lights "Delta 1" 1)    // turns on lights (steady)
(glow-lights "Delta 1" 2)    // turns on blinking lightsDynamic lighting should be yet another option -- running lights should cast no light, but a large light next to a docking bay would.

[Inquisitor]

Not sure how the fighter beam thread became running lights, but it's getting impossible to read, so I split it

[LtNarol]

dynamic lighting would allow for flood lights, that would be cool....but dock point lights and docking bay lights dont really need to cast any light, just illuminate themselves

[ZylonBane]

Originally posted by penguin
This was before all the "blinking lights" stuff started to surface, though... any ideas how to implement that?

Blinking lights are so inherently flexible that controlling them could easily become insanely complex. We should accept that it's not practical to create an interface that will let you pull off Las Vegas-style displays.

So here's a random proposal... just thinking into the keyboard here...

Instead of specifying light data in the POF, just give each light a bank number. Then, in the tables for the ship, have something like:

Code: [Select]


$Lights:
+Bank: 1
+Start Time: 0
+Time On: 10
+Time Off: 100
+Bitmap: glowred01
$Lights:
+Bank: 2
+Start Time: 2
+Time On: 10
+Time Off: 100
+Bitmap: glowblue01

This would have several advantages. It would simplify the POF structure, it would make it trivial for designers to tweak the lights on a ship, and it would reduce memory requirements. Also, randomly flashing lights in the same bank would flash together, creating the appearance of all the lights being on the same circuit.

That's the simple version. Now for a slightly more complicated/flexible version:

Code: [Select]


$Lights:
+Bank: 1
+Start Time: 0
+Delay: 50
+Delay: 100
+Bitmap: glowred01
+Bitmap: glowgreen01
+Bitmap: glowblue01

In this arrangement, you can put as many Delays and Bitmaps in each bank of lights as you want (well okay, limit it to 32 or something). The code would cycle through the delays and bitmaps sequentially. Thus the entry above would generate a light like this:

red for 50ms
green for 100ms
blue for 50ms
red for 100ms
etc..

You could have a single bitmap blink out a morse code message, or a dozen colors at a fixed rate. Flexible enough?

[Kazan]

it would not reduce memory requirements - it would have zero effect

it would be more difficult to code - parsing text parameters is more complex, requires more time - reading binary information is faster


the GLOW chunk is based off the prexisting FUEL chunk - we have the majority of the code in place for it to work as is we proceed with it as a POF chunk

it's already been merged into fs2_open

most of the implementation for POF CS to support it is underway and is trivial in comparision to the POF rendering code

[ZylonBane]

Originally posted by Kazan
it would not reduce memory requirements - it would have zero effect

Please explain how storing the light animation settings only once, instead of duplicated for every single light on a ship, wouldn't be more memory-efficient.

it would be more difficult to code - parsing text parameters is more complex, requires more time

The text-parsing routines are already built into the game.

most of the implementation for POF CS to support it is underway

So? Since when does the first idea on how to implement something ever turn out to be the best way?

[Kazan]

Originally posted by ZylonBane
Please explain how storing the light animation settings only once, instead of duplicated for every single light on a ship, wouldn't be more memory-efficient.
The text-parsing routines are already built into the game.
So? Since when does the first idea on how to implement something ever turn out to be the best way?

they're not duplicated for each individual light on the ship

the text parsing routines still take more time to EXECUTE, it's still a more complex operation because it requires more function calls overall [YOU may call one function, but that one function calls more functions]

if you're good at design? the first design often comes out to be the best

[Inquisitor]

Well, the first is almost never the best, in my experience.

But that is an argument for elsewhere.

Zylon, have you tried any of this of which you speak?

[Bobboau]

"Since when does the first idea on how to implement something ever turn out to be the best way?"

sence this time

reading from POF is faster than reading from tbl, much much faster, and the data in the POF holds less hard drive space, other than that memory usage (while in game) would be the same (though it would take more memory to parse it out of the tbl), it is quicker to implement in the POF (by that I mean both the game modifications and you and you're model file, remember Kaz will probly have graphical interface ready in a day or two, you can't check this if it's in the tbl), PCS auto-gen code will probly be implemented soon too


also the lights are organised by banks, this was origonaly done to organise texture useage (and becase I used the thruster chunk as a template), but it also alows you to make several groupes of two or three lights (say one on ether side of a flight deck) that blink in sequence, basicly insted of haveing to animate on a glow by glow basis you have the option of doing this way or grouping them

also you could do you're color cycling thing but you would need to generate a new glow point for each color, but you would be alowed to have a diferent size as well, in this case you're system would be somewhat simpler, but I don't think this would be used enough for it to justify the added complexity of codeing for this

[Inquisitor]

So, Bobboau, if you had this to do all over again, you'd pick the same approach?

[Bobboau]

yup
the only advantage tables would have is I wouldn't have to wait for an editor

[Kazan]

editor will be completed tommorow

[Bobboau]

thanks
and I wasn't realy directing that at you

[Inquisitor]

I just want people to keep an open mind to other's ideas, that's all

Healthy discussion, rather than, well, the alternative

[IceFire]

I think most of us modders will be happy as long as we can do the glowing lights, we can change the bitmaps, and we can set the blink delays.

It sounds like you guys have all of that worked out.

I can't wait to add those changes to TBP ships

[ZylonBane]

Originally posted by Bobboau
also the lights are organised by banks

Ah, I wasn't aware of that. Good show.

So will the random-flicker routines respect the bank organization?

[Kazan]

yes

[Bobboau]

the damage flicker I just put in flickers on a point by point basis, the code for random blinking times (negitive values for random blink  times) would probly be done on a bank basis

[Kazan]

i just have to write the GUI callback now

[Bobboau]

yay