Manipulation Of Func_statics

[greebo]

I finished what I began yesterday: the "Revert to worldspawn" command (default: Shift-G / OrthoContextMenu) is implemented.

 

I discovered yet another issue with func_statics: child patches don't seem to be affected by the func_static translation, they always stay where they are.

 

I'll look into the above problems in the afternoon, I'll have to make some progress on my thesis...

[greebo]

I could fix the issue regarding the ineffective texture lock of child brushes. There was already sorf of a framework for this, although it's more of a hack really. Not that this is surprising.

 

I'll look now into the Patch problem. This may pose some harder problem, as no "framework" like the one for Brushes exists here.

[greebo]

The patch problem is now fixed as well. Next is the rotation bug.

[OrbWeaver]

Wow, you're really attacking these bugs. There won't be any left at this rate.

[greebo]

Let's hope so. So far DarkRadiant bugfixing seems like fighting a nine-headed hydra.

[SneaksieDave]

There won't be any left at this rate.

*evil giggle*

[New Horizon]

Let's hope so. So far DarkRadiant bugfixing seems like fighting a nine-headed hydra.

 

That sounds nasty. How many bugs do you have to kill before one of the heads falls off?

[greebo]

Supposedly inifinitely many. As soon as you fix a bug, two new ones arise.

[greebo]

Ok, I've found a way to fix the manipulations of child primitives (based on Orbweavers suggestion to propagate the call to the children), although at the cost of having the func_static origin fixed during manipulation (i.e. it does not move along with the group). Converting to func_statics and back to worldspawn is working as well without any jumps of the primitives.

 

I'll try to dig into it and see if I can do anything about the origin.

[greebo]

Gah! I almost feel like giving up on this! I was so close and now several things seem to be broken that've already been working. This cursed Instance/Node stuff and all those hundreds of TransformChangedCallers are driving me nuts. I wonder what the DoomEdit guys did to get the func_statics working... (apart from the obvious daily rampage)

[OrbWeaver]

Maybe the particular problem you are trying to solve also exists in DoomEdit. Is this still the problem with the texture coordinates changing when you drag a func_static?

[greebo]

No, luckily I could solve this one. It's the implicit dragging of the origin that doesn't work (and it does work in DoomEdit). If you drag around the func_static and the origin gets updated all the child brushes move along as intended. However, this makes it impossible to transform the group using the rotation manipulator (the stuff moves around like mad).

 

I could work around this by propagating the transformations down to the child primitives, which seemed to work, but with the payoff that the origin stays unchanged while transforming (you'd get a double-translation otherwise).

 

I tried to combine both behaviours, but this attempt completely screwed up. I was nearly there, but then the method "convert to func_static" and "revert to worldspawn" broke because the child brushes not always get notified of the origin changes (they jump around afte rreverting them to worldspawn).

 

There must be a way around this, I just haven't a good idea yet. Everything's so entangled with callbacks it's really hard to tell what's actually going on. This is frustrating.

[SneaksieDave]

This is probably no help, but just an observation. In DoomEd when moving an object which displays the origin, it all moves as one, all the time. Only when it's dropped, can the user edit the origin key to move it, and not the rest of the object.

 

In DR, I've noticed that;

1. when you drag one of these objects, the origin lags behind - it doesn't snap to the object until I release the mouse,

2. (known) when you reposition the origin by typing a new value, the object itself moves as a whole, and to move the origin, you must first move the object as a whole, and then move the parts away from it.

 

So it's being handled in a backwards manner w/r/t DoomEd. Maybe that's at the source of the difficulties.

[greebo]

1. when you drag one of these objects, the origin lags behind - it doesn't snap to the object until I release the mouse,

I could fix that one already.

2. (known) when you reposition the origin by typing a new value, the object itself moves as a whole, and to move the origin, you must first move the object as a whole, and then move the parts away from it.

 

So it's being handled in a backwards manner w/r/t DoomEd. Maybe that's at the source of the difficulties.

The main evil is the design. I suspect that the DoomEdit programmers had to change more than I did to get this to work. Maybe they even rewrote that whole transformation part and got rid of all the callback shit.

[greebo]

Finally! The build snapshot on FTP should resolve all those issues now. This was really hard, but in the end I even could simplify things a bit (there's still room for improvements, though). The code cleanup is not yet done, but at least we could get rid of the BrushDoom3 node definition, which was used before to hack the func_static "support" into the Doom3Group.

[OrbWeaver]

I'm very encouraged when I see words like "simplify" and "remove".

[greebo]

Btw, the Doom3Group acts more or less like a real container now. It propagates all transformations to its children and the helper class Doom3GroupOrigin takes automatically care of the origin substraction/addition when new children are added. Hence the map::selectedPrimitivesSubtractOrigin() method doesn't need to be employed anymore.

[greebo]

Orbweaver, could try to compile the latest revision (1164) and see if it's crashing on your end too? I might need a hint where this thing is bailing out.

[OrbWeaver]

It compiles and runs for me. When is the crash supposed to happen?

[greebo]

Open op up darkmod.map and then switch to another map. Sometimes I had to switch more than once to different maps and it should bail out eventually.

[OrbWeaver]

I switched several times between maps but it hasn't crashed so far.

[greebo]

Grmpf. I could reliably reproduce it yesterday, even after full recompiles, and at least three times today. Oh well, I will hunt that bug down.

[greebo]

Ok, I don't what it is, but it seems to be related to these two code passages in scenelib.h:

 

class BrushDoom3
{
public:
 STRING_CONSTANT(Name, "BrushDoom3");

 virtual void setDoom3GroupOrigin(const Vector3& origin) = 0;
};

and

inline BrushDoom3* Node_getBrushDoom3(scene::Node& node) {
return NodeTypeCast<BrushDoom3>::cast(node);
}

Removing those two makes my DarkRadiant build crash upon map change, although nothing is using these two. Perhaps there is something with the NodeCastTable stuff that depends on it, I just don't know.

[OrbWeaver]

I guess you've tried the complete clean and rebuild? I often get crashes and forget to do this as a first step.

[greebo]

Yes, I tried that multiple times. I really hope this doesn't occur again.