GZDoomBuilder-Bugfix, a maintenance fork of GZDB

[Enjay]

(perhaps it should be a Notepad++ plugin?)

Something like that would make sense. Lots of people who are serious about text editing use Notepad++. I have it and sometimes use it but I prefer (mostly out of habit and familiarity) Textpad. (I'm not suggesting that you should make a plugin for that - indeed, I don't even think that there is a plugin system for it beyond custom syntax highlighting schemes.)

[Akira_98]

I don't really have a horse in this particular race, so take what I say with a grain of salt, but I could see how that feature could be useful to people working on larger-scale mods. Say you're doing 20 small tweaks and minor additions while working on a map. It's just a bit of extra time and effort saved, which could add up over the course of multiple maps. It's not so much that they belong in a map editor, and they certainly don't need to be there (and arguably if you need it, you're doing something weird), but I could see the benefit they provide to a specific kind of user.

Of course, I may be arguing for a side that doesn't exist at all. I haven't seen a lot of defense for it in this thread at least, but it's not really a wide distribution of users either.

[ZZYZX]

In case someone wants this new script editor to stay in it's full and complete form, and knows C# — they can volunteer for maintaining it
The poll will be open for 7 days regardless of the ratio between ok and not ok, so there's still a chance.

[Danfun64]

For the record, I voted "No" on "Remove unrelated lump editing from GZDB Script editor?". Even if it's "unrelated lump editing" for 99% of the user base, there will still be that 1% who is (for example) forking GZDoom for their own needs and likes the convenience of how things are set up here.

...unless there is way for GZDB to access gzdoom.pk3 directly.....then yes, get rid of it.....

...why isn't "it depends" an option on that poll?

[ZZYZX]

If you fork GZDoom for your own needs, you can't easily add a script type to the editor.
Currently, only the script types that are added and parsed are available for editing.
And adding a type is a major PIA, especially icons, because existing icons are embedded in the resource and for whatever reason Visual Studio hasn't had a way to extract an icon from a compiled resource (only add and delete) for decades.
Overall; I'm not removing the functionality altogether, but rather hiding the various script files and stopping to support their editing (except MAPINFO). So if someone forks GZDoom, adds some special lumps (say new fancy per-map scripting language), they can then also fork GZDB, add a script type and a dummy loader for it, and have it working.

...why isn't "it depends" an option on that poll?

Because I need a 100% yes or no as the result of the poll? Not "maybe". "Maybe" is what I have already.

[Rachael]

My guess is he just doesn't want to repeat what happened to MaxED with an unpopular choice that would have a lot of backlash.

[ZZYZX]

And yes, essentially, I want an actual feedback from the users before removing something large.

[NGX]

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'm inclined to agree that this argument makes sense, unfortunately; I say unfortunately because as a user I would dig to have "everything" in one place, but as you say, as a developer it is likely indeed distracting from actual mapping-related improvements. If somebody else would care to tag along in the GZDB development and handle this department of things then that'd be wonderful though, ofcourse.

I've never used GZDB for any "coding" besides map-related scripting, and frankly I didn't even know it existed.

Map-related scripting (the "F10 menu") definitely has to stay and I hope there's never a question to remove that --- probably a silly "concern" on my part

Keep on truckin'!!

[Kappes Buur]

While I use Slade3 regularly for editing of resource wads/lumps, I rarely use it for scripting because it gives me grief with compiling. Sometimes the script will compile, mostly it won't.

MaxED's support for ACS and DECORATE is perfect for me. So, yes I use the GZDB text editor extensively.
The only thing I do not like is the automatic inclusion of opening and closing braces, that's a bloody nuisance.

However, if there were a Notepad++ like plugin, that would be a good compromise.

Side Note:
While you are at it, you should give your style editor a new name, it is not GZDoom Builder anymore and it is not a Bugfix thereof. Your editor plays havoc with the cfg file generated by GZDB r2787.

[Gez]

I'm sorry that you had troubles with SLADE's DECORATE compiler.

[ZZYZX]

MaxED's support for ACS and DECORATE is perfect for me. So, yes I use the GZDB text editor extensively.
The only thing I do not like is the automatic inclusion of opening and closing braces, that's a bloody nuisance.

Pretty sure you can disable that in the settings: Script editor tab, "Auto close brackets".
Also, what exactly errors are there when it "doesn't compile" in SLADE? Maybe you should point it to the right compiler? I pointed SLADE to the ZDoom acc.exe included with GZDB, and it works just fine.

While you are at it, you should give your style editor a new name, it is not GZDoom Builder anymore and it is not a Bugfix thereof. Your editor plays havoc with the cfg file generated by GZDB r2787.

Sure, what name? Suggestions. I have none
Looking back at Zandronum, making up a new name just so that it doesn't look like the old one is a difficult task. And the resulting name won't make any sense, too.
Point being that it's still a Doom Builder 2 fork, and it's main goal is still to support bleeding edge GZDoom features. I've added two major GZDoom things already. Yea it definitely should be called MeowsaurEditor.
Also, what happens to the config though?

[Nash]

Your editor plays havoc with the cfg file generated by GZDB r2787.

Can you give more detail? I've been using GZDBBF with GZDB's config (it's the same machine after all) and everything seems to work normally on my side...

[Rachael]

MeowsaurEditor.

Good enough name for me.

[ZZYZX]

Besides, I am fixing GZDB bugs.
Hence "Bugfix" is perfectly legit too.

[Kappes Buur]

Your editor plays havoc with the cfg file generated by GZDB r2787.

Can you give more detail? I've been using GZDBBF with GZDB's config (it's the same machine after all) and everything seems to work normally on my side...

That's just it.
Both editors overwrite the GZBuilder.cfg file.