greebo 29 Posted March 10, 2016 Author Report Share Posted March 10, 2016 Oh, appears like dramthethief.com is dead. I'll upload it to somewhere else. edit: done Quote Link to post Share on other sites
Bikerdude 3740 Posted March 10, 2016 Report Share Posted March 10, 2016 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. Quote Link to post Share on other sites
greebo 29 Posted March 10, 2016 Author Report Share Posted March 10, 2016 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. Quote Link to post Share on other sites
Bikerdude 3740 Posted March 10, 2016 Report Share Posted March 10, 2016 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. Quote Link to post Share on other sites
Bikerdude 3740 Posted March 10, 2016 Report Share Posted March 10, 2016 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. Quote Link to post Share on other sites
greebo 29 Posted March 12, 2016 Author Report Share Posted March 12, 2016 Can I have copy of your settings xml files, please? Quote Link to post Share on other sites
Bikerdude 3740 Posted March 12, 2016 Report Share Posted March 12, 2016 Can I have copy of your settings xml files, please?here yer go fella - bikerdude_dr_files.zip.txt Quote Link to post Share on other sites
greebo 29 Posted March 12, 2016 Author Report Share Posted March 12, 2016 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? Quote Link to post Share on other sites
Bikerdude 3740 Posted March 12, 2016 Report Share Posted March 12, 2016 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 Quote Link to post Share on other sites
greebo 29 Posted March 12, 2016 Author Report Share Posted March 12, 2016 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. Quote Link to post Share on other sites
Bikerdude 3740 Posted March 12, 2016 Report Share Posted March 12, 2016 Thanks fella, I very much appreciate you looking into this. Quote Link to post Share on other sites
Spooks 673 Posted March 22, 2016 Report Share Posted March 22, 2016 (edited) 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 Quote My FMs: The King of Diamonds (2016) | Visit my Mapbook thread sometimes! | Read my tutorial on Image-Based Lighting Workflows for TDM! Link to post Share on other sites
greebo 29 Posted April 20, 2016 Author Report Share Posted April 20, 2016 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. Quote Link to post Share on other sites
Bikerdude 3740 Posted April 20, 2016 Report Share Posted April 20, 2016 Niiiiooooce......! The escape related crashing was starting to get on my proverbial nerve. Quote Link to post Share on other sites
grayman 2960 Posted April 21, 2016 Report Share Posted April 21, 2016 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. Quote Link to post Share on other sites
greebo 29 Posted April 21, 2016 Author Report Share Posted April 21, 2016 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. Quote Link to post Share on other sites
Bikerdude 3740 Posted April 21, 2016 Report Share Posted April 21, 2016 Well so far no escape based crashing! and even got Sotha using this build.. Quote Link to post Share on other sites
Fieldmedic 150 Posted April 23, 2016 Report Share Posted April 23, 2016 - 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! Quote Link to post Share on other sites
grayman 2960 Posted April 23, 2016 Report Share Posted April 23, 2016 I've been using the latest build w/no problems (though avoiding the 90 degree rotation buttons). Quote Link to post Share on other sites
greebo 29 Posted April 23, 2016 Author Report Share Posted April 23, 2016 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. Quote Link to post Share on other sites
grayman 2960 Posted April 23, 2016 Report Share Posted April 23, 2016 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. Quote Link to post Share on other sites
Bikerdude 3740 Posted April 23, 2016 Report Share Posted April 23, 2016 Greebo, you are a little star! Quote Link to post Share on other sites
Bikerdude 3740 Posted April 24, 2016 Report Share Posted April 24, 2016 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. Quote Link to post Share on other sites
Bikerdude 3740 Posted April 24, 2016 Report Share Posted April 24, 2016 Filed 2 more bugs - http://bugs.thedarkmod.com/view.php?id=4307http://bugs.thedarkmod.com/view.php?id=4308 Quote Link to post Share on other sites
Bikerdude 3740 Posted April 26, 2016 Report Share Posted April 26, 2016 Logged another bug - http://bugs.thedarkmod.com/view.php?id=4309Any idea on this old bug? - http://bugs.thedarkmod.com/view.php?id=4276 Quote Link to post Share on other sites
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.