Jump to content
The Dark Mod Forums

DarkRadiant 2.0.2 pre-release test


Recommended Posts

 

 


Found another bug and this one is major as its causing BSOD's,

 

As written in the bug report, I somehow doubt that DarkRadiant can even do that, even if it wanted to. Are you definitely experiencing this in this pre4-build only, and in no other build?

Link to comment
Share on other sites

As written in the bug report, I somehow doubt that DarkRadiant can even do that, even if it wanted to. Are you definitely experiencing this in this pre4-build only, and in no other build?

I had had it 2 other times, both while using previous test build versions of DR 2.x.x. But as I mentioned in the post, at the time I thought it was down to a dodgy driver and/or faulty ram so never did any indepth fault finding untill now.

Link to comment
Share on other sites

  • And the only driver you've recently updated was for the SB Z card?
  • Were you listening to music at the time
  • yes, but I have had the BSOD before this driver update.
  • no, but I did have TDM ruuning in a window with EAX enabled.

Hmm I wonder if the old EAX issue that caused TDM to CTD is now causing BSOD in the OS..? but then why would WinDbg mention only Darkraditn and not TDM or firefox which were both running..

Link to comment
Share on other sites

now I get a different compiling error:

CXX      compiler/Surface.lo
compiler/Surface.cpp: In member function 'bool map::Surface::rangeCheckIndexes()':
compiler/Surface.cpp:47:36: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
   if (indices[i] < 0 || indices[i] >= vertices.size())
                                    ^
compiler/Surface.cpp: In member function 'void map::Surface::defineEdge(int, int, int)':
compiler/Surface.cpp:228:27: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
    if (silEdges[index].p2 != _numPlanes)
                           ^
compiler/Surface.cpp: In member function 'void map::Surface::identifySilEdges(bool)':
compiler/Surface.cpp:388:22: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
   if (silEdges[i].p2 == _numPlanes)
                      ^
compiler/Surface.cpp: In member function 'void map::Surface::duplicateMirroredVertexes()':
compiler/Surface.cpp:440:59: error: 'memset' was not declared in this scope
  memset(tverts, 0, vertices.size() * sizeof(TangentVertex));
                                                           ^
compiler/Surface.cpp: In member function 'void map::Surface::createDupVerts()':
compiler/Surface.cpp:529:16: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
   if (remap[i] != i)
                ^
compiler/Surface.cpp: In member function 'void map::Surface::deriveTangents(std::vector<Plane3>&)':
compiler/Surface.cpp:964:46: error: 'memset' was not declared in this scope
  memset(used, 0, vertices.size()*sizeof(bool));
                                              ^
compiler/Surface.cpp:1011:48: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
   unsigned long signBit = ( *(unsigned long *)&area ) & ( 1 << 31 ); // FIXME: portability?
                                                ^
compiler/Surface.cpp:1021:22: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
   *(unsigned long *)&f ^= signBit;
                      ^
compiler/Surface.cpp:1035:22: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
   *(unsigned long *)&f ^= signBit;
                      ^
Makefile:609: recipe for target 'compiler/Surface.lo' failed
make[3]: *** [compiler/Surface.lo] Error 1
make[3]: Leaving directory '/usr/local/share/d3bfg/src/DarkRadiant/plugins/mapdoom3'
Makefile:435: recipe for target 'all-recursive' failed
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory '/usr/local/share/d3bfg/src/DarkRadiant/plugins'
Makefile:742: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/usr/local/share/d3bfg/src/DarkRadiant'
Makefile:482: recipe for target 'all' failed
make: *** [all] Error 2

Biel Bestué de Luna - Github

Link to comment
Share on other sites

I can compile it now!

 

do you guys can use the particle editor ? whenever I enter it and try it, then it locks my DR (warning windows doesn't display texts) then the prompt form exiting DR doesn't display any text nor any button only a white window which I can't close, so I have to kill DR in order to exit it.

 

whenever I enter the particle editor I see this "Gtk-CRITICAL" warning in the console:

(darkradiant:11443): Gtk-CRITICAL **: IA__gtk_tree_view_set_fixed_height_mode: assertion 'gtk_tree_view_column_get_sizing (c) == GTK_TREE_VIEW_COLUMN_FIXED' failed

which looks as the same "Gtk-CRITICAL" warning i get whenever I add a new model from the left click menu (on the 2D screen) :

(darkradiant:11443): Gtk-CRITICAL **: IA__gtk_tree_view_set_fixed_height_mode: assertion 'gtk_tree_view_column_get_sizing (c) == GTK_TREE_VIEW_COLUMN_FIXED' failed



which look quite similar as the one I see when pressing the "choose model..." button from the spawnarg "model" in a "func_emiter" entity:

(darkradiant:11443): Gtk-CRITICAL **: IA__gtk_tree_view_set_fixed_height_mode: assertion 'gtk_tree_view_column_get_sizing (c) == GTK_TREE_VIEW_COLUMN_FIXED' failed

(darkradiant:11443): Gtk-CRITICAL **: IA__gtk_tree_row_reference_new_proxy: assertion 'path->depth > 0' failed

Biel Bestué de Luna - Github

Link to comment
Share on other sites

I don't get that in my VM (the 3D rendering is not working there properly anyway for me), though I've seen the warning before. Not sure if that actually prevents anything from being rendered since these are treeview-related warnings, not rendering-related ones.

 

I've uploaded a new buiid (pre5), see first post. Not much new, but I managed to fix the handling/drag-resizing for rotated point lights.

Link to comment
Share on other sites

2 more bugs, one old and one new -

 

http://youtu.be/FWvh8UHfjTw

Sorry, I didn't see the video until now.

 

Regarding the "select everything behind" issue: that's definitely DarkRadiant performing a drag-select operation, due to the mouse cursor moving in between mouse CLICK and RELEASE events, it's a small but obviously large enough movement for DarkRadiant performing the drag-selection. You probably don't notice it much, but at the speed you are moving around and clicking in the camera it's actually quite easy to get an accidental drag-selection.

 

Now, the epsilon I mentioned earlier and you are referring to in the video is exactly the threshold that DR uses to distinguish between a click- and drag-selection operation. This one can be tweaked in the XML files. For a more permanent solution, I can also offer another option to add code to completely disable drag-selections for the 3D camera view - you have to tell me whether this is a desirable solution or not - I can imagine that not many people are using drag-selections in the camera since it's selecting EVERYTHING in the line of fire and it's hard to get that perspective right in a reasonably sized map anyway.

 

edit: the selection epsilon value can be defined in the user.xml file in your roaming folder: Shut down DR and open the user.xml file, it has these two lines at the top:

 

<?xml version="1.0"?>
<user>
  <ui>
Right after the tag you can add this tag:

 

<?xml version="1.0"?>
<user>
  <ui>
    <selectionEpsilon value="8.0" />
The value 8.0 is the default value, try to increase it to 16 or 24 for testing purposes.

 

Re: slow redraw when resizing. Well, this is hard to fix, since DR has to redraw the views for the update to dsiplay and that's just taking its time in a large map. One can move the far clip plane more inwards to speed up rendering, but rendering has always been taxing, there's only so much optimisation I can do.

 

Re: the memory dump. I can have a look but I don't know if it contains useful information, I'll have to try.

Link to comment
Share on other sites

edit: the selection epsilon value can be defined in the user.xml file in your roaming folder: Shut down DR and open the user.xml file, it has these two lines at the top:

<?xml version="1.0"?>
<user>
  <ui>
Right after the <ui> tag you can add this tag:

<?xml version="1.0"?>
<user>
  <ui>
    <selectionEpsilon value="8.0" />
The value 8.0 is the default value, try to increase it to 16 or 24 for testing purposes.

These lines in this order dont exist -

<?xml version="1.0"?>
<user>
  <ui>

Did you mean? -

<?xml version="1.0"?>
<user>
	<paths>
		<enginePath value="E:/"/>
		<mapPath value="E:/darkmod/fms/campaign/maps/"/>
		<prefabPath value="E:/darkmod/fms/campaign/prefabs/"/>
	</paths>
	<game>
		<type value="Doom 3"/>
		<fs_game_base value="darkmod"/>
		<fs_game value="darkmod/fms/campaign"/>
	</game>
	<ui>

So I put the epsilon value after the <ui> string, so it looks like -

<?xml version="1.0"?>
<user>
	<paths>
		<enginePath value="E:/"/>
		<mapPath value="E:/darkmod/fms/campaign/maps/"/>
		<prefabPath value="E:/darkmod/fms/campaign/prefabs/"/>
	</paths>
	<game>
		<type value="Doom 3"/>
		<fs_game_base value="darkmod"/>
		<fs_game value="darkmod/fms/campaign"/>
	</game>
	<ui>
		<selectionEpsilon value="8.0" />
Re: the memory dump. I can have a look but I don't know if it contains useful information, I'll have to try.

I've nuked the file now, but if it happens again I will upload it somewhere.

Link to comment
Share on other sites

So I gave a spin to 2.0.2pre5 and I don't have "select all behind" issue. After watching Bikerdude's video I don't see how madly clicking back and forth the same brushes is a realistic scenario in production. I did get slight lag 3D view when resizing brush in Ortho view, but I never noticed it until it was pointed out.

 

While I understand people wanting to have absolutely bug free app, it's not feasible to achieve, and I think the focus and energy are better spent on more critical bugs/issues and features that increase productivity :)

 

I have a few questions of my own. I noticed that play button (above 3D view, green triangle) doesn't do anything at all. I see frames counter advancing in 3D view when play is pressed, but nothing happens at all. What is it for anyway?

It also doesn't look like ambient lighting works when render lighting preview is activated. I am not sure if it ever worked, I didn't really use lighting render preview much.

Link to comment
Share on other sites

So I gave a spin to 2.0.2pre5 and I don't have "select all behind" issue. After watching Bikerdude's video I don't see how madly clicking back and forth the same brushes is a realistic scenario in production.

I wasn't madly clicking, it was simulating clicking lots of brushes/patches in succession when one is either creating an FS or pasting a texture etc.

 

I does happen to other mappers, but something particular with my setup accentuates the issue.

Link to comment
Share on other sites

ive been rebuilding my media pc for the last few hours, so will have a proper play with DR and the new epsilon setting this evening and tomoz...

ok tested for a while, its happens lass often but stiull happens.

 

But another bug I have been meaning to report but kept forgetting is the "snap back" issue, bug report - 02251

Link to comment
Share on other sites

Yes, the snap-back is a real problem.

 

It is just very difficult to reproduce. In my last session, it happened almost all the time I moved something, typically func_static collection of brushes and patches.

 

Now when I fired up DR with the intent of getting it to happen, it doesn't.

 

Perhaps it is something to do with session age? When the session has run for long enough it starts happening? Or the user does something that causes it to emerge? Or perhaps it has something to do with the undo-buffer?

 

EDIT: tried to artificially get it to happen, but simply cannot. In previous sessions I feel I often see it. Very odd.

Clipper

-The mapper's best friend.

Link to comment
Share on other sites

its seems to happen more with with lights, but I get it on brushes and models aswell. Will have to test more.

I stand corrected, its doing just as bad on everything now, in fact its now effecting my work flow. So untill Greebo can have a look at it Im going back to 1.8.1.

 

@Motorsep, for example clone and move a light source and a model, then try and drag it to another location. What Sotha and I are experiencing is the selected items constatnly snapping back to the original location.

 

@Greebo, regarding 2.02 its is so much better than 2.0.0 ever was. 2.02 is almost on parity with 1.8.1.

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


  • Recent Status Updates

    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 0 replies
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
    • OrbWeaver

      I like the new frob highlight but it would nice if it was less "flickery" while moving over objects (especially barred metal doors).
      · 4 replies
    • nbohr1more

      Please vote in the 15th Anniversary Contest Theme Poll
       
      · 0 replies
×
×
  • Create New...