Creating a light entity Def: how do we offset the light origin?

[Bikerdude]

So I'm creating a new light entity for Bhm, but rather annoyingly the light entity is located where the original of the models is.

 

Looking at at a lot of the stock light entities and I can see they all suffer from this issue, and this results in the light shader is offset from the model when for example when we have a lantern with four panes of glass and the mapper wants to then use a mapping shader eg "lights/tdm_lanternlight". The center of the shader wont be directly under the part of the model with the glass panes etc.

 

So my question is can the position/offset of the light entity (not the light_center) be defined in the def..?

@Biker: What issues? I didn't get it it seems

Sorry I probably wasn't clear enough with my initial post.

 

The attached snippet shows a typical electric light source, and you can see the light origin is the exact same location as the origin of the model.

 

 

The issue's are -

• if I dont use def_attatch I can't change or move the light_origin, which means for example a shader with a pattern (tdm_lantern) with directly under the origin of the light, not the light_center which idealy where you would want it.
• So then a mapper would then use def_attach so he/she could change the location of the light_origin eg

    "def_attach"                         "light_candleflame_unlit"
    "pos_attach"                         "flame"             // At the attach point called "flame"...
    "attach_pos_name_1"          "flame"             // ... which is defined here.
    "name_attach"                      "flame"            // Give it a name to pass along spawnargs
    "attach_pos_origin_1"      "0 0 10"          // Offset the origin of the light/flame X number of units in the Z direction 
    "light_center"                        "0 0 20"          // Offset the center of thelight/flame X number of units units in the Z direction
    "light_redius"                        "130 130 130"          // size of the light radius
    "texture"                                "lights/biground_candleflicker_shadow"  //shader for the light souce
    "_color"                                 "0.80 0.6 0.23"    //colour of the light souce

And now I have just realised what i was doing wrong, which was causing TDM to ignore my "light_radius" in-game. I was using "light_origin" instead of "attached_pos_origin" and this was because I thought it would be the same nomenclature as 'light_center' and 'light radius'.

 

The issue with def_attach is that the mapper can't then change the origin in DR, its has to be done in the .DEF file for that entity. Or they can force change the setting in DR using the following args -

// Flame

"set light_radius on flame" "100 100 100"
"set color on flame"
"set s_volume on flame" "-20"
"set attach_pos_origin on flame" "0 0 0"
"set _color on flame" "0 0 0"

// light

"set light_radius on light" "100 100 100"
"set color on light"
"set s_volume on light" "-20"
"set attach_pos_origin on light" "0 0 0"
"set _color on light" "0 0 0"

As some have mentioned in this thread, it would be nice to be able to change the above setting in DR using normal methods, not args. I guess the only way yo do this is for DR to create new definitions? like it does when you modify or create new particles?

Edited April 25, 2018 by Bikerdude

[Goldwell]

So I'm creating a new light entity for Bhm, but rather annoyingly the light entity is located where the original of the models is.

 

Looking at at a lot of the stock light entities and I can see they all suffer from this issue, and this results in the light shader is offset from the model when for example when we have a lantern with four panes of glass and the mapper wants to then use a mapping shader eg "lights/tdm_lanternlight". The center of the shader wont be directly under the part of the model with the glass panes etc.

 

So my question is can the position/offset of the light entity (not the light_center) be defined in the def..?

 

If the light entity is spawned in you could set the origin of the attachment. So for example for the entity "atdm:sconce_2candles_rigid" you could just change the spawnarg "attach_pos_origin_1" to whatever new origin you would like which would change the position of the actual light entity on the object when it gets spawned in.

[Bikerdude]

hmm, I've never created that type of entity before but this might fix another issue I have run into. The models has 12 'bulbs' where I want to attach func_emitters, I assume I could use the same trick for the light on the emitters..?

[nbohr1more]

Yep, here's the reference.

 

http://wiki.thedarkmod.com/index.php?title=Def_attach

 

Similar topic:

 

http://forums.thedarkmod.com/topic/15761-one-solution-to-overlapping-lights/

[Bikerdude]

Ok, so let me ask this, how many def/pos attach's can we have? as I need to do 12.

[Obsttorte]

As many as you want, I guess. I never read of any limit. But just to make sure that I understand you. Are you planning to bind 12 different lights to one entity? Because, if so, that would be a very bad idea.

[Bikerdude]

As many as you want, I guess. I never read of any limit. But just to make sure that I understand you. Are you planning to bind 12 different lights to one entity? Because, if so, that would be a very bad idea.

What I have is

• mode - http://forums.thedarkmod.com/topic/10003-so-what-are-you-working-on-right-now/page-309?do=findComment&comment=420369
• 1x light entity.
• 12x func emitters.

I need to offset the origin of the light so its below the model and the light center is in line with the bulbs. Then def attached all the emitters to the bulbs.

Edited April 19, 2018 by Bikerdude

[Bikerdude]

Well it looks like you cant def_attach particles, so am trying to create a custom entity with a single particle

[Guest]

That might eat up performance pretty quick too, both because of number of emitters and particles generated, and/or because of transparency overdraw. A lot depends on how well the emiter is made. One or two static particles would probably be fine, but I imagine placing 2 or 3 such chandeliers in a scene might cause a slowdown.

 

Edit: too slow one particle would probably be a good solution.

Edited April 19, 2018 by Judith

[Bikerdude]

one particle would probably be a good solution.

I guess a single custom particle would cleaner in the def at-least.

 

Well rather annoyingly, the new "func_bulb" entity appears in game just fine when I place it in DR - but is not appearing, def_attaching on the model.

Edited April 19, 2018 by Bikerdude

[Bikerdude]

I created a single custom particle, as this cuts down the on the entity count and for now I am just gonna place the new "atdm:func_chandelier_emitter" entity in the map, I cant figure out why the bloody thing wont def_attach.

 

 

The only other issue is the light entity at spawn time is on, but is not using the lit skin at spawntime. Turning it off then on again fixes that, any one got any pointers..?

 

 

 

entityDef atdm:func_chandelier_emitter
{
"inherit" "func_static"
"editor_color" "0.875 0.878 0.804"
"editor_mins" "-12 -12 -12"
"editor_maxs" "12 12 12"
"editor_rotatable" "1"
"cycleTrigger" "0"

"editor_displayFolder" "Func"
"editor_usage" "custom light bulb emitter for bhm chandelier"
"editor_bool start_off" "0" //if set to 1, particle system will not be visible on spawn."

"editor_setKeyValue model" "tdm_chandelier_12_bulb.prt" // the key value to be set when this entity is created

"solid" "0"
"noclipmodel" "1"
"spawnclass" "idFuncEmitter"
"start_off" "0"
}

entityDef atdm:bhm_chandelier_01
{
"inherit" "atdm:static_light_lit_base"
"model" "models/darkmod/lights/non-extinguishable/bhm_chandelier_01.lwo"
"editor_setKeyValue model" "models/darkmod/lights/non-extinguishable/bhm_chandelier_01.lwo"
"editor_displayFolder" "Lights/Model Lights, Static/Switchable/Electric/Indoor"

// attach the main light

"def_attach" "light"
"pos_attach" "light" // At the attach point called "light"...
"attach_pos_name_1" "light" // ... which is defined here.
"attach_pos_origin_1" "0 0 -160" // Offset the position of the light
"light_center" "0 0 60" // Offset the position of the light center
"texture" "lights/brightround"
"editor_usage" "A ceiling mounted electric lamp with a fancy design. Can be switched on/off."
"light_radius" "320 320 320"
"_color" "0.48 0.38 0.27"

// attach the 12 point func_emitter

// "def_attach1" "atdm:func_chandelier_emitter"
// "pos_attach1" "emitter" // At the attach point called "emitter"...
// "attach_pos_name_2" "emitter" // ... which is defined here.
// "attach_pos_origin_2" "0 0 0" // Offset the func_emitter


// skin and shadows

"noshadows" "0"
"noshadows_lit" "1" // no shadows from the model when lit

//"skin" "lights/bhm_chandelier_unlit"
"skin_lit" "lights/bhm_chandelier_lit"
"skin_unlit" "lights/bhm_chandelier_unlit"

"frob_action_script" "frob_light_holder_toggle_light"

}

 

 

Edited April 19, 2018 by Bikerdude

[Obsttorte]

Why don't you inherit the emitter from func_emitter then from func_static?

Is there any console output that might be of use to hunt down the error?

Is the chandelier moving?

 

[Bikerdude]

Why don't you inherit the emitter from func_emitter then from func_static?

Is there any console output that might be of use to hunt down the error?

Is the chandelier moving

Tried that, dosent work in DR or in TDM, had to create a custom "func_emitter" and a new particle.

Didnt think to check, will a normal console output show anything though..?

nope, static.

 

[Obsttorte]

 

Tried that, dosent work in DR or in TDM, had to create a custom "func_emitter" and a new particle.

No, I've meant the following.

 

entityDef atdm:func_chandelier_emitter
{
    "inherit"                    "func_emitter" // <<<<------------------------------
    "editor_color"                    "0.875 0.878 0.804"
    "editor_mins"                    "-12 -12 -12"
    "editor_maxs"                    "12 12 12"
    "editor_rotatable"                "1"
"cycleTrigger"          "0"
    
    "editor_displayFolder"                "Func"
    "editor_usage"                        "custom light bulb emitter for bhm chandelier"
    "editor_bool start_off"                "0" //if set to 1, particle system will not be visible on spawn."
    
    "editor_setKeyValue model"         "tdm_chandelier_12_bulb.prt" // the key value to be set when this entity is created
    
    "solid"                        "0"
    "noclipmodel"                    "1"
    "spawnclass"                    "idFuncEmitter"
    "start_off"                    "0"
}

[Bikerdude]

 

No, I've meant the following.

    "inherit"                    "func_emitter" // <<<<------------------------------

It doesn't apply because I am using the def of the func_emitter entity as a template, creating a new func_emitter with a predefined particle.

[Obsttorte]

Func_emitter is only a rough wrapper which starts working once additional spawnargs (like the prt to use) has been specified. When defining a new entity you do exactly the same. Inherit gets the entity you want to start off with (in your case func_emitter), and then you just add the spawnargs needed. That's the whole point of inheritance. Your definition should actually look like this

entityDef atdm:func_chandelier_emitter
{
    "inherit"                    "func_emitter" 
    "model"         "tdm_chandelier_12_bulb.prt"  
}

That's it. All other values (like spawnclass, starts_off etc...) are inherited from func_emitter and only need specification if their values should differ from the ones specified in the base entity class.

[Guest]

I'm not super proficient in entity classes yet, but IIUC, it should work like actor class tree in Unreal and other engines: you start from general and go to specific. So from light to a certain light, then to light with certain model, and then to light with certain model and certain particle.

[Bikerdude]

entityDef atdm:func_chandelier_emitter
{
    "inherit"                    "func_emitter" 
    "model"         "tdm_chandelier_12_bulb.prt"  
}

That's it. All other values (like spawnclass, starts_off etc...) are inherited from func_emitter and only need specification if their values should differ from the ones specified in the base entity class.

Fair enough, will give that a try.

Edited April 20, 2018 by Bikerdude

[Obsttorte]

I'm not super proficient in entity classes yet, but IIUC, it should work like actor class tree in Unreal and other engines: you start from general and go to specific. So from light to a certain light, then to light with certain model, and then to light with certain model and certain particle.

That is basically how it works. The whole idea behind this concept is that you try to keep the amount of repetition as low as possible. This basically comes from programming, where several types of constructs (called structs or classes/objects in modern programming languages) may do similar things. In that case you would have to write the same piece of code over and over agian. Instead you define a basic class that implements all the features that are shared by all your constructs, and in the latter you only have to specify what is specific to them.

 

The inheritance in entity definitions work the same. For example you create a basic entity definition for ai, which specifies all the things that are common among all ai. This is not a working ai yet, as lots of imformation are missing (like the specific model to use, the vocal set or whatever), but you have a blueprint for all your ai now. When you then create a specific ai, like a builder guard, you let it inherit from your base class (it now has all the features and properties specified there), and only add what is needed and may change what differs from the default values set in the base class. This way you can save a lot of time. In addition, if you want to make a change to all ai, like changing the scriptobject to use, you only have to make that change in the base class, instead of doing so for all dozens of ai entities you may have defined. All ai will inherit the change from the base class (hence that naming).

 

https://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming)

https://www.youtube.com/watch?v=ajOYOxCanhE

[Bikerdude]

entityDef atdm:func_chandelier_emitter
{
    "inherit"                    "func_emitter" 
    "model"         "tdm_chandelier_12_bulb.prt"  
}

That's it. All other values (like spawnclass, starts_off etc...) are inherited from func_emitter and only need specification if their values should differ from the ones specified in the base entity class.

Obs your a little star, as soon as I changed to the above and def_attched it to the new light entity it worked in-game. I had just been overcomplicating things, nice one fella!

Edited April 20, 2018 by Bikerdude

[Obsttorte]

Thou art welcome, Sir Dude

[Bikerdude]

The only other issue is the light entity at spawn time is on, but is not using the lit skin at spawntime. Turning it off then on again fixes that, any one got any pointers..?

@Obs, got any ideas or pointers on the the above..?

Edited April 20, 2018 by Bikerdude

[Obsttorte]

Use the skin spawnarg. (The one you've commented out )

[Bikerdude]

That makes sense, I can use the lit skin as the normal skin. I was confused by the way its done on all other lights, so maybe in those instances the plain skin was just a lit skin?

[Obsttorte]

skin is the spawnarg used by the engine to determine whether and what skin should be used. skin_lit and skin_unlit are used by the scriptobject (tdm_light_holder). The script changes the skin once the light status changes. IIRC it doesn't check for the initial state after spawn and choose the proper skin. Might be worth tweaking that in the future so that the skin spawnarg becomes unneccessary on entities using said scriptobject.