Itches, Glitches & Anything Else...

[greebo]

Thanks for fixing the Sconscript, OrbWeaver. I was about to commit the fixed version, when I noticed that you already changed it.

 

My scons is not working anymore in Linux (yet again). It doesn't recompile any changed files or sources depending on changed files - I always have to trigger a recompile by deleting the .so files from the build/ folder. Pretty annoying, it worked fine the whole afternoon and then it suddenly stops working...

[OrbWeaver]

Perhaps you need to delete your scons.signatures.dblite file? This will of course trigger a full rebuild, but hopefully things will work correctly after that.

[greebo]

Already tried that, doesn't help. A reboot resolves it, usually.

 

I think it's caused by or at least related to the issues I'm having with the system clock (the time was two hours in the future after switching from XP to Ubuntu). If it synchronises and turns back the time while I'm coding on things, this would explain a few things.

 

I turned off the UTC handling in the /etc/defaults/rcS file now - let's see whether this helps.

[Fidcal]

There's something a bit odd about shortcut assignment. I had the left and right arrow keys turning left and right by default and at the same time the mouse left and right (in free move mode) also doing this. That's fine. But when I cleared the left right arrow keys, DR will not let me restore them [edit back to turning left and right I mean] without removing the mouse left and right even though they both were set that way before. I've set it in input.xml so it's OK now but might need a tweak in the input tests? If so, let me know if you want me to put it on the bug tracker. Think I've also got a note to put up that one about the texture browser filter and scroll bar prefs but not yet found time to check it out.

 

BTW what I really was trying to do was to always strafe on the left right arrow keys. I've done that now using the input.xml. I've got to like the mouse control in camera view so much that I only really use that for moving and turning but when I come out of that mode I found it confusing that the left right arrow keys, that strafe in mouse mode now do a turn. So personally I prefer them to strafe only. I've put turn on the comma and period though I just don't think I'll need them much.

 

It's amazing how you can drag stuff around and resize directly in camera view though it's a bit of a knack else you can move in the wrong plain.

[greebo]

Ah, I see what you mean. The problem is that the Left/Right/Up/Down keys are double-assigned, as the "CameraFreeMove" and "CameraMove" commands are technically two different things. The Shortcut Chooser complains about that, of course, so I have two possibilities now: Let the shortcut chooser optionally ignore double-assignments or let the user edit the input.xml manually, as you did. I would tend to the former, what do you think?

 

The Texture Browser Filter issue (the one where it is showing up even with the preference setting set to disabled) is already fixed.

[Fidcal]

Are there any double assignments that might cause a serious problem? I mean other than one would not work and the user would have to change it. I think either way but document the input.xml eventually anyway. Maybe if double assignments are allowed then just modify the current warning but allow the change so at least the user does not double assign without realizing. Maybe three 'change to new/allow both/cancel' options.

[greebo]

I can't really say whether commands will be conflicting, but it could be possible. Maybe this even has some positive effects, but I can't say for sure.

 

The contents of the input.xml are more or less self-explaining, aren't they?

[Fidcal]

Yes but worth mentioning it exists and the path as it is not in the DR folder. I doubt it will be needed much except for awkward soandsos like me.

 

Another minor glitch. If the user maximizes the camera view then closes DR then the full size is stored so on reload if restore is selected it seems nothing happens because the restore size is the same as full screen. Don't know if any other child windows are like that.

 

While talking about resizing child windows, there are a few that don't retain the user's size/position. This is a minor irritation I know which is why I've never mentioned it. It's probably mostly ones that are not used too often like key shortcuts. I see a tiny window that needs three drags for me to get a good look at the list comfortably. Since you cannot then test any change without closing that window and losing the settings I find my curse quota for the day is exceeded.

[greebo]

I've opened the Tips & Tricks wiki page for DarkRadiant a while ago (http://www.thirdfilms.com/darkwiki/index.p...Tips_and_Tricks). Feel free to write anything into that page when you feel something might be worth knowing.

 

The resizing issues: Most modal DarkRadiant dialogs are centered in the middle of the screen and have a fixed width. This can be changed to a variable width/height relative to the screen resolution, if you want. Feel free to open an issue on the bugtracker, but keep in mind that you are running your desktop using a really large font.

[Mr Mike]

How do I tell which is clipper's operative side in DR? I can't see any difference and usually have to just try it and then undo and redo it.

 

In the 3D view you can see a blue plane, which highlights what edge will be kept, but it's not too helpful to have too look there.

 

I always work in a clockwise direction, and it always seems to give me the desired result.

 

For example, imagine a clock face. If you clipped at the 12 and 6, you would be left with the left hand side. Clip the 6 and then 12, it will leave the right.

 

Does that make sense? I'll take some screengrabs if it will help.

[Fidcal]

Hey you're right! However the 0 and 1 are oriented the piece is removed to their right viewing them with the 0 at the top and 1 at the bottom...

 

0

---->

1

 

Or regarding 0 as 12 on a clock and 1 as 6 then the 3 is always the direction that will be clipped however the clockface is turned. Good one.

 

Thanks MrMike.

[Fidcal]

The visportal filter also hides nodraw.

[greebo]

Yes, I did this on purpose, because otherwise only one face of the visportal brush would be hidden, which would make the filter kind of pointless.

[greebo]

The UnsortedSet container is gone. I could refactor the TraversableNodeSet, the Doom3Entity and the KeyValue classes to use std::vector instead, which seems to be good enough. I also documented and tidied all the things in traverselib.h and cleaned a bunch of other places too. So far for my weekend's effort to "Make the DarkRadiant Codebase a Better Place™".

[Komag]

So far for my weekend's effort to "Make the DarkRadiant Codebase a Better Place".

 

Yay!

[Fidcal]

Sometimes the camera icon faces the opposite way. In the screenshot you see the selected red triangle is viewed in camera view but is behind the camera icon in orthoview. If I turn up and down in camera view then the icon tilts up and down so it is updating OK but pointing the opposite way I am facing:

 

[Fidcal]

If I open my map in Dark Radiant then Doom crashes when I open it in windowed mode.

 

In my betamapper repository folder is m896.map. You might try the following to see if it does the same on your system. With doom NOT running, open the map in Dark Radiant. Then open darkmod/doom in windowed mode. I find it locks up into super slow mode. The in-game curse does not move and the start menu appears very very slowly. If I press the console key it does eventually appear after half a minute or more and every keypress takes half a minute or more. I have to use Task Manager to get out of doom. If I do it the other way round, open doom first so its running OK, then load Dark Radiant and m896 then no problem.

 

Now, if it does that on your system, in Dark Radiant, in plan view, zoom out to see the whole map. At left in the top half are 5 big patches. Delete them then resave with a new name say M896B.map. Then close Dark Radiant and re-open with this changed map. Then try doom again and it should work OK.

 

Note that the patches are not yet in their final positions or shapes but just placed roughly where I want them. The big patch at the bottom was there before and does not seem to cause this problem.

 

I tried deleting the 5 patches one by one and testing every time to see if it was one particular one but only when all 5 were deleted did I get the error.

 

This is Dark Radiant 0.9.2 Build date: June 21 2007 17:11:46.

[OrbWeaver]

What texture do you have on the problematic patches? That slowdown behaviour is consistent with viewing materials with fragment shaders (such as heatHaze.vfp) in windowed mode with an ATI card.

[Fidcal]

It's textures/darkmod/nature/grass/short_dry_grass. Now you mention it, that's what they have in common; the other big patch that is OK has some other texture. But mine's an Nvidia card gforceFX5900.

[Fidcal]

I should underline that the map works in Doom - it is only that Doom crashes if the map is open in Dark Radiant.

[greebo]

If DarkRadiant and Doom are interfering, this sounds more like a graphics driver problem. DarkRadiant has technically very little to do with the actual engine, apart from opening the PK4s, but this doesn't cause a crash. The only things that DarkRadiant and Doom3 have in common is the use of OpenGL functions.

 

Are you sure this cannot be resolved with a reboot and a clean restart of both programs?

[Fidcal]

Yes, first thing I tried was a reboot.

 

I just tried a different texture and that fixes it. In fact to force the error you need only start with a blank map, drag out a brush and texture it with textures/darkmod/nature/grass/short_dry_grass. No need to even save the map. Just open Doom in windowed mode and it crashes.

[Komag]

I just tried exactly that but mine didn't crash. So maybe it's drivers? I have an ATI card.

[OrbWeaver]

It sounds like some driver-related issue with contention between concurrent OpenGL applications, but I don't see much we can do about that without an OpenGL expert on hand.

[Fidcal]

Just downloaded the latest Nvidia update. It extracts all the drivers into its own default folder but then crashes 'can't find any drivers compatible with your hardware'. The download clearly gives my card FX5900, XP Home.

 

I see my last download (v93.71) was in February and the same filename except the version number is later on the new one (94.24). No doubt in my mind it is the correct download.

 

Searching, searching for info. On Nvidia's website 'support' (haha!) it describes a completely different route and probably obsolete way to install its drivers via the Windows driver update route. Worth a try. Too late! At last click I realize it's just re-installing part of the previous drivers. Forced reboot. Lost all my settings carefully tweaked over months - Thief 2, Oblivion, Dark Mod, etc etc. An hour wasted. Screw drivers and screw you Nvidia.