greebo

Yes sure, hang on. EDIT: sent to your gmail account. The testmodule is located under plugins/testmodule/. The patch creator warned me about not creating these files, so I hope you can apply this patch. Basically, these are the changed files: - includes/itest.h - radiant/mainframe.cpp - plugins/testmodule/ (folder added) - plugins/testmodule/test.cpp - Sconscript Thanks for looking into this!

Gah, I will let this rest until I have some better ideas how to solve this. I just copied over your filters.cpp file and changed the absolute minimum and it still crashes the second I call the echo() method. The point where I call the echo() method is located at the bottom of Radiant_Initialise() in mainframe.cpp where everything should be loaded.

Hm, would it be too radical to kick the support for multiple game files? Would there be disadvantages for us? (It seems that the .game files are needed before the modules to load the game-specific shortcuts.ini and local.pref from e.g. ~/.darkradiant/doom3.game folder.) EDIT: woah, I tried to move the game file loading process after the DLL ModuleLoad and I get even more crashes now. But it's possible that there is something screwed with my .dll, as soon as I try to call a test method (e.g. Globalregistry().dump(), which does exactly nothing, I commented everything out) the program bails out. I checked if the module is loaded correctly (it is). EDIT^2: Ok, I probably missed something: I just tried to implement a module named "testmodule" to test if I'm capable of installing any module (it has just one method called echo() that writes to std::cout) and it compiles, loads but still crashes on the echo() call. Any directions or common mistakes I could check?

I've turned the XMLRegistry into a module now, but I found this problem: In main.cpp there is the g_GamesDialog.Init(); call that loads the appropriate game file. The problem is that this function already expects the XMLRegistry to be setup correctly, but it isn't as all the modules are initialised in Radiant_Initialise() in mainframe.cpp which is quite a few lines below the former call. What is the plan? I don't know how deadly it is to change the order of these calls as the shader module for example expects the game file to be already located. Should I try to implement some kind of load() method to the game file dialog, so that the actual loading is done when the modules are initialised?

Yes, this is another thing I want to understand, I will take a look at this! If it's easily accomplished, I will convert the XMLRegistry soon, let's see...

I had this problem once, it was with my first DarkRadiant compile (July, I guess around version 0.5.0). The stretch value accidentally hit zero and the program immediately crashed. Can you give more detailed instructions (I guess you're using the 0.7.0 release?) and perhaps a map or something?

Well, I don't really have that much insight yet, I still didn't understand where exactly the things do happen in the code, it's so nebulous. My approach was to cut these huge files into small pieces and try to understand what the heck they do (I started with selection.cpp, but I'm not finished yet). In other words, if you'd like to do it... I still can't say if it is too much for me or not. You've got much more experience than me, so I guess the problem would be solved much faster if you would do it. However, I will continue to disentangle the files, just drop me a note, if you need exclusive access to selection.cpp so that we can avoid any conflicts.

I've just committed the following changes: - generic/vector.h and math/vector.h are gone - separated BasicVector classes into files: math/Vector2.h, math/Vector3.h, math/Vector4.h - removed all deprecated Vector2, Vector3, Vector4 functions Tomorrow I will look into the selection.cpp file again and see if I can do something about the draggable light center.

Yes, this is exactly what solved the problem. I've almost replaced all of the BasicVector4 methods and I'm currently splitting the Vector definitions into separate files. This week was very busy, but I should be able to commit this soon.

If you want to get a feeling what working for TDM is about, you should take a look at the game Doom 3 itself and try to do some Level Editing, Modeling, Texturing or whatever you're talented in, this really depends. There are a lot of Tutorials on www.doom3world.org, its Forums and also on DarkWiki. Generally speaking, it's never too late to do the first step, as I myself started modding in July this year. It's just a matter of interest and dedication, so I can really encourage everyone who is interested to try.

EDITED C++ was complaining: In file included from bleh, bleh, libs/math/matrix.h: In member function `Vector4 Matrix4::transform(const Vector4&) const': libs/math/matrix.h:288: error: ISO C++ says that these are ambiguous, even though the worst conversion for the first is better than the worst conversion for the second: libs/math/Vector4.h:83: note: candidate 1: Element BasicVector4<Element>::operator[](size_t) const [with Element = float] libs/math/matrix.h:288: note: candidate 2: operator[](const float*, int) <built-in> I already found the problem, there was another operator defined in Vector4 that I've missed.

If you're looking for a free forum software, you might want to take a look at phpBB: http://www.phpbb.com This is most probably the best forum you can get without paying license fees. If you don't need it right now, I would suggest waiting for the new version 3.0, which is a huge step forward in comparison to the current phpBB 2.2. edit: Redface was faster, it seems

I really doubt that my processor or the size of my RAM does matter in this case, but it's a Athlon XP 2500+ with 512 Megs of RAM. The process that is responsible for this behaviour takes (according to ps aux) 40% and around 50% of RAM. However, the hard drive is constantly accessed, I believe to recognise some kind of pattern in the accesses (though I could also be imagining this). I'm somehow disappointed that the Linux multitasking performance is so weak on my system, and in comparison to my Windows XP partition it's lame (although the hard drive where Windows XP is installed, is an 80GB drive, to be fair). I will try to re-install Linux (6.06 to be precise ) at some time, but somehow I'm not really motivated to mess around with such kind of things, I really have better things to do with my freetime. Perhaps I will look into this after I've finished my diploma.

Now that really sucks: I just tried to compile DarkRadiant on my Ubuntu 6.10 and everytime it hits brushmanip.cpp it eats up my system (mouse pointer moves every now and then, system clock stops, can't even open a console window to kill the process). The only way to stop the compiler is to have a console opened before I start compiling and be on my toes to find out the process number before the system stops responding at all. Hmpf, didn't have something like that with Ubuntu 6.06 but I can't be sure if it's the Ubuntu upgrade alone. Does anybody know whether the compiler version has been changed within edgy eft?

Happy Birthday!

(In Windows) I have setup my Doom 3 icon with a keyboard shortcut like Ctrl-Alt-D, which is also possible in Linux (haven't checked, but I'm positive). I also have shortcuts for my texteditor (Ctrl-Alt-E) and DarkRadiant (Ctrl-Alt-R), this way I only need one hand to fire up these apps. There is an autoexec.cfg in the Doom 3 folder and I tested it once if it's possible to drop a testmap bonehoard in there. I think it worked, although I can't remember right now. Perhaps this is the place to start looking for such a feature.

Ok, all of the deprecated vector2_bleh functions are gone. I'm afraid this is enough for today, I will try to achieve more of this the next days.

Ok, after this clean-up I will try to change the Vector3 definition and see what the compiler has to say about this... This was my plan. Is generic/ the right folder for this in the first place? Shouldn't this go to math/?

Ok, thought so. I don't know if there are any precision-critical applications in DarkRadiant. Another thing: I found that the Vector2 class is only used by patch.cpp a few files. Should I split the generic/vector.h into parts (generic/vector2.h, etc.)?

Ok, I'll look into it. Is there a difference between double and float in terms of speed?

Shouldn't this work by just changing the Vector3 definition to BasicVector3?

Unfortunately yes. I saw a BasicVector3 at least once, which was causing a compiler problem with accessing the member variables of the -Vector in the methods. I got around this by accessing the components via other.x() instead of static_cast(other.m_elements[0]). This happened with the += operator, so I guess there is a vector addition with a double vector out there somewhere. I couldn't be arsed to go into detail and investigate if the double was necessary, so I changed the implementation. edit: it's radiant/winding.h and libs/math/plane.h that use such a type.

Ok, thanks for explaining, highly appreciated! I'm off to working on BasicVector2 now...

Do I get this right: as soon as I put the implementation of a member function into the class declaration it becomes an inline function, even without the keyword inline. Do templated functions need to be implemented in the header file or is it possible for them to be moved into the cpp file? (I can imagine that these vector functions are "important" enough to have them inlined as they are used a lot and should be fast, so I probably wouldn't want to move them in a cpp file, but I just want to understand this right.) I will remove the inline from the declaration keyword, then.

No problem, I could have been faster, but I took my time, because I didn't want to break anything. The Vector2 and Vector4 classes are to follow. I don't understand this entirely. Do you mean that the inline keyword can be skipped here? Unfortunately, there is code that requires the vectors to be multiplicated in this mathematically incorrect way. I would have gladly removed this, but I didn't want to stir too much dirt up here.