Jump to content
The Dark Mod Forums

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


Bikerdude

Recommended Posts

Ok so just discovered that use def_attache broke 2 things -

  • It stopped me being able to treat & manipulate the entity like a light in DR
  • Its ignored the light_radius arg, as in it just set 320 320 320.

Is there really no way to move the origin of the light source without using def_attach..? As it stands with all model based light entities, the light entity is always stuck at the origin of the model.

Edited by Bikerdude
Link to comment
Share on other sites

It stopped me being able to treat & manipulate the entity like a light in DR.

 

I thought this is supposed to be a normal thing, and that's why I don't use custom light entities. Light source gets invisible, you can't see its radius and you can't change it via spawnargs.

Link to comment
Share on other sites

You can change it via spawnargs, though it's true it's invisible in DR. I forget the specific syntax at the moment but I've done this in most of my missions.

Link to comment
Share on other sites

Right, there are a few DR feature requests in this area I believe.

 

Making DR understand combined entities and allowing DR to see and manipulate the light_center (instead of the origin of the light).

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

I forget the specific syntax at the moment but I've done this in most of my missions.

Would be curious to see how you did it, got a specific example?

Making DR understand combined entities and allowing DR to see and manipulate the light_center (instead of the origin of the light).

Yes this would be extremely useful in this instance, got number for the trackers as I dont remember seeing this request..?

Link to comment
Share on other sites

There is a very old tracker about combined light entities:

 

http://bugs.thedarkmod.com/view.php?id=994

 

I couldn't find anything about the light_center but I will create one after testing the current DR

if you don't get to it before me.

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

Hmm.

 

If I read the combined light entity article right, the other option is to create several distinct entities

then use "bind" rather than def_attach. That allows you to see all the bound entities in DR. In the article

it lists the disadvantage of moving them together being a problem but now you can group entities in DR so

that disadvantage is mostly gone. In fact, you could just make an emitter entity and add it to a DR group

with the light model if it's stationary.

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

You can change it via spawnargs, though it's true it's invisible in DR. I forget the specific syntax at the moment but I've done this in most of my missions.

 

Usual spawnargs don't seem to work. Also, if the whole "class tree" thing is to make any sense, those light properties should be inherited and editable when you tick the Show inherited properties checkbox, just as it worked in Unreal and T3Ed. Right now it looks like this:

 

obraz.png

 

As you see stuff like light radius isn't even there, you can't change brightness/color, some things are repeated in active current-level properties, etc. Right now it's pretty confusing.

Edited by Judith
Link to comment
Share on other sites

Yup, the "set sth on flame" spawnarg works, although that's more like a workaround, not a solution (i.e. you can't edit the color values with the usual color menu, etc.).

 

It's interesting that this hasn't bothered anyone since... 2008, apparently. I haven't played with other entity classes and their dependencies yet, but if it works like that, then the usability of the whole system is kind of limited.

Link to comment
Share on other sites

Manipulation is done via set as pointed out above. Normally, you would create a custom light definition where you specify the settings required and attach that one. It is obvious that using the spawnargs directly can't work, because if you have several entities attached how should the engine know on which one you want to alter the spawnarg.

 

It is not optimal that DR doesn't recognize the set command in a way that let you use specific menus like the color menu or that def_attached entities aren't previewed at all. But as most spawnargs are text or numbers only you get used to it when working with them long enough. Personally I don't have any issues with that.

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

As you see stuff like light radius isn't even there,
you can't change brightness/color, some things are repeated in active current-level properties, etc.
  • Yes it is, looked at the inherited line "atdm:lamp_wall_gasflame03_unlit"
  • Its simple enough -
    • if the new light entity, in my case a chandelier made my dram uses inherited light properties it works as you would expect In DR, you can edit all the arg's (change the radious the origin, etc etc)
    • if the new light entity uses def_attach method then the mapper has to manually adjust the args under inherited properties in the entity viewer.

What I found with the second option is even when I set the light_radious manually the enetity/engine was ignoring my setting, so I had to go the first option and use a second light entity - and then switch both of them along with a func_emitter from a nearby switch.

Link to comment
Share on other sites

One of the most useful features of the entity classes system is ability to use any of the values inherited with parent items and change their values in current entity, whether down the dependency tree, or just the one placed in your map. If you can't do that, and you have to use other intermediary variables, like "set on..", it makes the whole process more complicated and longer. Right now, it's faster just to place a lamp model, a light, and a particle, set their values, and group them in a "staging room" of your map, so you can clone them and ungroup them to tweak the values. It should be the other way around.

Link to comment
Share on other sites

Right now, it's faster just to place a lamp model, a light, and a particle, set their values, and group them in a "staging room" of your map, so you can clone them and ungroup them to tweak the values.

Maybe at the beginning, but as said you get used to it. And then there is no real difference in speed. Not to mention that using combined entities reduces the risk of forgetting something when making a copy or using filters.

 

What I found with the second option is even when I set the light_radious manually the entity/engine was ignoring my setting

See my earlier post.

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

Last time I've worked with an UnrealEd was when trying to map for Thief 3, 10 years ago or so. So I can't really remember the details.

 

It is obvious that there is always room for improvement. But it is possible to get to a fast and efficient workflow the way it is now, and that is what I wanted to point out.

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

I havent fired up T3ed for quite some time too, but I rememer how it works (it's common for all Unreal 2.x engines and probably further). The workflow implemented in DR is slower and less clear than that. To make things more streamlined, users should be able to bring the inherited (grayed out) properties/spawnargs to the current level. So the stuff like light radius, color, or texture would initially be grayed out, but if user changes the value, it would be "brought to the current level", not sort of doubled, like it is now (and not working anyway).

Link to comment
Share on other sites

@Judith: What do you mean by changing inherited values "is not working anyway"? Of course it does work.

 

@Biker: Using the vertex mode allows you to move the light center around. Alternatively you can use the light_center spawnarg.

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

Obs, see the example I posted above. Try changing a light texture in that wall lamp. The spawnarg gets repeated with new value, it isn't greyed out anymore, but the new light texture doesn't work in game.

 

I also tried to make a few entities of my own, in a way it was done in Unreal actor classes. I.e. I created a light source (inherits light_base), and a lamp model (inherits my light source), and now the light shows up in the editor, along with all its spawnargs, and the radius is visible and editable.

 

Edit: vertex mode allows to move the light center slightly, there seem to be a sort of limit here, not sure about exact values. Still, that's better than immovable light source.

Edited by Judith
Link to comment
Share on other sites

Obs, see the example I posted above. Try changing a light texture in that wall lamp. The spawnarg gets repeated with new value, it isn't greyed out anymore, but the new light texture doesn't work in game.

 

I also tried to make a few entities of my own, in a way it was done in Unreal actor classes. I.e. I created a light source (inherits light_base), and a lamp model (inherits my light source), and now the light shows up in the editor, along with all its spawnargs, and the radius is visible and editable.

 

Edit: vertex mode allows to move the light center slightly, there seem to be a sort of limit here, not sure about exact values. Still, that's better than immovable light source.

If you want to change the properties on the attached light, you have to use set ... on. So set texture on flame in your instance. The example you've posted above is a bit confusing, as the entity itself already seems to be a light, so why is there an additional one attached?!

 

Never noticed any limits in regards to moving the light center, though.

 

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

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

@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.

 

post-496-0-87502100-1524646212_thumb.jpg post-496-0-61548600-1524648107_thumb.jpg

 

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 by Bikerdude
Link to comment
Share on other sites

 

If you want to change the properties on the attached light, you have to use set ... on. So set texture on flame in your instance. The example you've posted above is a bit confusing, as the entity itself already seems to be a light, so why is there an additional one attached?!

 

Obs, that's a stock TDM light, you can see it under Create entity>Lights>Model lights, Static>Gas. All I did was selecting Show inherited properties check-box in Entity tab, selecting "texture" and changing it from "lights/biground1" to something else. New value for that spawnarg appeared right under it, but it doesn't work in-game. So my guess was either the class system is borked, or something is inherited in a weird or wrong way. As I said before, using stuff like def_attach with invisible light radius and some intermeriary spawnargs is more like temporary workaround, not a real solution.

 

Let me show you how it should probably work, This is UE 2.x actor (entity) class window:

obraz.png

 

The structure is clear and simple, you go to world objects, choose a torch and place it in the map. Then you check the box to show inherited properties, and they appear on a current level (so in the entity placed in map). Then just change the values as you need, so they change from "grayed-out" to "active", and that's it. No doubled values, no intermediary variables.

 

obraz.png

 

There's nothing super-speedy about that workflow, it's just... normal. That's why I highly recommend studying other engines, at least from time to time, to blatantly steal their ideas ;) Not from a coding perspective I guess, but in terms of stuff like structure, UX, and interface design. This is all tried-out and already proven stuff. It saves you time, so you don't have to reinvent the wheel.

 

 

That said, I tried to do something similar to above in DR, and came up with what I expected, the result was similar to Biker's. The light was at the model pivot point, although its properties are editable and the radius is visible, which is good. Using vertex mode or changing the light_center results in an unpredictable effect though, compare the position of the light center in the editor and how it looks in game:

obraz.png

obraz.png

Edited by Judith
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recent Status Updates

    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 4 replies
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
    • OrbWeaver

      I like the new frob highlight but it would nice if it was less "flickery" while moving over objects (especially barred metal doors).
      · 4 replies
    • nbohr1more

      Please vote in the 15th Anniversary Contest Theme Poll
       
      · 0 replies
×
×
  • Create New...