DarkRadiant 2.0.4 pre-release testing

[greebo 29]

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

 

edit: done

[Bikerdude 3738]

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 29]

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 3738]

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 3738]

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 29]

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

[Bikerdude 3738]

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

here yer go fella -

 

bikerdude_dr_files.zip.txt

 

[greebo 29]

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 3738]

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 29]

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 3738]

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

[Spooks 663]

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 29]

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 3738]

Niiiiooooce......!

 

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

[grayman 2849]

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 29]

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 3738]

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

[Fieldmedic 115]

- 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 2849]

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

[greebo 29]

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 2849]

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 3738]

Greebo, you are a little star!

[Bikerdude 3738]

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 3738]

Filed 2 more bugs -

 

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

[Bikerdude 3738]

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