Will the new dyn. lights struct ever be exposed to ZScript?

[phantombeta]

I'd really like to know this, as some things currently can't be done in ZScript anymore, such as lights that don't light their owners. It'd also be nice for doing ZScript-controlled dynlights with less of a performance impact.
I imagine it would be possible to make an interface that doesn't expose the internals of the dynamic light struct, allowing them to be changed later if needed.

[Rachael]

I wouldn't mind doing the work to make this happen, but whether it ever happens and the specifics of it are up to Graf.

As far as I know, dynamic lights are fully playsim safe despite being a renderer function. But I expect actually manipulating these variables every tic will likely produce a ton of lag since it would require relinking the lights when they move or change. I don't know if disabling r_lights or gl_lights would affect this though.

[phantombeta]

I wouldn't mind doing the work to make this happen, but whether it ever happens and the specifics of it are up to Graf.

I would also be willing to do that, but I wouldn't do it unless Graf said I could - otherwise, there'd be a very real chance of wasting my time because he didn't want it or wanted it done in a specific way.

But I expect actually manipulating these variables every tic will likely produce a ton of lag since it would require relinking the lights when they move or change.

Relinking would only be necessary for changing position and radius. Colour, angle and pitch don't affect the linking. It also wouldn't really produce any more lag than moving lights already do.

[Rachael]

I would also be willing to do that, but I wouldn't do it unless Graf said I could - otherwise, there'd be a very real chance of wasting my time because he didn't want it or wanted it done in a specific way.

Agreed - my concerns exactly. Which is why, like you, I am not interested in investing any work into this unless he says something.

Relinking would only be necessary for changing position and radius. Colour, angle and pitch don't affect the linking. It also wouldn't really produce any more lag than moving lights already do.

Colour you're right about - however, I expect the situation with pitch and angle changes to be temporary. There may yet be changes in the future (if they haven't happened already - I don't think they have yet, though) so that spotlights only link their relevant surfaces. This is what I am a bit iffy about - just because dpJudas might say he has no plans to change this, doesn't mean it will never change, be it by him years or so down the line, or by someone else. It's one of those "very low priority needs" - and so when the change occurs, this assumption will break the system, you will have to prepare for that in advance.

[phantombeta]

Colour you're right about - however, I expect the situation with pitch and angle changes to be temporary. There may yet be changes in the future (if they haven't happened already - I don't think they have yet, though) so that spotlights only link their relevant surfaces. This is what I am a bit iffy about - just because dpJudas might say he has no plans to change this, doesn't mean it will never change, be it by him years or so down the line, or by someone else. It's one of those "very low priority needs" - and so when the change occurs, this assumption will break the system, you will have to prepare for that in advance.

I'd say doing such a thing would be a VERY bad idea. Changing angle and pitch is likely to be used more often than movement, and that'd make changing angle and pitch an expensive operation, which I'd argue would be worse than slower relinking on movement. (which probably isn't likely to be done as often as changing pitch or angle)
I'd also argue they should only relink after everything is done ticking/when actually needed, anyway, to allow for modifying them more easily without relinking the same light a hundred times in a single tic.

[Graf Zahl]

This struct won't get exposed to scripting, it's render side data that's allocated through means that do not work with scripting for performance reasons. What should be done is to add functionality to let the user attach and detach lights through some utility functions.

[phantombeta]

Why not expose only setters (e.g., "SetPos", "SetFlag") instead of making such a thing, if what you don't want is people reading the dynlight data?
If we have to spawn light actors anyway, it'd go against the entire point of separating dynamic lights from the actors. And if we are forced to use only GLDEFS-defined lights, that'd be a pretty bad and useless feature.

[Graf Zahl]

What needs to be done is to give class Actor a method AttachLight that sets up an internal structure and gives it an identifier, so when you call the function again with the same identifier, it will modify the light, otherwise it will add a new one. Of course there also needs a DetachLight method.

The internal structures should neither be readable nor settable directly and scripts shouldn't be able to get a pointer to them.

[Caligari87]

So... it seems this is going to break an extremely important feature of one of my mods. I'm happy to do it in a different way if necessary, but I really need a way to access dynlight-affected lightlevel. I hope we can get something canonical for that.

[Graf Zahl]

Attached lights are no longer actors. This was changed for 4.0 already, the reason mainly being that the old method was extremely inefficient and had a heavy impact on how lights affected the game's performance. Since 4.0 the dynamic light actors are no longer the actual lights but merely anchor objects to attach lights to that do not belong to a 'real' map actor.

That code doesn't even work properly if shadowmaps or glowing textures are being used. And it may also break if the lighting model sees further changes, e.g. if the currently abandoned lightmaps branch gets resurrected.

[kb1]

So... it seems this is going to break an extremely important feature of one of my mods. I'm happy to do it in a different way if necessary, but I really need a way to access dynlight-affected lightlevel. I hope we can get something canonical for that.

Wow, that's some fancy script you've got there! It looks like some of that code might be generic enough that it could make sense to, one day, bake into built-in functions, for additional speed, reliability, and compactness. It's a chicken and egg problem: You need to provide the abilities to do some low-level stuff in the script language, to know what functionality people want. But, once they start using the language to the fullest, you start to identify common constructs that people need everywhere. Then, it may make sense to provide some built-in support for some of them. Which is all good, as long as you don't recreate the .NET CLR