Request: Real Working Candle

[greebo]

I'm not sure why the brushdef is in there, might be left over from initially making the collision model?

I believe that's a so-called dummy brush that the editors create for entities (they get removed in-game).

[Ishtvan]

Yeah, that sounds possible... I think it may only happen for entities with a brush-based collision model.

 

@Dave: You can't put all three on a single entity, it has to be at least two entities for the two frobable parts, and we decided that flame entities should be separate from light holder entities so that they can do the particle effects and have a contained bounding box around the flames plus one around the holder for better stim/response behavior. So I think it definitely has to be three entities.

 

What I was saying was it might be possible to have one entity call an init script at runtime that spawns the others and sets up the binding, etc, but you wouldn't be able to see them in the editor since they're spawned at runtime (I think, some runtime stuff does happen in the editor but I'm not sure what).

 

I guess I remembered wrong that we had prefabs settled... so we don't have a prefab torch or architecture or anything? Anyway, making a prefab out of those 3 items would not be hard, especially if DarkRadiant could put the correctly incremented names in the "bind" key like we set it up to do with the "target" key.

[SneaksieDave]

What I was saying was it might be possible to have one entity call an init script at runtime that spawns the others and sets up the binding, etc, but you wouldn't be able to see them in the editor since they're spawned at runtime (I think, some runtime stuff does happen in the editor but I'm not sure what).

Ah yes, that's ringing a bell now. Hm. So that would be a small problem, yes. But then, do we know it won't also work in DarkRadiant?

 

Also, unless I'm wrong, I'm wondering if there is a way to still use a prefab, but be able to call/create it from the entity list (so the user doesn't have to go to a completely different place, under a completely different method, to find a torch - might as well reserve a spot at the top of the FAQ if that's the case).

 

There is a prefab directory, but only junk in there so far (minus the sky) as proof of concept. I think there's also currently a problem with DR loading prefabs at all. Yes, smart incrementing necessary!

[Ishtvan]

Also, unless I'm wrong, I'm wondering if there is a way to still use a prefab, but be able to call/create it from the entity list (so the user doesn't have to go to a completely different place, under a completely different method, to find a torch - might as well reserve a spot at the top of the FAQ if that's the case).

 

There is a prefab directory, but only junk in there so far (minus the sky) as proof of concept. I think there's also currently a problem with DR loading prefabs at all. Yes, smart incrementing necessary!

Well, they're going to have to load some prefabs at some point, since I'm guessing a candle made of two frobable objects bound together isn't the last thing we'll do that requires more than one entity. Doors, handles and locks are another thing I can think of that would be nice to prefab, unless we are okay with the mapper not seeing handles in the editor?

 

In DR we can make the process as easy as we want, and could place it from the regular entity list, I assume.

[OrbWeaver]

In DR we can make the process as easy as we want, and could place it from the regular entity list, I assume.

 

We could go further than that, if necessary. My understanding is that decls that are not recognised by Doom 3 are simply ignored, so we could invent a new one -- "combinedEntity" or something -- which could be parsed by DarkRadiant and used to create meta-entity structures which consist of a number of entities with offsets and various linked keyvalues.

 

E.g.

 

combinedEntity candle1 {
entity 1 {
  classname frobable_candle_top
  offset "0 0 16"
  link "bind" "3" // add a "bind" key targeting the 3rd entity
  }
  entity 2 {
  classname "frobable_candle_base"
  offset "0 0 0"
  link "bind" "3"
  }
  entity 3 {
  classname "frobable_candle_main"
  }
}

[SneaksieDave]

Good point with the doorknobs example. Well, setting up a direct path to TDM's special prefabs in DR is a great solution then.

[Springheel]

Ok, is this still the way dual-use candles are set up?

 

 

With the cm of the candle being that large (which was done so the frob trace could hit it), that model becomes unusable for regular use...if the candle was tipped over it would sit several inches off the ground.

 

Given the updates greebo made to the physics code, and my tests binding two cms together, is there any reason why we couldn't do away with the extra cm extending up from the candle-holder? That would also make it much easier to add candles of differing sizes.

[Ishtvan]

Yeah, that was done before Greébo's changes to the bound entity physics, so now that we can bind two things together and still have proper collisions, you shouldn't need the handle CM extending all the way up to the candle CM anymore. We probably want to test it thoroughly though to make sure there are no surprises.