GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Without a minimal working example that can reliabliy recreate that silent crash it'll be pretty much impossible to anything about it.
As for the slowdowns. I'm not familiar with the 3D code, but AFAIK it's not optimized for speed (at all?). On the other hand that means that there's probably lots of possibilities of improvements (for people who know that 3D stuff, i.e. not me).
As for the slowdowns. I'm not familiar with the 3D code, but AFAIK it's not optimized for speed (at all?). On the other hand that means that there's probably lots of possibilities of improvements (for people who know that 3D stuff, i.e. not me).
- Tormentor667
- Posts: 13534
- Joined: Wed Jul 16, 2003 3:52 am
- Contact:
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Well, this is exactly the problem - I can’t recreate it because it happens totally random. I can only explain how I can prevent it from happening.boris wrote:Without a minimal working example that can reliabliy recreate that silent crash it'll be pretty much impossible to anything about it.
For “testing” it, simply get the latest dev version of WolfenDoom Blade of Agony and edit the larger maps in visual mode with things activated. Chances are at 100% that it happens
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
I tried out C3M6_B, C2M0_B, and C3M1_JUAN1, which are the 3 biggest maps by file size, and I can seemingly fly around in them and change sector heights and textures all day long without it crashing.
- Kappes Buur
-
- Posts: 4122
- Joined: Thu Jul 17, 2003 12:19 am
- Graphics Processor: nVidia (Legacy GZDoom)
- Location: British Columbia, Canada
- Contact:
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Ditto for me.boris wrote:I tried out C3M6_B, C2M0_B, and C3M1_JUAN1, which are the 3 biggest maps by file size, and I can seemingly fly around in them and change sector heights and textures all day long without it crashing.
I load the map like so, with WolfenDoom-master from a directory
Spoiler:While my computer is fairly aged, no unforeseen crashes occur. Working in 2D is quite fluid, but in 3D preview it gets choppy. There is little difference when I set the viewdistance to 9000 with the slider in F5 or 20000 in GZBuilder.cfg.
All I can surmise is that something in your computer system is not quite up to snuff.
Either something in hardware, maybe a faulty memory location, or something in software, driver or app, which needs an update.
While you do not get a crash log, perhaps GZBuilder.log could shed some light on what is going on.
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Something else entirely. I'm probably just doing something wrong but the search dialogue in F10 Scripts gives me a (very minor) headache.
This one:
It works just fine for much of what I need but every now and again it vanishes and I can't get it back without closing the scripts editor and re-opening it.
I think it happens when either I press [Enter] after typing in the search term or I pick "Find Usages" (which is what I think [Enter] does anyway). If I do that, search results appear at the bottom of the screen but the Find/Replace dialogue disappears and, as I said, the only way that I have found to get it back is to close and reopen the script editor. The usual hotkeys or menu choices do not bring it back.
If I pick "Find Next" it doesn't happen: the dialogue stays in place and I can continue to use it.
So, am I doing something wrong? Can I get the dialogue back without closing the script editor?
I don't know about anyone else but I need to use "Find Next" (needed it hundreds of times) much more commonly than "Find Usages" (never needed it) so I'm not quite sure why hitting [Enter] defaults to "Find Usages" instead of "Find Next". Every single time I have had the above problem is because I accidentally hit [Enter] to "Find Usages" and then I had to close the script editor and reopen it to hit the button that I actually wanted.
This one:
It works just fine for much of what I need but every now and again it vanishes and I can't get it back without closing the scripts editor and re-opening it.
I think it happens when either I press [Enter] after typing in the search term or I pick "Find Usages" (which is what I think [Enter] does anyway). If I do that, search results appear at the bottom of the screen but the Find/Replace dialogue disappears and, as I said, the only way that I have found to get it back is to close and reopen the script editor. The usual hotkeys or menu choices do not bring it back.
If I pick "Find Next" it doesn't happen: the dialogue stays in place and I can continue to use it.
So, am I doing something wrong? Can I get the dialogue back without closing the script editor?
I don't know about anyone else but I need to use "Find Next" (needed it hundreds of times) much more commonly than "Find Usages" (never needed it) so I'm not quite sure why hitting [Enter] defaults to "Find Usages" instead of "Find Next". Every single time I have had the above problem is because I accidentally hit [Enter] to "Find Usages" and then I had to close the script editor and reopen it to hit the button that I actually wanted.
- Ozymandias81
- Posts: 2063
- Joined: Thu Jul 04, 2013 8:01 am
- Graphics Processor: nVidia with Vulkan support
- Location: Mount Olympus, Mars
- Contact:
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
On BoA usually to force an error occur you must try to modify INTERMAP, it is where I get most of the crashes at least
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Not getting any crashes there, either.Ozymandias81 wrote:On BoA usually to force an error occur you must try to modify INTERMAP, it is where I get most of the crashes at least
- Tormentor667
- Posts: 13534
- Joined: Wed Jul 16, 2003 3:52 am
- Contact:
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Where can I find that?Kappes Buur wrote:While you do not get a crash log, perhaps GZBuilder.log could shed some light on what is going on.
Well, I have the problem on 3 different computers - from lower to higher rigs, with Win 7 and Win 10. Not sure if I have installed something on every computer that makes the problem happen.Kappes Buur wrote:All I can surmise is that something in your computer system is not quite up to snuff.
Either something in hardware, maybe a faulty memory location, or something in software, driver or app, which needs an update.
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
It seems too common for a hardware problem on Torm's PC. He gets it on multiple computers, Ozy gets it, I've had it...
And the common factor of disabling things display hints against it being hardware related too I think.
And the common factor of disabling things display hints against it being hardware related too I think.
- Kappes Buur
-
- Posts: 4122
- Joined: Thu Jul 17, 2003 12:19 am
- Graphics Processor: nVidia (Legacy GZDoom)
- Location: British Columbia, Canada
- Contact:
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
C:\Users\name\AppData\Local\Doom Builder\GZBuilder.logTormentor667 wrote:Where can I find that?Kappes Buur wrote:While you do not get a crash log, perhaps GZBuilder.log could shed some light on what is going on.
My last one, for comparison
Spoiler:
On the other hand, one could make the argument that there are a number of computers, probably the majority, where the editor runs without problems. I run Wadauthor, Deepsea, DB1, DB2, DBX, GZDB, GZDBBF (x64 and x86), Eureka and SlumpED, XWE and Slade3 quite regularly.Enjay wrote:It seems too common for a hardware problem on Torm's PC. He gets it on multiple computers, Ozy gets it, I've had it...
And the common factor of disabling things display hints against it being hardware related too I think.
All I can think of, at the moment, are these steps I take to keep my trusty old computer up to snuff.
I install every editor version manually in a dedicated folder. I never install a new version on top of an old version.
On the software side:
- Let Microsoft install Windows updates automatically.
- Update the video driver every so often, at least so that it does not lag by more than 2 or 3 versions.
- Update all Microsoft Visual C++ Redistributable versions required by the various editors.
- According to Control Panel I have accumulated a number of them from 2005 to 2015-2019, both x86 and x64
- Update Microsoft® .NET Framework as required
- I have a number of them from version 3.0 to 4.7
- Install SlimDX Runtime .NET, I have versions
- .NET 2.0 (January 2012)
- .NET 4.0 x64 (January 2012)
- .NET 4.0 x86 (January 2012)
The more RAM the better. I maxed my motherboard out at 16GB.
I run Memtest 86+ V4.00 every so often during my sleeping time. That ensures that the test goes at least through 4 iterations. Rarely I run it for 2 days non-stop.
- Tormentor667
- Posts: 13534
- Joined: Wed Jul 16, 2003 3:52 am
- Contact:
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
I will post that as soon as the next crash occurs.Kappes Buur wrote:C:\Users\name\AppData\Local\Doom Builder\GZBuilder.log
By the way, getting a new bug when drawing sectors, no idea where this comes from but it happens when drawing a sector at the INTERMAP.WAD (from Blade of Agony); Uploaded the map here, it crashes without using the resources.
Code: Select all
***********SYSTEM INFO***********
OS: Microsoft Windows 10 Enterprise
GPU: Radeon RX 580 Series
GZDB: R3074
Platform: x64
********EXCEPTION DETAILS********
Die angegebene Umwandlung ist ungültig.
bei CodeImp.DoomBuilder.Map.UniValue.ReadWrite(IReadWriteStream s)
bei CodeImp.DoomBuilder.Map.MapElement.ReadWrite(IReadWriteStream s)
bei CodeImp.DoomBuilder.Map.Thing.ReadWrite(IReadWriteStream s)
bei CodeImp.DoomBuilder.Editing.UndoManager.RecPrpThing(Thing t)
bei CodeImp.DoomBuilder.Map.Thing.BeforePropsChange()
bei CodeImp.DoomBuilder.Map.Thing.Move(Vector3D newpos)
bei CodeImp.DoomBuilder.Map.Thing.SnapToAccuracy(Boolean usepreciseposition)
bei CodeImp.DoomBuilder.Map.MapSet.SnapAllToAccuracy(Boolean usepreciseposition)
bei CodeImp.DoomBuilder.BuilderModes.DrawGeometryMode.OnAccept()
bei CodeImp.DoomBuilder.Editing.EditingManager.AcceptMode()
bei CodeImp.DoomBuilder.BuilderModes.DrawGeometryMode.FinishDraw()
bei CodeImp.DoomBuilder.BuilderModes.DrawGeometryMode.DrawPointAt(Vector2D pos, Boolean stitch, Boolean stitchline)
bei CodeImp.DoomBuilder.BuilderModes.DrawGeometryMode.DrawPointAt(DrawnVertex p)
bei CodeImp.DoomBuilder.BuilderModes.DrawGeometryMode.DrawPoint()
bei CodeImp.DoomBuilder.Actions.Action.Begin()
bei CodeImp.DoomBuilder.Actions.ActionManager.BeginActionByKey(Int32 key, Boolean repeated)
bei CodeImp.DoomBuilder.Actions.ActionManager.KeyPressed(Int32 key)
bei CodeImp.DoomBuilder.Windows.MainForm.display_MouseDown(Object sender, MouseEventArgs e)
bei System.Windows.Forms.Control.OnMouseDown(MouseEventArgs e)
bei System.Windows.Forms.Control.WmMouseDown(Message& m, MouseButtons button, Int32 clicks)
bei System.Windows.Forms.Control.WndProc(Message& m)
bei System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Completely different area of the program: ACS compiling.
If there is an error in my script and I press in the F10 editor to compile the script, I hear a noise and the error gets flagged up.
If, however, instead of doing the above, I close the editor and save the map, the compile fails silently and I don't realise there is a problem. So, I go to test my map in GZDoom, find out that nothing has changed and there is a moment of head-scratching to figure out why. If GZDB had beeped at me when saving the map, I wouldn't have wasted my time testing it and would have gone straight back to the script editor to fix things up.
So, is there an option to make compiling failure more obvious when auto-compiling during map saving?
If there is an error in my script and I press in the F10 editor to compile the script, I hear a noise and the error gets flagged up.
If, however, instead of doing the above, I close the editor and save the map, the compile fails silently and I don't realise there is a problem. So, I go to test my map in GZDoom, find out that nothing has changed and there is a moment of head-scratching to figure out why. If GZDB had beeped at me when saving the map, I wouldn't have wasted my time testing it and would have gone straight back to the script editor to fix things up.
So, is there an option to make compiling failure more obvious when auto-compiling during map saving?
- Kappes Buur
-
- Posts: 4122
- Joined: Thu Jul 17, 2003 12:19 am
- Graphics Processor: nVidia (Legacy GZDoom)
- Location: British Columbia, Canada
- Contact:
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
It is most strange that you and Ozymandias81 have problems with modifying INTERMAP.wadTormentor667 wrote: I will post that as soon as the next crash occurs.
By the way, getting a new bug when drawing sectors, no idea where this comes from but it happens when drawing a sector at the INTERMAP.WAD (from Blade of Agony); Uploaded the map here, it crashes without using the resources.
My own experience is that I can modify that map
Spoiler:My GZDBuilder.log
Spoiler:
- Kappes Buur
-
- Posts: 4122
- Joined: Thu Jul 17, 2003 12:19 am
- Graphics Processor: nVidia (Legacy GZDoom)
- Location: British Columbia, Canada
- Contact:
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Where did you configure the editor to auto-compile when saving a map?Enjay wrote: So, is there an option to make compiling failure more obvious when auto-compiling during map saving?
I am not aware of such a feature.
The noise you hear on a script compile error is the Windows sound when an error occurs.
- Tormentor667
- Posts: 13534
- Joined: Wed Jul 16, 2003 3:52 am
- Contact:
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
I was able to fix the problem by simply deleting the .db file and starting over again when opening INTERMAP.WAD - so I guess the file must be corrupted.Kappes Buur wrote:It is most strange that you and Ozymandias81 have problems with modifying INTERMAP.wad
My own experience is that I can modify that map