Page 78 of 97

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

PostPosted: Fri Aug 09, 2019 5:23 am
by boris
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).

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

PostPosted: Fri Aug 09, 2019 7:31 am
by Tormentor667
boris wrote:Without a minimal working example that can reliabliy recreate that silent crash it'll be pretty much impossible to anything about it.

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.

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

PostPosted: Fri Aug 09, 2019 10:13 am
by boris
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.

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

PostPosted: Fri Aug 09, 2019 10:40 am
by Kappes Buur
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.


Ditto for me.

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

PostPosted: Fri Aug 09, 2019 11:31 am
by Enjay
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:

Image

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.

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

PostPosted: Fri Aug 09, 2019 2:55 pm
by Ozymandias81
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

PostPosted: Sat Aug 10, 2019 2:45 am
by boris
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

Not getting any crashes there, either.

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

PostPosted: Sat Aug 10, 2019 3:05 am
by Tormentor667
Kappes Buur wrote:While you do not get a crash log, perhaps GZBuilder.log could shed some light on what is going on.

Where can I find that?

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.

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.

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

PostPosted: Sat Aug 10, 2019 3:39 am
by Enjay
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.

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

PostPosted: Sat Aug 10, 2019 6:36 am
by Kappes Buur
Tormentor667 wrote:
Kappes Buur wrote:While you do not get a crash log, perhaps GZBuilder.log could shed some light on what is going on.

Where can I find that?


C:\Users\name\AppData\Local\Doom Builder\GZBuilder.log

My last one, for comparison
Spoiler:


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.


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.

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)

On the hardware side:
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.

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

PostPosted: Sun Aug 11, 2019 4:34 am
by Tormentor667
Kappes Buur wrote:C:\Users\name\AppData\Local\Doom Builder\GZBuilder.log

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.
Code: Select allExpand view
***********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

PostPosted: Sun Aug 11, 2019 8:12 am
by Enjay
Completely different area of the program: ACS compiling.

If there is an error in my script and I press Image 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?

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

PostPosted: Sun Aug 11, 2019 8:22 am
by Kappes Buur
Tormentor667 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.


It is most strange that you and Ozymandias81 have problems with modifying INTERMAP.wad
My own experience is that I can modify that map

Spoiler:


My GZDBuilder.log
Spoiler:

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

PostPosted: Sun Aug 11, 2019 8:48 am
by Kappes Buur
Enjay wrote:So, is there an option to make compiling failure more obvious when auto-compiling during map saving?

Where did you configure the editor to auto-compile when saving a map?
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.

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

PostPosted: Sun Aug 11, 2019 8:52 am
by Tormentor667
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

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.