Where would I start if I wanted to move an entity down on the Z plane?

[AluminumHaste]

So I'm not looking forward to moving 1800 trees by hand, sooooo where can I start in the code? Any pointers?

I was thinking of a function that dropped just a single entity that's selected down on the Z plane until it encounters anything. Patches, brushes, other entities.

 

Any help would be appreciated.

[greebo]

Define what you mean by "encounter anything". That's the tricky part in the first place, as DarkRadiant doesn't keep a collision world to detect intersections between objects. You would have to cycle over all planes of all objects in the scenegraph to test the vertices of the moved object against collisions. A simple bounding box check wouldn't give you satisfying results, as you would have to still manually tweak the trees after such an operation.

 

Another problem is that there are no methods available for you to retrieve the vertices of a model entity, which means you can't iterate over them, unless this interface is exposed somewhere. Only the bounds are available.

 

I'm not sure at all whether this is a suitable task to get started coding in DarkRadiant.

 

At any rate, you'd need to define a new command and register this "event" in the EventManager class, so that you can assign a shortcut or menu item to it. There are a lot of commands registered in the last third of mainframe.cpp file, in case you need an example.

[AluminumHaste]

Define what you mean by "encounter anything". That's the tricky part in the first place, as DarkRadiant doesn't keep a collision world to detect intersections between objects. You would have to cycle over all planes of all objects in the scenegraph to test the vertices of the moved object against collisions. A simple bounding box check wouldn't give you satisfying results, as you would have to still manually tweak the trees after such an operation.

 

Another problem is that there are no methods available for you to retrieve the vertices of a model entity, which means you can't iterate over them, unless this interface is exposed somewhere. Only the bounds are available.

 

I'm not sure at all whether this is a suitable task to get started coding in DarkRadiant.

 

At any rate, you'd need to define a new command and register this "event" in the EventManager class, so that you can assign a shortcut or menu item to it. There are a lot of commands registered in the last third of mainframe.cpp file, in case you need an example.

 

Exactly what I was looking for thanks

Well this would only be useful if entities such as models could "detect" another object. Now a bounding box for a table would probably be fine though as you would want to place objects on it's flat surface, which the bounding box would reflect. I was also thinking more like using the origin of the models themselves as the point of reference.

 

Anyways I'll start on that tonight.

[Tels]

Exactly what I was looking for thanks

Well this would only be useful if entities such as models could "detect" another object. Now a bounding box for a table would probably be fine though as you would want to place objects on it's flat surface, which the bounding box would reflect. I was also thinking more like using the origin of the models themselves as the point of reference.

 

Anyways I'll start on that tonight.

 

If your code encounters moveables (and the user tries to move a moveable down), it should actually be using the collison model because that is what the physics engine would use for collisions. Otherwise, the two moveables clip into each other at map start with unpredictable things happening when you touch then (usually one falls through the other).

 

Setting a func_static on a moveable would be the same.

 

(This brings up the old issue that many of our objects have collision meshes sticking out of their visual meshes, meaning you can f.i. never stack two books ontop of each other without them either clipping into each other, or one of them floating above the other. Which looks espeaciallyy bad when light shines through the crack or the player crouches and can look through. But I digres

[Springheel]

(This brings up the old issue that many of our objects have collision meshes sticking out of their visual meshes,

 

There are lost of cases where the cm can't mimic the visible mesh because it's too complex. Nothing can be done about that. If there are just bad cms, however, they can and should be fixed. Just bring them to my attention.

[Tels]

There are lost of cases where the cm can't mimic the visible mesh because it's too complex. Nothing can be done about that. If there are just bad cms, however, they can and should be fixed. Just bring them to my attention.

 

The ones I remember off hand are the books, tomes and crates. You can easily check them out in DR for yourself by adding the model to an empty map, then enable the CM view (e.g. disable its filtering out), then zoom in and see if the CM sticks out of the visual or not (enabling/disabling CM view makes it easier to see).

[Springheel]

The ones I remember off hand are the books, tomes and crates.

 

I checked all the books that were pointed out to me earlier; they are all flush with the visual mesh. I modified one of the crates but the others are fine.

[AluminumHaste]

You would have to cycle over all planes of all objects in the scenegraph to test the vertices of the moved object against collisions.

 

Yeah I was just poking around the Scenegraph code looking for just this, I don't mind if the entire operation takes several seconds to complete, it doesn't need to be instant.