Itches, Glitches & Anything Else...

[Fidcal]

Make Hollow not working in V1 64-bit. I never really use it but just saying.

[Fidcal]

Make Room now stopped working. But I've just been using it OK.

 

Battery dead?

[greebo]

Works fine here...

[AluminumHaste]

I'm getting random crashes to desktop when cloning patches. It doesn't always happen either, which is kinda annoying so I have to save before every single clone operation.

 

Also after I create a bevel, I hit Ctrl+S to bring up the Patch Inspector window and everything is greyed out until I deselect the patch and reslect it.

 

[Fidcal]

Confirmed the bevel patch inspector thing. Seems to be a minor bug. Can you add it to tracker if it's not on already?

[AluminumHaste]

I'm cleaning the SVN solution and recompiling, maybe the issue with crashing after cloning patches will go away.

I ran the editor from VS2008, I got this stack error:

 

First-chance exception at 0x000007fefdceaa7d in DarkRadiant.exe: Microsoft C++ exception: boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::bad_lexical_cast> > at memory location 0x0012cbe0..
First-chance exception at 0x000007fefdceaa7d in DarkRadiant.exe: Microsoft C++ exception: selection::algorithm::AmbiguousShaderException at memory location 0x0012cdd8..
First-chance exception at 0x000007fefdceaa7d in DarkRadiant.exe: Microsoft C++ exception: boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::bad_lexical_cast> > at memory location 0x0012cbe0..
First-chance exception at 0x000007fefdceaa7d in DarkRadiant.exe: Microsoft C++ exception: selection::algorithm::AmbiguousShaderException at memory location 0x0012cdd8..
The thread 'Win64 Thread' (0x770) has exited with code 0 (0x0).
First-chance exception at 0x00000001401188f6 in DarkRadiant.exe: 0xC0000005: Access violation reading location 0xffffffffffffffff.

STATUS_STACK_BUFFER_OVERRUN encountered
DarkRadiant.exe has triggered a breakpoint
The thread 'Win64 Thread' (0xf80) has exited with code -1073740791 (0xc0000409).
The thread 'Win64 Thread' (0xb2c) has exited with code -1073740791 (0xc0000409).
The thread 'Win64 Thread' (0xcc8) has exited with code -1073740791 (0xc0000409).
The thread 'Win64 Thread' (0x84c) has exited with code -1073740791 (0xc0000409).
The thread 'Win64 Thread' (0xb9c) has exited with code -1073740791 (0xc0000409).
The thread 'Main Thread' (0xd60) has exited with code -1073740791 (0xc0000409).
The program '[1612] DarkRadiant.exe: Native' has exited with code -1073740791 (0xc0000409).

 

EDIT: I tried debug mode, just got this that's different:

 

Unhandled exception at 0x00000001401188f6 in DarkRadiant.exe: 0xC0000005: Access violation reading location 0xffffffffffffffff.
First-chance exception at 0x00000001401188f6 in DarkRadiant.exe: 0xC0000005: Access violation reading location 0xffffffffffffffff.

[Mortem Desino]

Yeah, I've been getting crash-to-desktops when I clone patches as well. It seems to be sporadic: I can only reproduce it in 50% of the processes (sometimes it will definately crash, other times it won't.

[AluminumHaste]

Tracked both bugs:

 

http://bugs.angua.at/view.php?id=1987 - Patch Inspector properties greyed out

http://bugs.angua.at/view.php?id=1986 - Random crashes when cloning patches

[SneaksieDave]

Interesting, because there's an implicit deselect when cloning. And I've been getting unpredictable crashes when deselecting patches.

[AluminumHaste]

Interesting, because there's an implicit deselect when cloning. And I've been getting unpredictable crashes when deselecting patches.

 

Looks like Greebo fixed the random crash bug when cloning patches, at least it's marked as resolved.

EDIT: And the other bug report is also fixed.

 

Either recompile or wait for the snapshot builds.

[Fidcal]

May be a glitch with setting mod fs game in prefs. I kept setting it but on exit and relaunch it was gone. Yet I remembered doing it yesterday successfully. Then I set it, OK, then I checked back in prefs before exiting. It was still there. Exit, relaunch. Now it's there OK. But I'm wondering if it will 'stick' because I haven't changed it since yesterday when it worked.

 

I can get round it with a custom shortcut but I have several of those for FMs I'm working on regularly but temporary ones I don't bother.

[Fidcal]

No, it disappeared again after one short session. Now it won't even 'stick' at all. If I enter 'patently_dangerous' then click OK. Then go back to prefs - it's gone. I'll add this to tracker if someone can confirm.

 

btw this is V1 64-bit but the version just before the release.

[greebo]

@OrbWeaver: LordSavage is asking for the .deb package for Linux. I'm still not able to do that on my own - would you be willing to take care of this?

[greebo]

So I gather this is a "no"?

 

Not much of a problem though, I was meaning to set up Ubuntu 9.10 anyway this weekend. I've got the Karmic 64 DVD ISO downloaded already.

[Fidcal]

DR 1.0 64 bit. Imported startmap and tried to move it but there's a lot of debris left behind and some of it seems scattered and moves in other ways. I think this might be known but thought I'd just post it. How did Goldchocobo merge his maps together I wonder? Maybe they didn't need moving.

 

[greebo]

DR 1.0 64 bit. Imported startmap and tried to move it but there's a lot of debris left behind and some of it seems scattered and moves in other ways. I think this might be known but thought I'd just post it. How did Goldchocobo merge his maps together I wonder? Maybe they didn't need moving.

This sounds like an issue I fixed already - I just tried to import startmap.map and move the stuff around right after import (when it's still highlighted), everything went along.

[Fidcal]

I'm just too lazy to update. Also I need to look up that fix for disabling text input on target and others; it hangs badly. I think I had to do a clean install sometime and lost that. It seems to me a lot of people won't know about that. Still, nobody's complaining.

[greebo]

Most maps out there are probably small and people won't notice - but I'll fix that issue eventually.

[Fidcal]

At some stage recently the colors in grid view have changed I think in my install. So I'm seeing AI, moveables, and the selected item, all the same bright red. So I cannot tell which item is selected (see image.) How do I change the color of the AI and the moveables? Done this before long ago but don't know where to start looking.

 

[greebo]

The entity colour is defined by the "editor_color" spawnargs in the def files. And there's one "Entity (default)" colour setting in the Colour Scheme Editor.

[Fidcal]

The entity colour is defined by the "editor_color" spawnargs in the def files. And there's one "Entity (default)" colour setting in the Colour Scheme Editor.

Thanks. Maybe a glitch but unsure if it's local to my setup. An internal search for editor_color through all the def folder finds none of the ai def files listed except the rat and steambot lantern. So I'd expect most AI to be the default. In my color scheme I have magenta set for default entities. The other color schemes have a bright orange which may be what I'm seeing in grid view. If I change that in say the default color scheme it has no effect on the AI color so that must be defined elsewhere but I can't find it.

 

Similarly, the moveable barrel is also this bright orange. No editor_color set in its def or where it inherited from.

 

If I change the 'selected brush' it has no effect on the color of the selected brush which remains bright orange.

 

Anybody else seeing the above?

[greebo]

For some colours you'll need to restart the editor, at least for the "selected brush" one, iirc.

[Fidcal]

OK, as a workaround I can change to bright yellow for the selector (btw that 'selected brush' should read 'selection' or 'selected item' as it seems to affect everything. But it is still strange that I can't find the editor_color for AI and moveable barrels (or even why moveable barrels are so special. )

[greebo]

The moveable barrel inherits from "moveable_base_barrel" which defines an editor_color of "1 0.5 0". I guess this is a vanilla D3 entityDef.

[Fidcal]

What do think, is it a good idea to set it in our own moveable barrel to override that? For instance to be like other moveables? Then only AI are bright red orange. I'd rather tone that down so our default bright red orange (slightly different shade I think) does not confuse. Can anyone else spot the selected item in my screenshot?