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.)ZZYZX wrote:(perhaps it should be a Notepad++ plugin?)
GZDoomBuilder-Bugfix, a maintenance fork of GZDB
-
-
- Posts: 26564
- Joined: Tue Jul 15, 2003 4:58 pm
- Location: Scotland
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
-
- Posts: 213
- Joined: Sun Jun 27, 2010 2:45 pm
- Location: AC District 7
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
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.
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.
-
-
- Posts: 1384
- Joined: Sun Oct 14, 2012 1:43 am
- Location: Ukraine
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
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.
The poll will be open for 7 days regardless of the ratio between ok and not ok, so there's still a chance.
-
- Posts: 93
- Joined: Tue Apr 23, 2013 4:33 pm
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
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?
...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?
-
-
- Posts: 1384
- Joined: Sun Oct 14, 2012 1:43 am
- Location: Ukraine
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
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.
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.
Because I need a 100% yes or no as the result of the poll? Not "maybe". "Maybe" is what I have already.Danfun64 wrote:...why isn't "it depends" an option on that poll?
Last edited by ZZYZX on Fri Jan 20, 2017 1:41 pm, edited 3 times in total.
-
- Posts: 13783
- Joined: Tue Jan 13, 2004 1:31 pm
- Preferred Pronouns: She/Her
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
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.
-
-
- Posts: 1384
- Joined: Sun Oct 14, 2012 1:43 am
- Location: Ukraine
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
And yes, essentially, I want an actual feedback from the users before removing something large.
-
- Posts: 123
- Joined: Sat Jun 14, 2014 12:17 pm
Re: GZDoomBuilder-Bugfix, a maintenance fork of 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.ZZYZX wrote: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'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'!!
-
-
- Posts: 4149
- Joined: Thu Jul 17, 2003 12:19 am
- Graphics Processor: nVidia (Legacy GZDoom)
- Location: British Columbia, Canada
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
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.
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.
Last edited by Kappes Buur on Fri Jan 20, 2017 5:06 pm, edited 1 time in total.
-
-
- Posts: 17933
- Joined: Fri Jul 06, 2007 3:22 pm
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
I'm sorry that you had troubles with SLADE's DECORATE compiler.
-
-
- Posts: 1384
- Joined: Sun Oct 14, 2012 1:43 am
- Location: Ukraine
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Pretty sure you can disable that in the settings: Script editor tab, "Auto close brackets".Kappes Buur wrote: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.
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.
Sure, what name? Suggestions. I have noneKappes Buur wrote: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.
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?
Last edited by ZZYZX on Fri Jan 20, 2017 6:28 pm, edited 1 time in total.
-
-
- Posts: 17465
- Joined: Mon Oct 27, 2003 12:07 am
- Location: Kuala Lumpur, Malaysia
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
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...Kappes Buur wrote:Your editor plays havoc with the cfg file generated by GZDB r2787.
-
- Posts: 13783
- Joined: Tue Jan 13, 2004 1:31 pm
- Preferred Pronouns: She/Her
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Good enough name for me.ZZYZX wrote:MeowsaurEditor.
-
-
- Posts: 4149
- Joined: Thu Jul 17, 2003 12:19 am
- Graphics Processor: nVidia (Legacy GZDoom)
- Location: British Columbia, Canada
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
That's just it.Nash wrote: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...Kappes Buur wrote:Your editor plays havoc with the cfg file generated by GZDB r2787.
Both editors overwrite the GZBuilder.cfg file.