DarkRadiant 2.0.4 pre-release testing

[greebo]

Oh, appears like dramthethief.com is dead. I'll upload it to somewhere else.

 

edit: done

[Bikerdude]

Thanks fella, i'll download from the new links as soon as they are up.

 

And regarding links, why not use one of the official mirrors for now - drop me a pm if you need the login details.

 

i see you've sorted already, downloading.

[greebo]

You're saying you can make DR crash pretty frequently. Maybe it's feasible to record a video of you doing that? It might help me trying to figure out what's causing it to crash.

 

If that doesn't help, I'll probably have to create special debug builds for you, or compile a version that's using extensive logging.

[Bikerdude]

I was using pre1, I have now updated to pre2. So I will have a proper play this evening and see if I keep getting a crash.

[Bikerdude]

Ok, pre2 is much better but still managed to get a CTD after about 1-2hrs or solid work. Pressing escape is still causing the crash -

 

- dumpfile.

 

Also I have noticed that when pressing escape to deselect, if I don't click into the main window before pressign escape - Windows 7 beeps at me. So I am guessing there is a focus issue where DR isnt treating its child windows as part of the main window.

[greebo]

Can I have copy of your settings xml files, please?

[Bikerdude]

Can I have copy of your settings xml files, please?

here yer go fella -

 

bikerdude_dr_files.zip.txt

 

[greebo]

Ok, thanks, the files helped me figure out what's going on. The steps to reproduce the bug are as follows:

 

- Switch off the option "Freelook mode can be toggled"

- RMB in the camview to enter freelook mode and keep the RMB held down

- Hit the MMB during the freelook-around

- Hit ESC >> Crash

 

Can you confirm this with pre2?

[Bikerdude]

Let me do some more mapping now and come back to you shortly.

 

Switch off the option "Freelook mode can be toggled - this was already switched off

 

But yep, doing the above steps caused an instant crash! on pre2

[greebo]

I ran into the same issue on Feb 15th, so it's sort of fixed already in the latest source. But I understand now how this situation can occur in the first place - I always have the freelook toggle mode activated that's why I didn't run into this as easily as you. I need to think about the code to come up with a better design. The latest source doesn't crash, but it's more of a defensive workaround.

[Bikerdude]

Thanks fella, I very much appreciate you looking into this.

[Spooks]

You cannot set negative values in the particle editor, something that iirc was possible in 2.0.2. Doesn't work in 2.0.3/2.0.4 pre2. Take any of the recyc_hexdrip particles e.g., specifically the second stages (the water droplet splashes). Their speed is -30 to 9, but the particle editor clamps the first value to 0, and if a mapper clones one of those for a custom particle it will come out wrong.

 

e: speaking of values being clamped I put an AI tab UI issue like this on the tracker (and thank you greebo for moving that other one, I was dead tired when submitting it and it shouldn't have been in the DR section )

Edited March 22, 2016 by Spooks

[greebo]

I uploaded a new pre-release build. The discussed crashes when using the mouse and another crash should be gone. I also improved the func_static rotation handling once again. See the first post for download links and a list of what has been fixed.

 

I'm still working on making the mouse interaction code more stable.

[Bikerdude]

Niiiiooooce......!

 

The escape related crashing was starting to get on my proverbial nerve.

[grayman]

Got it.

 

The first prefab I tried rotating was containers/chest_wood_old.pfb.

 

The atdm:target_set_frobable inside the chest, while rotating properly, sent its origin way far away.

 

I'll note that in the tracker issue.

[greebo]

Thanks for spotting it, it's a weird thing. It only applies to that minus-90-degree-z-axis button in the toolbar, curiously enough it's working fine when using the Transformation dialog for rotating the stuff about the same amount. I'll track it down sooner or later.

[Bikerdude]

Well so far no escape based crashing! and even got Sotha using this build..

[DeTeEff]

- Improved rotation code for multi-ent selection (#230), this should make prefab placement a bit easier

 

 

THIS should give the creator a Nobel Peace prize!

[grayman]

I've been using the latest build w/no problems (though avoiding the 90 degree rotation buttons).

[greebo]

I have a new build (pre4) up with the rotation button behaviour fixed. It was caused by incorrect hardcoded quaternions that date back to the GtkRadiant base we've been forking from, it's curious that it had been working at all. I double-checked the calculations and replaced the wrong values (as usual, the difference was just one minus sign). Now I could rotate the whole map by 90 degrees using the button, so hopefully we should be in good shape now.

[grayman]

Now I could rotate the whole map by 90 degrees using the button, so hopefully we should be in good shape now.

 

A HUGE benefit! (Not that I want to rotate maps, but I do want to rotate rooms, buildings, walls, etc.)

 

Thanks! Getting now.

[Bikerdude]

Greebo, you are a little star!

[Bikerdude]

Afternoon

 

Hi Greebo regarding the following bug tracker #4276, your response was -

 

"This is due to the Octree filtering out scene nodes. If a node is not rendered, its target keys are not drawn either. A possible workaround would be to submit the target lines as separate entities (either to the scene or to the rendering system). One has to take care not to use the GlobalRenderSystem() but the one attached to the owning entity node"

 

The issue I think isnt that the path_nodes aren't being render but that the target lines between them aren't. For example a given path_wait or path_corner can be just off-screen and he target line is still drawn, but then you move the view so the path_node goes further off-screen its at that point the target-line disappears. And this dosent apply to all path_nudes that are off screen either.

 

The issue with the target lines disappearing is that its almost impossible to follow a given path, as you have to stop move the camera around contently to see where the paths are going - vastly slowing down workflow.

[Bikerdude]

Filed 2 more bugs -

 

• http://bugs.thedarkmod.com/view.php?id=4307
• http://bugs.thedarkmod.com/view.php?id=4308

[Bikerdude]

Logged another bug -

• http://bugs.thedarkmod.com/view.php?id=4309

Any idea on this old bug? -

• http://bugs.thedarkmod.com/view.php?id=4276