GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Projects that have specifically been abandoned or considered "dead" get moved here, so people will quit bumping them. If your project has wound up here and it should not be, contact a moderator to have it moved back to the land of the living.
Locked
Bauul
Posts: 78
Joined: Mon Aug 29, 2016 4:23 pm

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post 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.
Xabis
Posts: 63
Joined: Wed Mar 06, 2013 7:15 pm

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post 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.
User avatar
ZZYZX
 
 
Posts: 1384
Joined: Sun Oct 14, 2012 1:43 am
Location: Ukraine
Contact:

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post 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
User avatar
Tormentor667
Posts: 13530
Joined: Wed Jul 16, 2003 3:52 am
Contact:

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post 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.
User avatar
Nash
 
 
Posts: 17433
Joined: Mon Oct 27, 2003 12:07 am
Location: Kuala Lumpur, Malaysia
Contact:

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post 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! ;)
Xabis
Posts: 63
Joined: Wed Mar 06, 2013 7:15 pm

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post 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.
skornedemon
Posts: 154
Joined: Mon Aug 02, 2010 11:10 am

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post 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?
User avatar
ZZYZX
 
 
Posts: 1384
Joined: Sun Oct 14, 2012 1:43 am
Location: Ukraine
Contact:

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by ZZYZX »

Example wad please
Kagur
Posts: 161
Joined: Fri Mar 14, 2014 12:40 am

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post 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
User avatar
Kappes Buur
 
 
Posts: 4114
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

Post 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.
anotak
Posts: 43
Joined: Tue Dec 06, 2016 6:16 am

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post 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
anotak
Posts: 43
Joined: Tue Dec 06, 2016 6:16 am

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post 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
User avatar
ZZYZX
 
 
Posts: 1384
Joined: Sun Oct 14, 2012 1:43 am
Location: Ukraine
Contact:

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post 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?)
TwoDubyaz
Posts: 2
Joined: Tue Jun 12, 2018 9:57 am

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post 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.
anotak
Posts: 43
Joined: Tue Dec 06, 2016 6:16 am

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post 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.
Locked

Return to “Abandoned/Dead Projects”