GZDoomBuilder-Bugfix, a maintenance fork of GZDB

[ZZYZX]

As for the current bugs: undo on cancel was done for when these options are enabled:

Currently it doesn't undo at all, even when I just drew a sector using that option, and then hit cancel.

Also, you omitted non-UDMF version of the edit form, it's probably better to change it as well.

[anotak]

As for the current bugs: undo on cancel was done for when these options are enabled:
http://i.imgur.com/Sdh6m9u.png
Currently it doesn't undo at all, even when I just drew a sector using that option, and then hit cancel.

i'm not sure if i understand what you mean here, but i believe i have it fixed in the most recent commits to my branch. i have tried both with the options on and off

Also, you omitted non-UDMF version of the edit form, it's probably better to change it as well.

now i'm really confused? i dont see what i omitted. i fixed the issues on the non-UDMF version as far as i could tell.

optimizing the texture browser looks like a non-trivial task because of how it's architected

What exactly is lagging there?

whenever you open the browser or click between categories a long time is spent populating the list by calling ImageBrowserControl.AddItem
here: https://github.com/jewalky/GZDoom-Build ... ol.cs#L475
i havent been able to fully explore this but i assume instantiating N imagebrowseritems isn't scaling so well, i just dont know enough about the context well enough to know how to use an object pool or caching them somehow

i'm also pretty sick right now so i'm not at 100% brain capacity. so i apologize if my post is bad

[ZZYZX]

i'm not sure if i understand what you mean here, but i believe i have it fixed in the most recent commits to my branch. i have tried both with the options on and off

Nevermind, for whatever reason I thought that sector creation should be reverted if you press cancel after creating and editing a sector.
But that doesn't seem to happen even in old revisions that you did nothing with.

now i'm really confused? i dont see what i omitted. i fixed the issues on the non-UDMF version as far as i could tell.

There is LinedefEditForm.cs and LinedefEditFormUDMF.cs. I might be wrong but your changes only affect the latter. (same for sectors, IIRC, point me at the commit/whatever if this is not true)
(actually after looking at non-UDMF form, I don't think it needs any optimization, since it's like 6 times smaller than UDMF one...)

As for the AddItem in TextureBrowser, will look into it (and look at your recent commit about it too )
edit: Fixed the off gradient in classic view. (here).

Not sure what to do with AddItem for now, as theoretically that one can be cached at least partially (for regular texture icons, not folder icons). Not sure if that's the place that lags though, as it's regular list addition with a bunch of generic type copying in ImageBrowserItem constructor.
The only costly operation there can be the name width calculation, which can probably be moved to rendering stage so that we only calculate widths for items that are actually to be drawn (i.e. rectangle is in viewport).
I don't have any lag as of now, so you'll have to test that.

I'll do some final testing here and merge to master, so that you can continue from it and avoid merge conflicts.
edit2: ok, nothing fatal happens, merged and in R2872.

[ZZYZX]

Recently changed a bit how the info panel (at the bottom of the bottlewindow) is drawn. Not sure if it has any positive or negative impact for people, feedback pls. Especially people with worse CPUs (/me looks at anotak), because as for myself I can already see that nothing changed really.

[Nash]

Am I supposed to see any changes to the info panel in 2.3.0.2883 (db9bb4f)? Looks the same as before to me...

(I hope this GZDB version won't eat my map XD)

[ZZYZX]

It should lag less when switching from one map element to another (like in 3D mode, looking at different walls, looking at ceilings/floors then walls, etc).
Aaaand no, it shouldn't eat your map, in fact a lot of things should be fixed compared to R2866.

[anotak]

now i'm really confused? i dont see what i omitted. i fixed the issues on the non-UDMF version as far as i could tell.

There is LinedefEditForm.cs and LinedefEditFormUDMF.cs. I might be wrong but your changes only affect the latter. (same for sectors, IIRC, point me at the commit/whatever if this is not true)
(actually after looking at non-UDMF form, I don't think it needs any optimization, since it's like 6 times smaller than UDMF one...)

yeah um all the changes are there for both

As for the AddItem in TextureBrowser, will look into it (and look at your recent commit about it too )
edit: Fixed the off gradient in classic view. (here).

oh i wanted to see if there's a way to fix this without new-ing on every draw call because it's a particularly slow operation

Not sure what to do with AddItem for now, as theoretically that one can be cached at least partially (for regular texture icons, not folder icons). Not sure if that's the place that lags though, as it's regular list addition with a bunch of generic type copying in ImageBrowserItem constructor.
The only costly operation there can be the name width calculation, which can probably be moved to rendering stage so that we only calculate widths for items that are actually to be drawn (i.e. rectangle is in viewport).
I don't have any lag as of now, so you'll have to test that.

the lag is somewhere in the callstack from AddItem, it might be the string measuring. The VS profiler isn't giving me debug symbols for calls to system.drawing stuff so it's possible. haven't fully investigated

I'll do some final testing here and merge to master, so that you can continue from it and avoid merge conflicts.
edit2: ok, nothing fatal happens, merged and in R2872.

thx!

Recently changed a bit how the info panel (at the bottom of the bottlewindow) is drawn. Not sure if it has any positive or negative impact for people, feedback pls. Especially people with worse CPUs (/me looks at anotak), because as for myself I can already see that nothing changed really.

erm i tried merging your stuff in and there's a few files (Core/Data/ZScriptHandler.cs and Core/ZDoom/ZScriptParserSE.cs) missing?

now back to coughing up mucus in bed :<

edit: oh i forgot to mention, like, my cpu isn't that slow, i have an i5-3450? i mean we are talking about editing for a game from 1993. for me, responsiveness is very important in tools i use and so i'd much prefer if things react in 1/60th a second or less so when operations take 100ms it is noticeably jarring to me. but i know not everyone is bothered by that kind of thing

[anotak]

ran into something that i thought was a bug with changes i did at first but it turns out it's in older builds too:
if you open ancient aliens (aaliens.wad https://www.doomworld.com/idgames/level ... ds/aaliens ) map14 and start dragging the sector #328 (floor is IRON_06, it's 2 large non connected spots):
1) TraceSector() takes FOREVER
2) sometimes it crashes on
https://github.com/jewalky/GZDoom-Build ... t.cs#L2025
this line right here because l.Start and l.End become null somehow

[ZZYZX]

erm i tried merging your stuff in and there's a few files (Core/Data/ZScriptHandler.cs and Core/ZDoom/ZScriptParserSE.cs) missing?

Oops. Fixed.

edit: oh i forgot to mention, like, my cpu isn't that slow, i have an i5-3450? i mean we are talking about editing for a game from 1993. for me, responsiveness is very important in tools i use and so i'd much prefer if things react in 1/60th a second or less so when operations take 100ms it is noticeably jarring to me. but i know not everyone is bothered by that kind of thing

That's some sharp eye. I can't notice 100ms delay on my i5-6400, for the UI responsiveness lag to be unbearable it has to be GTK-level.

For the bug: will check.

[camaxide]

Poll:
How many people actually use the embedded script editor for editing the WAD? I understand that it's a bit useful, but there's already SLADE and there is already a feature called "open in DB2" in SLADE if you want it to be synchronized.
I want to keep things like MAPINFO editing or external scripts (SCRIPT01, extradata or whatever other directly map-related stuff should be there), but remove DECORATE/ZSCRIPT/SNDINFO/etc editing and displaying from the script editor.
The reasoning for this is because this is not exactly the duty of a map editor to edit resources, and reverse SLADE is a joke, not something to become a reality.
I don't want to support that bloated script editor tbh, it's only distracting from the stuff that's actually restricted and unique to GZDB.

I use F10 (Script Editor) like all the time while I map - since I work directly up againt all the trigger numbers and values changing real-time inside the editor it would be quite a hassle going back into Slade just to script common map-related things like opening doors and pressing switches through script. Mapinfo etc. I always do through Slade ofc. just not the map specific functions which use triggers in the map.

--ok my bad.. I didn't read the following posts before answering the poll... - Thanks a ton for keeping the work on GzDB - I didn't notice this branch until today I was still refreshing the old closed thread

[camaxide]

With this new attenuated lights, I'd love being able to change a normal dynamic light into attenuated light in the editor without all the settings of the light to reset.. this also happens with doors etc.
If two things or functions have the exact same value-properties it would be very nice if they would stick - and not reset. In theory this would mean I could select all dynamic lights in a map and just switch them to attenuated lights and off I would go leaving all the color and intensity settings untouched.. and if as mentioned one should add 50% to them I could just do **1.5? (** does not work at the time.. but ++32 or --32 works - so I'd love if also ** was added - meaning you could select lights with many different intensities - and multiply all of them by said number - divide would not be neccesary since **0.5 would effectively divide..

So summarize:
* I'd like values to not reset when changing thing type, (and same with actions where arguments are the same) - say if I change from door open to door to door raise / or change light into attenuated light
* I'd like ** to work like ++ and -- does in the value boxes

[camaxide]

I get these messages in the new build:

---

GLDEFS warning in "D3.wad\GLDEFS:4", line 8224. DECORATE class "ChargeBall1" does not exist.
GLDEFS warning in "D3.wad\GLDEFS:4", line 8041. DECORATE class "FireBeam" does not exist.

But those seem fine..

in decorate:

ACTOR FireBeam
{
Height 10
Radius 10
etc. etc.

GLDEFS starting from line 8041:

Object FireBeam
{
Frame HK04A { Light FireBeam1 }
Frame HK04B { Light FireBeam2 }
Frame HK04C { Light FireBeam3 }
}

Is this a wrong call from the editor?

[ZZYZX]

Probably a bug. Or not. Are there any other errors regarding DECORATE parsing? (also, give example wad pls)

I'd like ** to work like ++ and -- does in the value boxes

Try to use * or /. "++" and "--" have two characters only to avoid confusion with positive/negative integers.

[camaxide]

Strange.. I tried unloading all except my main wad - and it still gave error, I tried old DB and error came.. then I just resaved the wad in Slade, )it was already saved (no *) and it suddenly gives no error - even when bringing back all wads. So something seemed up.. Lately Slade wont save properly if I have the wad open in Gzdoom builder - before I never had problems with that - and could just save the file then F8 in Gzdb - now I have to close down Gzdb to press save in Slade, then reopen :/

Anyway - about the values. if I select one or more lights, with various values in intensity - and enter *2 and click ok - then intensity drops to 0 - same happens with /2 - so these does not seem to be valid commands?
Any chance btw for the ability to change between things and/or actions without the values (properties) of said thing to reset? writing down the RGB-values and intensity for each light on each level means noting many thousands values - so it would be lovely if this was possible to just change from one to the other without reset

[ZZYZX]

Strange.. I tried unloading all except my main wad - and it still gave error, I tried old DB and error came.. then I just resaved the wad in Slade, )it was already saved (no *) and it suddenly gives no error - even when bringing back all wads. So something seemed up.. Lately Slade wont save properly if I have the wad open in Gzdoom builder - before I never had problems with that - and could just save the file then F8 in Gzdb - now I have to close down Gzdb to press save in Slade, then reopen :/

Does "open map resources in read-only mode" not help? It's a checkbox in the map settings dialog.

writing down the RGB-values and intensity for each light on each level means noting many thousands values - so it would be lovely if this was possible to just change from one to the other without reset

Maybe. I have no idea what causes the reset and there might be already a checkbox like "don't reset thing special on type change".

Anyway - about the values. if I select one or more lights, with various values in intensity - and enter *2 and click ok - then intensity drops to 0 - same happens with /2 - so these does not seem to be valid commands?

Apparently not all fields support this. Will see what can be done there.