greebo

Ok, then. I've changed a lot files btw, most of the deprecated vector3_yyyy functions are history now. edit: Ah, found it, the changes are reverted now.

I use a different binary parser and such. They won't fit for Linux environments, I'm afraid. edit: Hm. Update to Revision works for my local copy, but it doesn't let me commit the reverted copies.

I just accidentally committed the .cdtproject and .project files (I meant to tick them off but obviously forgot this). How can I revert such a change on the server? The files are made for my Windows environment, so you don't want to update now, I guess. Do I have to revert the change to revision 83 and re-commit the files?

Yes, it's Gildoran, I believe. I haven't started yet looking at the SDK, as DarkRadiant is keeping me busy, but I definitely will sometime in the future. BTW, is Gildoran away for a while? Does anybody know?

Agreed. Let's remove it then, it's just a matter of editing the XML file anyway. We can leave the code for now, perhaps it gets fixed sometime by the GTKRadiant people. If the fix turns out to be un-appliable at that time, we can strip the code as well.

What shall we do with the modifier, fix or remove it? I'm always using the QER-style modifier that can both scale and translate, so I would vote for removing it. Or should we wait till the GTKRadiant people fix it?

When does this error occur? Right at startup or at shutdown or sometime random?

Cool. Glad it was nothing more serious. For the next release this kind of pain won't happen (promised) as I already have an idea for a simple upgrading system that's not too hard to implement. @Orbweaver: could you edit this task into the todo-list in the programming forum? (Or am I able to do this myself, I don't know?) I also got some news for the vector.h refactoring: I have added most of the operators to the Vector3 class (*, *=, +, +=, -, -=, /, /=, inner product) and already replaced all deprecated vector3_dot() function calls. I won't commit it yet, however, as I want to wait till DR 0.7.0 is released.

This is the part that's describing the problem: XMLRegistry: Importing XML file: /home/newhorizon/darkradiant/install/user.xml XMLRegistry: Critical: Could not parse /home/newhorizon/darkradiant/install/user.xml XMLRegistry: Critical: File does not exist or is not valid XML! It seems that there is no user.xml in your install/ folder, please try to checkout the file again. You can safely delete the user.xml file in the hidden folder (it gets copied over by the install/user.xml at startup).

You sure that you are looking in the right folder? It's a hidden folder: /home/newhorizon/.darkradiant (note the point). You can show the hidden files in Nautilus by pressing Ctrl-H. Sorry, if I sound smart-ass and say the obvious, I just want to make sure.

A completely different question: does the "scale" operator work for anyone else here? Create a brush, toggle the "scale" mode on the toolbar, and try to drag a brush. What happens for you? For me, the brush get's stretched ad infinitum, and just a thin line remains. Can anyone reproduce this? First I thought I have screwed some of the vector operations, but this seems to be a problem with Radiant in general.

Ok, let's wait for New Horizon, then.

Ok, as soon as I get my hands on the log file, I will look into this. edit: just looked at the toolbar code: it's already bolted up against NULL pointers, so perhaps it's some missing colours causing the problem.

Yeah, I recognised that screenshot. In fact, we added a lot of optimisations since the first internal "release", so it should also be better performing with all the shadows on. Many of the light volumes were intersecting in the first version, this is mostly resolved now.

I just managed to implement the + and - operations to the Vector3 class, which work seamlessly (I commented out the operator in math/vector.h and it works flawlessly). I will try to do as much as possible without having to touch every single cpp-file in the codebase. I got such a crash once when I ran DarkRadiant with a completely outdated user.xml in my user settings folder. I guess this had to do with all the toolbars that were missing, so I could imagine that's the case here. A log dump would definitely help to write a more fail-safe routine to include those XML settings.

Wow, I just realised that there is a bonehoard screenshot in that thread... I'm all red in the face now, thanks New Horizon! I guess this is the best way to convince all those people on TTLG is to let screenshots or even a demo map speak for the Dark Mod.

What function do your refer to? The vector_substracted() one? This is already a template, it's in one of the last posts.

Ah, I think I got the idea, why the vector addition was implemented this way, and not directly in the class: the above declaration of vector3_substracted() is designed such way, that one can also substract Vector3s of different type (e.g. an int-Vector3 and a float-Vector3). I'm not sure if this is feasible with declaring the operation within the class BasicVector3 itself, someone with more experience might well know that. I don't know how often this happens, though, but I guess I'll leave it as is is then, before anything breaks. edit: perhaps the + operator can be defined as a template operator, analogous to this templated constructor? template<typename OtherElement> BasicVector3(const BasicVector3<OtherElement>& other) { x() = static_cast<Element>(other.x()); y() = static_cast<Element>(other.y()); z() = static_cast<Element>(other.z()); }

I have a question regarding the generic/vector.h lib: While disentangling the code of selection.cpp I noticed masses of function that look pretty deprecated to me, like: vector3_subtracted(origin, ray.origin); Looking at the BasicVector3 template, I found that the Vector3 class has no + or - operators defined, wouldn't this be handy or is there a specific reason for using functions like vector3_substracted()? This is C-style, isn't it? In fact, I found an implementation of the - operator in math/vector.h: template<typename Element, typename OtherElement> inline BasicVector3<Element> operator-(const BasicVector3<Element>& self, const BasicVector3<OtherElement>& other) { return vector3_subtracted(self, other); } that again is calling vector3_substracted() what I somehow find weird... this should be declared in the class BasicVector3, shouldn't it? Another thing I wanted to ask: I found this line in the getLength() function of BasicVector3: double lenSquared = x()*x() + y()*y() + z()*z(); Wouldn't it be faster if this was implemented like this double lenSquared = m_elements[0]*m_elements[0] + m_elements[1]*m_elements[1] + m_elements[2]*m_elements[2]; without having to call the internal function six times? Or is this neglectable in terms of speed? Maybe I'm thinking too conservative in terms of CPU cycles (like I had to in the olden days ), perhaps I underestimate the optimisation routines of g++, I just wanted to know.

Hm. Have you tried to delete your user.xml file in your /home/newhorizon/.darkradiant folder?

I just want to chime in here, good shots!

I really hope the hard drive is the reason for the lame performance. Otherwise Ubuntu is no improvement in comparison to Windows for me at the moment. One spends already too much time waiting for the computer to do his job, I don't want to increase this time even more... Anyways, it seems everything is working with DarkRadiant, thanks for the changes! Is there anything missing for version 0.7.0?

Yes, so it seems. I will re-install my system in the near future anyway, as the hard disk partitioning is not good at the moment (I just wanted to give it a try, so I installed it on a small, secondary 40 GB drive). If the performance is still not increasing after this re-install, I don't believe that I will spend too much time on Linux in the next year or so, as Windows seems to be far better performing on this very system.

I don't wanted to post in the Off-Topic forum, as this is scons-related: Is there a possibility to turn off the update notification for scons 096.92-02? I had to re-install the 0.96.1 package for Ubuntu 6.06 as New Horizon and now it bugs me everytime to update the (working) package with the (not working) package...

I can't compile right now as my Linux runs crappier by the minute and even reboots don't help. It just kind of hangs at random times and accesses the hard drive like mad, but doesn't proceed a bit, especially during compile. It was better with Ubuntu 6.06 than it is now, but it doesn't need to correlate with the update... hmpf. I just read through the code and it looks definitely better than before , I hope I can compile the thing in the evening, but I'm positive that nothing broke.