func_emitter angle constrained to one axis...

[AluminumHaste]

I think I've found the source of my issues, in dark_radiant, I cannot change the func_emitters angle on more than one axis. It just will not rotate. I can't put it in manually either as their is a slider bar for the angle:

 

 

But in doom3ed the angle of doom3's emitters can be set for all 3 axis (x y z).

[greebo]

So you're saying the func_emitter angle is supposed to be non-planar? That's new to me, I didn't realise tha angle was used for anything on emitters.

 

Please report that on the tracker.

[AluminumHaste]

So you're saying the func_emitter angle is supposed to be non-planar? That's new to me, I didn't realise tha angle was used for anything on emitters.

 

Please report that on the tracker.

 

I'm sorry it was the rotation property that's missing. Also when I add it to the entity I can't set it's value, if I put in say a number (45.58585) then press the spacebar to put in the next number, the first value I typed is replaced by "-". So still can't rotate the emitter.

[greebo]

Well, of course you can't rotate the arrow - right now, DarkRadiant doesn't support a 3D angle arrow on entities, this must be coded in.

[AluminumHaste]

Well, of course you can't rotate the arrow - right now, DarkRadiant doesn't support a 3D angle arrow on entities, this must be coded in.

 

This seems like a big oversight as right now there's now way to get particles moving at any direction other than up or down, it is impossible. Is this a carry over from GTKRadiant? Doom 3 editor sucks so much ass compared to DarkRadiant that's it's impossible to use, so really you can't have particles pointing in any direction except up or down with DarkRadiant?

That really sucks, should I add this to the tracker?

 

EDIT: I thought all entities inherited the same base functionality, so if I create a func_static entity I can rotate it all over the place on any axis, so isn't a func_emitter just another entity to the editor? Why is it special?

[greebo]

That really sucks, should I add this to the tracker?

Yes, as I posted above, please add it.

 

EDIT: I thought all entities inherited the same base functionality, so if I create a func_static entity I can rotate it all over the place on any axis, so isn't a func_emitter just another entity to the editor? Why is it special?

DarkRadiant has 5 separate classes for entities, all of which are implementing similar but not the same functionality. It's beyond me why there was no base class (until a few weeks ago, when I started refactoring these classes), maybe that's due to the custom typesystem GtkRadiant was using.

[AluminumHaste]

Yes, as I posted above, please add it.

DarkRadiant has 5 separate classes for entities, all of which are implementing similar but not the same functionality. It's beyond me why there was no base class (until a few weeks ago, when I started refactoring these classes), maybe that's due to the custom typesystem GtkRadiant was using.

 

A I see, thanks for clarifying, I'll add this to the tracker

[AluminumHaste]

Okay, issue tracked

 

http://bugs.angua.at/view.php?id=1338

[SneaksieDave]

I might be wrong, someone would have to check, but I'm not positive it will work anyway. I believe particles orient themselves according to the world, not their entity alignment.

[AluminumHaste]

I might be wrong, someone would have to check, but I'm not positive it will work anyway. I believe particles orient themselves according to the world, not their entity alignment.

 

I opened the Id maps and checked the func_emittdes that I knew were spewing fire at a downward angle and sure enough the Rotation key had three values like -1.23412341234 -45.3453454 -90.1342512341234. So how would you set those angles other then in the editor? At least in the Doom3 editor you can see the particles as you place them, but I'd have to guess in DarkRadiant, but that's better than not being able to at all.

[SneaksieDave]

Well that's certainly good news.

[AluminumHaste]

Well that's certainly good news.

 

You might recognize this from Doom 3, here's fire coming out at a downward angle:

 

[SneaksieDave]

Yep, it's a good find; this is legit and important.

[OrbWeaver]

The "rotation" key does not contain angles, it is a 3x3 (or maybe 4x4) transformation matrix. There is no meaningful way to display these values in a property editor, they are set automatically when you physically rotate the entity using the rotation tool.

 

If the emitter entity does not respond correctly to the rotation tool then this is a bug, but it would be worth checking whether the map actually works in Doom 3 or whether it is just DarkRadiant failing to render the entity correctly.

[AluminumHaste]

The "rotation" key does not contain angles, it is a 3x3 (or maybe 4x4) transformation matrix. There is no meaningful way to display these values in a property editor, they are set automatically when you physically rotate the entity using the rotation tool.

 

If the emitter entity does not respond correctly to the rotation tool then this is a bug, but it would be worth checking whether the map actually works in Doom 3 or whether it is just DarkRadiant failing to render the entity correctly.

 

Okay I understand the first part properly, but I'm not sure about the second paragraph. What do you mean "whether the map acutally works in Doom 3"? The map in question is an ID map, from vanilla doom 3. DarkRadiant does not allow us to rotate the entity which is the exact problem.

[greebo]

Yes, DarkRadiant is lacking support for "rotation" spawnargs on these "GenericEntities" (as they are called in the code). The entity should respond to the rotation tool - it is also worth checking whether the "editor_" spawnargs have to say anything with regards to the rotation response (planar or 3D or no rotation at all).

[OrbWeaver]

Yes, DarkRadiant is lacking support for "rotation" spawnargs on these "GenericEntities" (as they are called in the code).

 

Ah ok, that's the bug then.

 

Certainly refactoring these classes sounds like a good suggestion, I never liked all of that copy-and-pasting. There should definitely be a base class for all entities, perhaps also intermediate base classes for entities with a radius (speaker and light), those with a model, and those with a direction (emitter, path node, whatever else).