Page 57 of 97

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Posted: Sat May 26, 2018 12:07 am
by Bauul
The error with the bundled ACC compiler not being able to find #zcommon.acs happened to me today too. Replacing it with the official one fixed the problem.

Whatever version of ACC is currently included with R3018 is definitely broken.

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Posted: Sat May 26, 2018 3:53 pm
by Xabis
It should probably be rolled back if is different than the latest version on the official github, imo.

Not going to lie, seems kind of sketch that "some guy" gave him an "updated" version, if you ask me.

Either way... something should be done, because this has been broken officially for a few weeks now, so if anyone upgrades gzdbbf they will be broken right now.

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Posted: Sat May 26, 2018 11:57 pm
by ZZYZX
Actually I did build it locally myself from rheit/acc github because he (some guy) told me that the version downloadable at ZDoom website is not the latest-latest one and may not work with newest features needed.
Either way reverted, hope it will work better now.

Also: note that when I say "some guy" I don't mean total random out there, I mean someone like Nash or even Rachael. I don't remember who requested the last ACS update on Discord, that's all :Р
Was updated as part of https://github.com/jewalky/GZDoom-Build ... issues/195

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Posted: Sun May 27, 2018 4:14 am
by Tormentor667
Something I wanted to say for a while already: ZZYZX, thanks for keeping this up to date, I am very glad that GZDoomBuilder is still being maintained after being dropped by the original programmer.

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Posted: Sun May 27, 2018 5:44 am
by Nash
ZZYZX wrote: Also: note that when I say "some guy" I don't mean total random out there, I mean someone like Nash or even Rachael.
Definitely wasn't me! I only bug you when the engine is updated to add something that the editor needs to support! ;)

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Posted: Sun May 27, 2018 6:25 pm
by Xabis
Tormentor667 wrote:Something I wanted to say for a while already: ZZYZX, thanks for keeping this up to date, I am very glad that GZDoomBuilder is still being maintained after being dropped by the original programmer.
Same~ your efforts are appreciated, ZZYZX.

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Posted: Sat Jun 02, 2018 11:49 am
by skornedemon
This version of GZDoomBuilder seems to crash in visual mode when viewing models(could be high poly models only?)

The models render on the overhead view(least their outlines) perhaps if the model doesn't have a texture assigned it freaks out? In the 2017 version, there was a 64x64
untextured-texture for things untextured in gzdoombuilder, is that still the case?

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Posted: Sat Jun 02, 2018 1:16 pm
by ZZYZX
Example wad please

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Posted: Mon Jun 04, 2018 2:22 am
by Kagur
I made some low poly volcanic props in blender for an inferno map I was going to make in Gzdoom builder but I got this when I loaded it and tried to work with the exported obj file in GZDoom builder.

***********SYSTEM INFO***********
OS: Microsoft Windows 7 Professional
GPU: NVIDIA GeForce GT 525M
GZDB: R2787

********EXCEPTION DETAILS********
Value cannot be null.
Parameter name: key
at System.ThrowHelper.ThrowArgumentNullException(ExceptionArgument argument)
at System.Collections.Generic.Dictionary`2.FindEntry(TKey key)
at CodeImp.DoomBuilder.Geometry.Triangulation.FindRightMostVertex(Dictionary`2 sides, Dictionary`2 ignores) in x:\Source\Core\Geometry\Triangulation.cs:line 380
at CodeImp.DoomBuilder.Geometry.Triangulation.DoTrace(Sector s) in x:\Source\Core\Geometry\Triangulation.cs:line 235
at CodeImp.DoomBuilder.Geometry.Triangulation.Triangulate(Sector s) in x:\Source\Core\Geometry\Triangulation.cs:line 128
at CodeImp.DoomBuilder.Map.Sector.Triangulate() in x:\Source\Core\Map\Sector.cs:line 360
at CodeImp.DoomBuilder.Map.MapSet.Update(Boolean dolines, Boolean dosectors) in x:\Source\Core\Map\MapSet.cs:line 1031
at CodeImp.DoomBuilder.BuilderModes.EditSelectionMode.OnAccept() in x:\Source\Plugins\BuilderModes\ClassicModes\EditSelectionMode.cs:line 1573
at CodeImp.DoomBuilder.Editing.EditingManager.AcceptMode() in x:\Source\Core\Editing\EditingManager.cs:line 447
at CodeImp.DoomBuilder.BuilderModes.EditSelectionMode.OnDisengage() in x:\Source\Plugins\BuilderModes\ClassicModes\EditSelectionMode.cs:line 1762
at CodeImp.DoomBuilder.Editing.EditingManager.ChangeMode(EditMode nextmode) in x:\Source\Core\Editing\EditingManager.cs:line 355
at CodeImp.DoomBuilder.Editing.EditModeInfo.UserSwitchToMode() in x:\Source\Core\Editing\EditModeInfo.cs:line 166
at CodeImp.DoomBuilder.Actions.Action.Begin() in x:\Source\Core\Actions\Action.cs:line 256
at CodeImp.DoomBuilder.Actions.ActionManager.BeginActionByKey(Int32 key, Boolean repeated) in x:\Source\Core\Actions\ActionManager.cs:line 557
at CodeImp.DoomBuilder.Actions.ActionManager.KeyPressed(Int32 key) in x:\Source\Core\Actions\ActionManager.cs:line 496
at CodeImp.DoomBuilder.Windows.MainForm.MainForm_KeyDown(Object sender, KeyEventArgs e) in x:\Source\Core\Windows\MainForm.cs:line 1378
at System.Windows.Forms.Control.OnKeyDown(KeyEventArgs e)
at System.Windows.Forms.Control.ProcessKeyEventArgs(Message& m)
at System.Windows.Forms.Control.ProcessKeyMessage(Message& m)
at System.Windows.Forms.Control.WmKeyChar(Message& m)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.ScrollableControl.WndProc(Message& m)
at System.Windows.Forms.ContainerControl.WndProc(Message& m)
at System.Windows.Forms.Form.WndProc(Message& m)
at CodeImp.DoomBuilder.Windows.MainForm.WndProc(Message& m) in x:\Source\Core\Windows\MainForm.cs:line 4091
at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)


The obj file is right here:

https://1drv.ms/u/s!AtUwonlWFY1HhiKlE1Wa58dtnmiY

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Posted: Thu Jun 07, 2018 1:41 pm
by Kappes Buur
Feature Request:
Right now up to 3 backup files are made. Could this be extended to 5 or more?
Or perhaps a slider akin to Max. Recent Files up to 20.

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Posted: Thu Jun 07, 2018 1:53 pm
by anotak
hey, so i've noticed a bit of an issue internal to the codebase of DB2-based editors, that we should probably agree on a way to fix for plugin makers.
There isn't a way to set the values of Linedef.Args and create an undo snapshot from outside internal scope (BeforePropsChange() is never called). This currently does not cause any bugs that I'm aware of, because every instance right now of changing args also involves changing other details about the linedef. but it may lead to future bugs.

right now, I'm writing a plugin, and obviously I'd like to support both DBX and GZDB-BF if possible. because of this issue, if my plugin only changes linedef args, no undo snapshot is created for those lines, and it cannot be undone.

there are some hacky workarounds I could do, like using Linedef.Update() or just saying Linedef.Tag = Linedef.Tag, but these are not ideal.

so I'd like your thoughts on some kind of method we could add to Linedef in both DBX & GZDB-BF perhaps, like say something like:

Code: Select all

public void SetArg(int index, int new_value)
{
       if(index < 0 || index >= NUM_ARGS)
       {
              return;
       }
       BeforePropsChange();
       args[index] = new_value;
}
(note: i havent actually compiled that code or anything, just sketching right now)

edit: there's not a way to use a C# indexer for this, is there?

edit2: at least on my end, i will be placing a comment in the Linedef source before the definition of the Args property warning people to not do Args[index] = value; to set args if they want to create an undo snapshot for the linedef

edit3:
hmm, i'm also finding that my plugin will be needing access to changing the grid size probably, but as you can see, that in GridSetup all the ways to change the size are marked as internal. We could expose some of those as public, perhaps?

edit4:
so, the same problem appears to be the case with Thing's args as with Linedef

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Posted: Mon Jun 11, 2018 2:21 pm
by anotak
hey, so, look, i don't mean to rush you, but if you're interested in that at all, could i at least get a "hey, i saw your post, we can do something like that, kind of busy right now, can't respond", post?
i see you've logged in recently

it'd be a lot easier on me and a lot less work for me to not maintain compatibility with my new plugin! but i think both our editors have a niche for people to use and we can coexist and cooperate some, if you're willing. so, so far i've been putting in the work for it to try to be easy for you to support my plugin

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Posted: Tue Jun 12, 2018 6:13 am
by ZZYZX
Hey, I saw your post, but don't understand how this part (undo/redo) of GZDB/DB2 works (I don't even understand what's the issue, wtf is BeforePropsChange?) and thus don't currently have enough time nor interest to implement it.
Note though that it's not like I don't understand it due to completely alien concept, but more like I haven't ever had a reason to look into it.
Maybe on the weekend and if I get a working example of how it works in DBX. Actually, if I get a working example of how it works in DBX there are way higher chances of it happening.

I don't have anything against the idea of plugin compatibility. (if that even exists already, don't DB2 and GZDB have too much differences?)

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Posted: Tue Jun 12, 2018 10:19 am
by TwoDubyaz
Can't run the new releases with .NET 4.6.1 (fresh Windows 10 install/64bit) and now windows won't allow installing any 4.6.x. Previously was running r3018 fine but reinstalled windows and lost all my old .NET frameworks. Have r2993 and DB2 2.1.2.1553 working here if it means anything.

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Posted: Tue Jun 12, 2018 1:28 pm
by anotak
ZZYZX wrote:Hey, I saw your post, but don't understand how this part (undo/redo) of GZDB/DB2 works (I don't even understand what's the issue, wtf is BeforePropsChange?) and thus don't currently have enough time nor interest to implement it.
Note though that it's not like I don't understand it due to completely alien concept, but more like I haven't ever had a reason to look into it.
Maybe on the weekend and if I get a working example of how it works in DBX. Actually, if I get a working example of how it works in DBX there are way higher chances of it happening.

I don't have anything against the idea of plugin compatibility. (if that even exists already, don't DB2 and GZDB have too much differences?)
oh, compatibilty exists mostly, as long as the same method calls & properties are available with the same call signatures. I had to add a few method calls to DBX, to support the sound propagation and sound environment and automap plugins in DBX, but they do work, mostly the same now. I didn't implement some of the GZDB features like reading LOCKDEFS, i just hardcoded it, but otherwise it's the same.

ok so what i was saying is:
https://github.com/jewalky/GZDoom-Build ... def.cs#L91
BeforePropsChange() is called here for example, when you change actions, or other various features of Linedefs and other MapElements

BeforePropsChange() itself sets up the undo for the Linedef (and as you can see, is marked protected)
https://github.com/jewalky/GZDoom-Build ... ef.cs#L186

but you see, there is no set { } with BeforePropsChange() for Linedef.Args or Thing.Args
https://github.com/jewalky/GZDoom-Build ... ef.cs#L102
now, it might seem like this is not a problem, because there is no set {} at all, but with just a get {}, you can do

some_linedef.Args[0] = some_value;

and this is done in many places in the db** code, because there is no other public way to set the args at all.

this isn't a problem if you do anything else that calls BeforePropsChange() within the same undo snapshot, which is why nothing bad has happened for now.

this code is all the same in DBX and GZDB-BF.

my hacky workaround in my plugin does this:

Code: Select all

thing.Tag = thing.Tag;
thing.Args[0] = value;
or like here:
https://github.com/anotak/doombuilderx/ ... ef.cs#L188

if i did not do this, and someone only changed the Args, then the person will not be able to undo changing Args.
i guess my workaround works, just my larger concern is that this issue will stick around and someone else will trip over it writing a plugin because there is no warning that this can happen in the code itself.