Jump to content
The Dark Mod Forums

Recommended Posts

Difficult to say. I don't want to tell you to ditch all your progress, if you put a lot of work into it. Although this happened more than once to me (I once had to revert four hours of chewing through compiler errors, eventually realizing that this won't work out - things like that happen).

 

I guess the above diff file contains these changes as well? I can take a look at it and finish it off, but I would have preferred if the Monsterclip stuff could have been handled separately. (It's usually better not to mix more or less unrelated changes into one commit, because it may be harder to step back in the SVN history.)

 

Anyway, I'll have a look at your diff file now and see whether the problem can be resolved quickly. :)

Link to post
Share on other sites
  • Replies 314
  • Created
  • Last Reply

Top Posters In This Topic

Na, I reverted all that stuff..... a Solution is of course better!

 

Edit: that latest patch misses some includes in OrthoContextMenu.h since I put the Visitor class properly in there and forgot to move the includes, apart from that it should (I hope) work.

Link to post
Share on other sites

I can tell you how to work around the compiler complaints: The problem lies in these lines:

GlobalSelectionSystem().foreachSelected(
  PatchVisibleSelectedVisitor<Functor>(functor)
);

Here, the PatchVisibleSelectedVisitor is passed directly within the function call. This renders the Visitor to be implicitly declared as const, but as the SelectionSystem interface has been changed to only accept a Visitor& visitor, it cannot convert this const Visitor& to non-const.

 

The workaround is this:

PatchVisibleSelectedVisitor<Functor> visitor(functor);
GlobalSelectionSystem().foreachSelected(visitor);

Here, the visitor is definitely declared as non-const, and you can safely pass it to the SelectionSystem without compiler errors.

Link to post
Share on other sites

Okay, understood that one, thanks :-)

 

If you want to submit the monsterClip stuff first, as you said:

The new diff file contains only the monsterClip changes.

Only those two lines are missing in OrthoContextMenu.h

#include "scenelib.h"
#include "selectionlib.h"

 

Compilation then fails with

plugins/entity/light/Light.cpp: At global scope:
plugins/entity/light/Light.cpp:12: error: definition of 'LightShader::m_defaultShader' is not in namespace enclosing 'LightShader'

 

But I think that's not related to my changes.

Link to post
Share on other sites
If you want to submit the monsterClip stuff first, as you said:

The new diff file contains only the monsterClip changes.

Only those two lines are missing in OrthoContextMenu.h

#include "scenelib.h"
#include "selectionlib.h"

Thanks, I'll commit the changes soon. :)

 

I'll make some modifications additional to your diff, so if you're interested you can watch the forthcoming revisions to track my changes.

 

For instance, I changed the inclusion in the OrthoContextMenu.h header to "ipath.h", "iselection.h" and added a forward declaration. This way the headers are as slimmer and the scenelib.h doesn't get copied into everywhere. I also set the default value for the "showOptions" bool to false, so that the other clients don't need to pass it explicitly.

 

Oh, and I just tried to add a model, but it crashes instantly when I select "Add monsterclip". I don't know what may be wrong here. I assume it worked on your end?

 

Compilation then fails with

plugins/entity/light/Light.cpp: At global scope:
plugins/entity/light/Light.cpp:12: error: definition of 'LightShader::m_defaultShader' is not in namespace enclosing 'LightShader'

 

But I think that's not related to my changes.

I'll have to check that, that's probably something only gcc 4+ is reporting. MinGW doesn't complain about this.

Link to post
Share on other sites

Another thing: there is a boost equivalent for dynamic_cast designed for shared_ptrs:

// Ordinary pointer
MyClass* test = dynamic_cast<MyClass*>(pointer);

// shared_ptr
boost::shared_ptr<MyClass> test = 
 boost::dynamic_pointer_cast<MyClass>(shared_pointer);

I'll change that in your diff before committing it, so you don't need to correct it on your end.

Link to post
Share on other sites

Ok, I committed your changes and moved the ModelFinder to a separate file pair in selection::algorithm, so that other stuff can be use it as well.

 

I fixed a crash when the ModelFinder was encountering non-entities (Node_getEntity() can return NULL if the cast was unsuccessful). I also encapsulated the members and made them private (and renamed them according to the naming convention for class members).

 

Overall, the feature works very well, so this is another step forward, well done! :)

 

There is one thing left to do, which I leave to you, because it's useful to learn, I think. Currently, the "textures/common/monsterclip" shader is hardcoded in the OrthoContextMenu.cpp file, but can be game-specific or might change in the future. The better place for this is the games/doom3.game file, which can be accessed via the XMLRegistry.

 

Have you already worked with the Registry? If not, I can of course explain it to you - this is quite an important part of DarkRadiant, as all the settings and configurations are stored there. You don't need to know the inner workings of the module, just how to add settings, and access them. There is also a Wiki page about the XMLRegistry, so you might want to check that out first.

Link to post
Share on other sites

There is a section in the doom3.game file. Create a new XML tag somewhere in this section.

 

The XPath should be something like: game/defaults/monsterClipShader, which is the same path you can use to query it:

  namespace {
   const std::string RKEY_MONSTERCLIP_SHADER = "game/defaults/monsterClipShader";
 }

// somewhere else in the code
... = GlobalRegistry().get(RKEY_MONSTERCLIP_SHADER);

 

I'll see if I need to update the wiki article. :)

Link to post
Share on other sites

Okay, I think I got that thing, really wasn't hard.

But my radiant will strictly not start.

in plugins/entity/light/Light.cpp I needed to put

std::string LightShader::m_defaultShader = "";
namespace entity {

before the namespace, because it wouldn't compile otherwise.

But on start radiant segfaults with

WARNING: Failed to load module /home/patrick/development/apps/darkradiant/cvs/head/install/modules/entity.so:
/home/patrick/development/apps/darkradiant/cvs/head/install/modules/entity.so: undefined symbol: _ZTI6Entity
Segmentation fault

Link to post
Share on other sites

Fixed. I seem to have forgotten to move the LightShader code into the entity namespace, and the initialisation failed. MinGW didn't complain about this.

Link to post
Share on other sites

Sounds strange, but with latest head I still get that Segmentation fault, I'll try gdb...

 

Edit: gdb spits out:

(gdb) run
Starting program: /home/patrick/development/apps/darkradiant/cvs/head/install/darkradiant 
WARNING: Failed to load module /home/patrick/development/apps/darkradiant/cvs/head/install/modules/entity.so:
/home/patrick/development/apps/darkradiant/cvs/head/install/modules/entity.so: undefined symbol: _ZTI6Entity

Program received signal SIGSEGV, Segmentation fault.
0x082abd90 in ui::MRU::constructPreferences ()
(gdb) bt
#0  0x082abd90 in ui::MRU::constructPreferences ()
#1  0x082ac667 in ui::MRU::MRU ()
#2  0x082acc2a in GlobalMRU ()
#3  0x080fdb80 in Radiant_Initialise ()
#4  0x080f7cfe in main ()

Link to post
Share on other sites

Strange, everything works fine on my end. Did you try to compile from scratch after a scons -c? Are there any old modules lying around in your modules/ subfolder?

Link to post
Share on other sites

Fanally switched my PC on first time since two days, sort of a record...

 

Well, I did a completely new checkout, deleted my .darkradiant dir, compiled and still the error stays, quite stupid.... I have honestly no clue what the problem could be.

Link to post
Share on other sites

I can reproduce that (strange, I couldn't in using my 32 bit Linux machine, but here on AMD64 Ubuntu it's reproducible).

 

I'm currently stepping back the SVN history to check where this happened, but I assume that there is something amiss with the namespace changes I recently checked in (the LightShader::m_shader stuff, as you recall).

Link to post
Share on other sites

Revision 2120 works (if you put the namespace entity {} braces around the LightShader), I'm currently checking 2122.

 

edit: I think I've found the error, recompiling now to check.

Link to post
Share on other sites

Fixed. I added the virtual bool isModel() const method and intended to add a standard implementation in the base class, but removed the implementation later before committing. Unfortunately I forgot to make the method abstract, and this seemed to screw up the module definitions.

 

Please sync up and try again, it should be gone now. :)

Link to post
Share on other sites

Jup, good work :-), radiant finally starts again. But now it segfaults when using the new monsterclip functions :-(

 

Program received signal SIGSEGV, Segmentation fault.
0x082c1d1b in TraversableNodeSet::traverse ()
(gdb) bt
#0  0x082c1d1b in TraversableNodeSet::traverse ()
#1  0x082b8962 in map::(anonymous namespace)::Node_insertChildFirst ()
#2  0x082bc15a in map::(anonymous namespace)::createWorldspawn ()
#3  0x082bc3ec in map::Map::updateWorldspawn ()
#4  0x082bc4b8 in map::Map::findOrInsertWorldspawn ()
#5  0x0818062d in ui::OrthoContextMenu::callbackAddModel ()

 

I will have a look at that segfault tomorrow.

 

btw. If you want to try the registry thing you taked about, I uploaded a patch. I can't try it, since radiant segfaults me, so no idea whether it works or not.

Link to post
Share on other sites

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1232931120 (LWP 13804)]
0x0820fbf5 in boost::detail::atomic_increment (pw=0x1d) at /usr/include/boost/detail/sp_counted_base_gcc_x86.hpp:66
66		  );
(gdb) bt
#0  0x0820fbf5 in boost::detail::atomic_increment (pw=0x1d) at /usr/include/boost/detail/sp_counted_base_gcc_x86.hpp:66
#1  0x0820fc1a in boost::detail::sp_counted_base::add_ref_copy (this=0x19)
at /usr/include/boost/detail/sp_counted_base_gcc_x86.hpp:133
#2  0x0820fd2e in shared_count (this=0xbfc04938, r=@0x91c6fc4) at /usr/include/boost/detail/shared_count.hpp:170
#3  0x08210446 in shared_ptr (this=0xbfc04934) at /usr/include/boost/shared_ptr.hpp:106
#4  0x0841323a in TraversableNodeSet::traverse (this=0x9a64cc8, walker=@0xbfc04990) at libs/traverselib.h:222
#5  0x0840bd29 in map::(anonymous namespace)::Node_insertChildFirst (parent=@0xbfc04a48, child=@0xbfc04a40)
at radiant/map/Map.cpp:86
#6  0x0840c196 in map::(anonymous namespace)::createWorldspawn () at radiant/map/Map.cpp:98
#7  0x0840c25e in map::Map::updateWorldspawn (this=0x85156c0) at radiant/map/Map.cpp:347
#8  0x0840c2c7 in map::Map::findOrInsertWorldspawn (this=0x85156c0) at radiant/map/Map.cpp:352
#9  0x082d456d in ui::OrthoContextMenu::callbackAddModel (item=0x98c9b60, self=0x8509380)
at radiant/ui/ortho/OrthoContextMenu.cpp:302
#10 0xb78230b9 in g_cclosure_marshal_VOID__VOID () from /usr/lib/libgobject-2.0.so.0
#11 0xb7815ec9 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#12 0xb7826901 in ?? () from /usr/lib/libgobject-2.0.so.0
#13 0x09a76610 in ?? ()
#14 0x00000000 in ?? ()

I recompiled it with debug flags, this is the output I get.

 

Another thing I noticed, is that it works correct if a model is loaded without clipBox first.

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.


×
×
  • Create New...