Itches, Glitches & Anything Else...

[OrbWeaver]

I just kicked the SmartPointer and SmartReference stuff from the codebase - one weird thing less. This was taking a strange approach anyway, because it delegated the reference counting to the allocated object itself.

 

Yes, I always thought that was stupid. Reference counting is a meta-function, not a function of the object itself.

[greebo]

I noticed that the Doom3Entity class was the last client of pooledstring.h, so this will be kicked next.

 

Another question: are there any objections to turning the scenelib.h/traverselib.h and such into an own static library like gtkutil and math? It's used by several modules (radiant, entity, model) and it's pretty annoying having to recompile half the codebase when adding a single debug output line to scenelib.h.

[OrbWeaver]

In theory it could be a static library, but I wonder how much of it actually needs to be included in other modules, versus just having a suitable interface on the GlobalSceneGraph() module. I guess there are some utility functions and classes which are used to operate on the core functionality exposed by the module?

[greebo]

There is the TraversableNodeSet class handling all the children of a node and the scene::Node itself which is the base implementation of scene::INode that all actual nodes (e.g. BrushNode) are deriving from. All the casting stuff (Node_getInstantiable) and other things are all defined in the lib.

 

I guess some of them can (and should) be moved, but I don't know about the commonly used classes.

[OrbWeaver]

If classes like TraversableNodeSet are not used outside of the Scenegraph module (as I suspect), then they can be moved into the scenegraph module's implementation files. Stuff like the casting functions could be inside the iscenegraph.h file.

 

This use of a globally-included header file to provide implementation code for interfaces is an extremely lazy and bloat-inducing way of doing things; I really don't understand why the developers used this technique.

[greebo]

No, the TraversableNodeSet is used by both the RootNode (radiant/scenegraph) and the Doom3GroupNode (plugins/entity) as a class member - I can't move the implementation that easily. Both the plugin as well as the radiant core have to "see" the actual definition of that class. Same goes for the scene::Node class and the scene::Instance, which are the common base classes of all the nodes and instances.

 

The annoying thing is that I can't move the implementation stuff into a .cpp file the way it's currently setup, hence a fresh recompile is due as soon as I change anything.

[greebo]

I don't think it is reliably reproducible, it seems to happen randomly. The copy and paste texture problem isn't because of something in the way, it pastes the texture, but not the attributes.

@jdude: I couldn't reproduce this so far, do you have some example map for me where this happens?

[jdude]

What do you mean with bottom, left and right? Do you mean the world orientation of the brush edges? I guess I could get it to work with 4-sided faces, but it wouldn't make sense for polygons that have more than 4 edges. Left and right are non-unique descriptions for a 3D space, however. Or were you referring to something different?

 

Do you have some screenshot of such a situation, so that I can imagine what you're meaning - maybe I can think of another solution.

 

Sorry about the delayed response. Sometimes when I'm working on a map I find a wall that has a -1 horiz or vertic value. I don't remember when I applied this value to the wall but by doing so I have accidentally made the texture inverted. When I look in the text tool, the texture appears to be the correct size but doesn't line up properly, that is why having color coded sides would be helpful. I seem to remember having to use -1 to align textures before we had the text tool. But upon trying to go back and find a situation where I had to, I haven't been able to find one where the text-tool cannot simply fix it...

 

Also I don't know if this is Darkmod or just Doom3 related, but after compiling a map I sometimes get this weird block on the bottom half of my screen. It consists of blocks and shows the sky. When you move around and look around the blocks disappear / re-arrange / re-appear ect ect.

 

I made this image to show you what it looks like:

 

It can be fixed by restarting the game.

 

Edit: Also @ greebo. No I don't have a map that does this specifically, it seems to do it randomly. Is there any debug or something I could do when this occurs and send you the information?

[greebo]

The screenshot above looks somewhat familiar (I believe we have the same graphics card too (an ATI X1950 Pro)), I think it happened when I started Doom, compiled something and did something else in DarkRadiant, which messed up the graphics when I switched back to the game. My guess is that this is a driver or graphics memory issue. It vanishes as soon as you restart Doom 3, at least on my system.

 

@the texture problem: If this happens again, take a screenshot before you apply the texture another time, so that I can see what the results are after the first and second paste operation. Also, please note the orientation of the source (the one you copied from) and the target brush. Maybe there is a certain orientation of these two where the error occurs. If it's too randomly happening, I can only "hope" that it occurs to me sometimes so that I can nail it down, otherwise we're probably out of luck.

[sparhawk]

I have an ATI 9800XT and I run DR and Doom all the time at the same time, when I map, but I haven't noticed such a problem as in this screenshot. I guess it's probably a driver problem related with some chipsets maybe.

[Capela]

I had a ATI1900XT and never had that problem.

[jdude]

The screenshot above looks somewhat familiar (I believe we have the same graphics card too (an ATI X1950 Pro)), I think it happened when I started Doom, compiled something and did something else in DarkRadiant, which messed up the graphics when I switched back to the game. My guess is that this is a driver or graphics memory issue. It vanishes as soon as you restart Doom 3, at least on my system.

 

@the texture problem: If this happens again, take a screenshot before you apply the texture another time, so that I can see what the results are after the first and second paste operation. Also, please note the orientation of the source (the one you copied from) and the target brush. Maybe there is a certain orientation of these two where the error occurs. If it's too randomly happening, I can only "hope" that it occurs to me sometimes so that I can nail it down, otherwise we're probably out of luck.

 

I outlined the two textures, this is what it does.

[greebo]

Ok, I guess so you copied & pasted from one of the outlined surfaces to the other? I'll have to try once more, I hope I can catch that. This is a six-sided cylindric brush you have there?

[greebo]

I created a six-sided prism and applied a differently scaled texture to two of the faces. I couldn't reproduce it after 20 copy&paste operations (using either the menu commands, Ctrl-MMB or Shift-MMB). I can't say what's going on here.

[jdude]

I just realized it may be some sort of problem arising from me installing 9.0 over the 8.1 build. Perhaps that is the source of the problem.

[Fidcal]

There are some great textures to choose from. There are a lot of stone and brickwork under the floor section. I wonder if they should be under the wall section - especially as there are one or two window apertures. If I were searching for a wall texture I probably wouldn't look under floor - but if I wanted a brick or stone block floor I probably would also look in the wall section. (probably this para should be posted in a different forum?)

 

While looking for stone floors under media I naturally clicked on a great many to see the picture. When finished, all of those were then entered into the texture selector even though I didn't want them. I think they disappear next reload if not used so maybe that is not a problem. But having searched for my texture and selected it in media (to view the picture) I then had to search through the texture selector to put it on the surface. I wonder if it would be better if it went straight on the surface from the media selector. So the media selector does not primarily and only select what goes in the texture selector but actually selects what you want to put on the selected surface. The texture selector then becomes just a shortcut to already-used textures. Does that make sense? Just my two cents.

[Crispy]

@texture organisation: There's a texture reorg in progress at the moment. (This is more of a main mod issue than a DR issue, by the way.) Hopefully the result of that will make more sense to you than the current organisation.

[greebo]

@Fidcal: You can right click the shader in the list and choose "Apply Shader to Selection".

[Baddcog]

I've been using alot of the 'floor' textures for walls too. Some of them are obviously in the wrong spot.

[Fidcal]

OK, got it thanks.

[Fidcal]

What determines the order in the create entity list? I usually struggle to find AI then I just realized it's probably because the folder is capital AI and maybe if it were changed to ai then it would be OK. But inside that I see these which do not seem to have any alphabetical order....

 

atdm....

Builder

Guard

atdm.....

atdm....

Undead

Non-Comabatant

Belcher

Pagan

Spider

[Baddcog]

What determines the order in the create entity list? I usually struggle to find AI then I just realized it's probably because the folder is capital AI and maybe if it were changed to ai then it would be OK. But inside that I see these which do not seem to have any alphabetical order....

 

atdm....

Builder

Guard

atdm.....

atdm....

Undead

Non-Comabatant

Belcher

Pagan

Spider

 

I always hit B when I bring up the entity list, that puts me right below the AI entitys, a short mouse roll up gives me the AI folder.

 

I believe the AI entity files are listed by their order in the def folder:

 

ai_builder... is first

ai_citywatch... is next

monster

noble

pagan

spider

steambot

zombie...def

 

D3 loads everything in alphabetical. So if you have the same entity in builder.def and in guard.def it will only load the one form builder.def, the other gets ignored.

[Fidcal]

OK, thanks Badcogg. So just needs sorting in the def file. Hadn't realized you can just hit the initial letter. And I see a little search input appears too.

[greebo]

There should be a way to sort the tree view elements in DarkRadiant, although I haven't done this before, but I think it's possible. If you feel this should be done >> open a task in the bugtracker.

[Mr Mike]

Fidcal, as stated you can right click and "apply to selection" in the media browser and there is also an option to flush unused textures at the top of the texture browser window.