Jump to content
The Dark Mod Forums
Sign in to follow this  
greebo

DarkRadiant 2.0.4 pre-release testing

Recommended Posts

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

 

edit: done

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 :wacko: )

Edited by Spooks

My FMs: The King of Diamonds (2016)



| Visit my Mapbook thread sometimes! | Read my tutorial on Image-Based Lighting Workflows for TDM! |

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

- 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!

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...