Jump to content
The Dark Mod Forums
Sign in to follow this  
OrbWeaver

Scenegraph

Recommended Posts

I switched to the scenegraph branch and successfully compiled it. Haven't done any testing yet.


"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Share this post


Link to post
Share on other sites
I found a pretty huge bug so far, when I save the map, all my "convert to func_static" entities are deleted! Good thing I backed up my map before!!! ... Just tried some more, selected a few brushes, made into func_static, selected some other brush, deselected (just to be all cleared), then saved, boom the new func_static disappeared! It's just gone, they're all gone man, gone gone gone

Hm, I just tried this out in my local build and I couldn't reproduce that. Can you give me detailed instructions of how to produce that bug?

Share this post


Link to post
Share on other sites
Right away I like the new lights. But I miss seeing the old lights because you could see the light color right on it, now it's just a green outline. But I really LOVE seeing the whole light size in the 3D window, very nice.

Could you post a pic of what you mean here? I'm not seeing a difference. I'm only going back as far as 0.95 though; I don't remember if this changed prior to that.

 

As to the func_static issue: I got it as well, but don't have 100% repro so far.

 

I didn't even have to save. I simply started up, loaded an old temp map I have, and created a brush. Upon turning it to func static, the brush itself vanished, and only the XYZ axis indicator thingy remained (with the lettering, because I have names turned on). After save and reload, it was the same -- no brush info, just the origin and name.

 

Edit: although, in trying to repro this, I did just manage to lose the ability to drag/draw brushes at all. :huh: Trying to repro that too.

Edit: and then it crashed

 

Edit: okay the second thing is 100% reproducable at least. I simply launch DR, create a large brush, press the room (or hollow) button, and then I can no longer select brushes. Crashes on shutdown. The guess is that perhaps the auto-deselection of the brush (after it's carved) is messing up?

Share this post


Link to post
Share on other sites

Another: create a brush, and go into translate mode (W). Deselect brush. The translate indicator jumps to 0,0,0, worldspawn, and you can drag it around. Releasing jumps back to worldspawn. This appears to be linked to the above issue (can't make new brushes) -- it's not happening without it. Seems like maybe worldspawn is permanently selected.

Share this post


Link to post
Share on other sites

Nice, two new major issues. I'll look into that.

Share this post


Link to post
Share on other sites

Ok, I've got the first issue fixed and the second one I couldn't reproduce (I guess it got fixed along with it).

 

I've created another experimental build, which contains the recent fixes plus a few other code changes, this should be a bit better now.

 

http://208.49.149.118/TheDarkMod/DarkRadia...t-0.9.6exp3.exe

 

Please download this one again (you can remove the old one, if you want) and check it out, especially the func_static issue, where things are disappearing.

 

edit: Updated link, there's a new build #3 up.

Share this post


Link to post
Share on other sites

@Komag: nevermind my request above; I just went back and tried my old copy of .95 on my game system, and I see what you mean. On the .96pre, I also have only outlines as lights (cam view), where they used to be solid shapes with light color indicated. We did also gain a wireframe outline, which is nice (so basically, exactly what you said). ;)

 

Hoping to try the fixes above by tonight (have to repro on my work system).

Share this post


Link to post
Share on other sites

exp3 I still have all my func_static's getting deleted when saving the map.

 

I tried with just a tiny little test map that I have, added a couple brushes, converted to func static, saved, they disappeared.

 

Tried again with a NEW map, same issue.


shadowdark50.gif keep50.gif

Share this post


Link to post
Share on other sites

Ok, I could narrow that one down to the func_static pre-save handling. The weird thing is that it only happens in release builds, that's why I couldn't reproduce it at first. Hopefully I will find that soon, this is rather strange.

Share this post


Link to post
Share on other sites

Phew, this is fixed. The problem was (I think) due to some optimisation of references in the release build. The Doom3BrushTranslator took a const Vector3& reference to translate the child brushes, but this reference got screwed in the process. I made the translator copy the Vector3 into a local member variable, and now it works like a charm.

 

From looking at this, the reference should actually work. I thought this through again, and the reference should stay valid all the time, the referenced object is ok throughout the process. Maybe this is a compiler bug, but it's probably not.

 

Anyway, I will compile a new experimental build this evening for you guys to test.

Share this post


Link to post
Share on other sites

Not to sidetrack, but just so you're aware:

I officially have no idea what the hell is going on w/r/t issue 594: http://bugs.angua.at/view.php?id=594

 

I'm not getting the problem now. But, I'm also not getting it with my work system's official 0.96 snapshot. Even though it was originally reported with 0.96. The only guess I have at the moment is a difference in behavior between my work and game system w/r/t that (?!), but I don't see how. Unless some important TDM file is not up to date for one or the other, which 1.) is a pretty obscure cause, 2.) I don't believe to be the case, and 3.) wouldn't fix the problem, because hopefully DR would still handle it.

 

So I've got more research to do on that one I guess. :(

 

/end sidetrack

 

Back on topic: is there a known repro for the disappearing func_statics? Because I never had it reliably enough to assert that it might now be fixed.

Share this post


Link to post
Share on other sites
Not to sidetrack, but just so you're aware:

I officially have no idea what the hell is going on w/r/t issue 594: http://bugs.angua.at/view.php?id=594

This was due to a change in the def files, which had the editor_mins/maxs spawnargs set on the moveable entityDef. I think it happened during the entityDef reorganisation.

 

This borked DarkRadiant's handling of moveables with child brushes. It was mentioned somewhere in the Next Release thread I think, where people were reporting blue boxes instead of moveables.

 

The spawnargs have been removed and these types of moveables are working again, but the core issue that DarkRadiant has problems in these cases is still there, though.

 

Back on topic: is there a known repro for the disappearing func_statics? Because I never had it reliably enough to assert that it might now be fixed.

I got it reproducably when starting a new map, creating a brush, convert to func_static and save. Komag also reported a few more cases above.

Share this post


Link to post
Share on other sites
Phew, this is fixed. The problem was (I think) due to some optimisation of references in the release build. The Doom3BrushTranslator took a const Vector3& reference to translate the child brushes, but this reference got screwed in the process. I made the translator copy the Vector3 into a local member variable, and now it works like a charm.

 

From looking at this, the reference should actually work. I thought this through again, and the reference should stay valid all the time, the referenced object is ok throughout the process. Maybe this is a compiler bug, but it's probably not.

 

Heh, is this one of the places where GCC warns you that you shouldn't take the reference? :P


"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Share this post


Link to post
Share on other sites

func_static seems totally fixed, works find in a new map, my test map, and my city map.

 

(Too bad we don't have two or three more folks testing this stuff :( )


shadowdark50.gif keep50.gif

Share this post


Link to post
Share on other sites
This was due to a change in the def files, which had the editor_mins/maxs spawnargs set on the moveable entityDef. I think it happened during the entityDef reorganisation.

 

This borked DarkRadiant's handling of moveables with child brushes. It was mentioned somewhere in the Next Release thread I think, where people were reporting blue boxes instead of moveables.

Oh whew, that is a relief. I was dreading spending the next few hours trying to pin the conditions on that one down. Thank you! :D

 

The spawnargs have been removed and these types of moveables are working again, but the core issue that DarkRadiant has problems in these cases is still there, though.

Okay I won't force-close the entry then. We'll just need a repro condition for the fix and it should be straightforward to verify.

Share this post


Link to post
Share on other sites
Heh, is this one of the places where GCC warns you that you shouldn't take the reference? :P

No. I'm not that ignorant on compiler warnings.

Share this post


Link to post
Share on other sites
No. I'm not that ignorant on compiler warnings.

 

Your humor-o-meter needs calibrating.


"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Share this post


Link to post
Share on other sites

I'm getting another problem with the func_statics. If I start with some brushes, make them into a func_static, then save (no disappearing problem) and test in game, it's fine. But if I then revert to worldspawn, there is a black square (only in game mode) that won't go away!


shadowdark50.gif keep50.gif

Share this post


Link to post
Share on other sites

I tested it with the snapshop 0.9.6pre version, no problems.

 

With the 0.9.6exp4, just:

- Make a blank room, add start point, one light

- add a few small brushes, convert to func_static, save, dmap and test in game (everything is fine)

- select the func_static and "revert to worldspawn", save, dmap and test in game

 

and this is where you see the black square. If you move the brushes after reverting or delete them, the black square is where they used to be. So it seems that something gets created upon the "revert" command, some phantom object that you can't see or delete in DR. I couldn't find it in the Entity List either.


shadowdark50.gif keep50.gif

Share this post


Link to post
Share on other sites

Ah, there was a logical error in the revertToWorldspawn() method, a ! was missing and the empty func_static was not deleted. The issue is fixed now, expect a new experimental build soon.

Share this post


Link to post
Share on other sites

I just realized something: with the way lights are behaving right now [raised here, thus this mention], that is, they have no color or highlight, just a wireframe outline in cam mode, does this mean that we can get rid of the selected brush highlight completely now? Before, the annoying red highlight of selected brushes was mitigated by allowing the user to choose a neutral color (I use 50% grey), which is better, but still annoying and blocks a clear view of selection (obfuscating texture alignment, choosing, etc). If the selected brush could (optionally?) just be outlined like the light is now, no overlay color at all, that would be superb.

 

*finger poised over bugtracker, anticipating.......*

Share this post


Link to post
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.

Sign in to follow this  

×
×
  • Create New...