GZDoomBuilder-Bugfix, a maintenance fork of GZDB
- Sarah
- Posts: 551
- Joined: Wed Sep 06, 2006 12:36 pm
- Preferred Pronouns: She/Her
- Operating System Version (Optional): Debian 11 (bullseye), Windows 10
- Location: Middle of Nowheresville Il.
- Contact:
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
ZZYZX, two issues I've noticed with some recent work.
1 - The panel that should display what errors occurred during compiling in the script editor is missing. The script editor says there are errors but does not tell me what they are. Is there a setting I'm missing?
2 - When setting a script to be executed via line, I can only select from one of my scripts using the drop down in the dialog; there are several that should be there. I've long since been in the habit of using named scripts, so copying a name over is obnoxious and error prone (I somehow got a space in before the script name in one instance which left me scratching my head for a moment until console output gave me a clue). I am aware of the check box to indicate a string script name. I'm suspecting bug here.
Looks like I'm using 2.3.0.2989 (e7328e4). Issue 2 has existed since at least the previous update. Thanks in advance for looking into these issues. Let me know if you need more info, the map, etc.
*Edit - After some more fiddling I discovered the error panel was just hiding. So I was missing something. No insights into issue 2 though.
1 - The panel that should display what errors occurred during compiling in the script editor is missing. The script editor says there are errors but does not tell me what they are. Is there a setting I'm missing?
2 - When setting a script to be executed via line, I can only select from one of my scripts using the drop down in the dialog; there are several that should be there. I've long since been in the habit of using named scripts, so copying a name over is obnoxious and error prone (I somehow got a space in before the script name in one instance which left me scratching my head for a moment until console output gave me a clue). I am aware of the check box to indicate a string script name. I'm suspecting bug here.
Looks like I'm using 2.3.0.2989 (e7328e4). Issue 2 has existed since at least the previous update. Thanks in advance for looking into these issues. Let me know if you need more info, the map, etc.
*Edit - After some more fiddling I discovered the error panel was just hiding. So I was missing something. No insights into issue 2 though.
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
2 — I need script source. Ideally untouched, but at least with script ... (...) { ... } and includes. Parser might be broken or something.
- Sarah
- Posts: 551
- Joined: Wed Sep 06, 2006 12:36 pm
- Preferred Pronouns: She/Her
- Operating System Version (Optional): Debian 11 (bullseye), Windows 10
- Location: Middle of Nowheresville Il.
- Contact:
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
I actually think I found the issue: my overzealous use of commenting.
Example:
The extra //'s seem to be causing the problem. I haven't tested yet but something like "// -" might be enough to solve the issue; my hypothesis is that the lack of characters following the // is confusing the parser. So, the lesson here is to use block comments. My discovery of this came from noticing that the one script that does appear in the drop down is the lone script without a comment preceding it.
Code is attached below if you still need to look into this.
Example:
Code: Select all
//
// - Script Description
//
script "I_Have_Not_Written_ACS_In_Over_A_Year" (void)
{
// ... stuff ...
}
Code is attached below if you still need to look into this.
- Attachments
-
- source.txt
- (3.13 KiB) Downloaded 31 times
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Thanks, got it to reproduce. Will update later today, I think.
Regarding this
Regarding this
I don't have Win10, but will look into it.Kappes Buur wrote:Request:
Concerning screenshots taken with F10, could the extra 7 pixel frame on the sides and the bottom be eliminated.
Spoiler:That's been bugging me for some time now. Having to get rid of the frame in another app is just getting to me.
Thank you
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Code: Select all
class LADCharacter : Inventory
{
enum ECharacterSex
{
SEX_Male,
SEX_Female,
}
enum ECharacterEthnicity
{
ETH_Caucasian,
ETH_African,
ETH_Hispanic,
ETH_Asian,
}
Default
{
Inventory.MaxAmount 1;
+Inventory.UNDROPPABLE;
+Inventory.PERSISTENTPOWER;
+Inventory.AUTOACTIVATE;
+Inventory.UNTOSSABLE;
+Inventory.KEEPDEPLETED;
-Inventory.INVBAR;
}
FCharacter myStat;
Array<LADItem> myItems;
bool bIsModularCharacter;
LADModularCharacterPart myModularCharacterPart[LADModularCharacterPart.TOTAL_MODULAR_CHARACTER_PARTS];
}
ZSCRIPT error in "src\zscript\base\LADCharacter\LADCharacter.zc", line 145. Expected ], got <Token.Dot (.)>.
-
- Posts: 9
- Joined: Thu Apr 06, 2017 2:45 am
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
I can't seem to desync the maximum brightness levels between 3D mode and classic top down viewing mode. Is this a bug or some feature that was added in earlier? If it is a feature, would it be possible to add in a menu option that allows the maximum brightness mode to be toggled on or off for each viewing mode and remain independent of each other?
- kevansevans
- Spotlight Team
- Posts: 420
- Joined: Tue Oct 05, 2010 12:04 am
- Graphics Processor: nVidia with Vulkan support
- Contact:
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Can I request the ability to save maps as text files and the ability to load these text files? The group I'm working in has settled on using github to keep our files synced together as we work on it, however, pull requests don't like merging binary files, which includes the .wad. Having it as a text file would make the merging process way easier. Along that note, an refresh function would be great for whenever a pull is made on the map, so we don't have to close the editor and reopen every time.
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
UDMF needs to be put in a wad to work using the folder structure, which is a binary format. However, I'm unclear on how this would work as a GZDB-BF suggestion, since this sounds more like a suggestion for a way to store maps in the folder structure without using wads, which sounds like more of a suggestion towards GZDoom than GZDB-BF (though, if such a thing were to exist in GZDoom, I reckon GZDB-BF would be updated to support that).
- kevansevans
- Spotlight Team
- Posts: 420
- Joined: Tue Oct 05, 2010 12:04 am
- Graphics Processor: nVidia with Vulkan support
- Contact:
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
To make it easier to use github to synchronize files? I literally explained my reasoning in my request. Having to keep repackaging the files inside a wad over and over to edit it in builder, then unpackage everything to push a commit, would get very tiresome and difficult to keep track of. If we had the option to save a wad in it's most bare format, which is text files, this would make map editing much more smooth on group projects, where several people are focusing on the same map. GZDoom doesn't have to support the ability to run maps in the bare format, but builder having the ability to process and save them should be a thing. Plus the advantages of this would include being able to document every small change that happens, akin to how regular coding projects can use commit history to find out where things were changed, and make it easier for the project developers to communicate what's going on.Gutawer wrote:UDMF needs to be put in a wad to work using the folder structure, which is a binary format. However, I'm unclear on how this would work as a GZDB-BF suggestion, since this sounds more like a suggestion for a way to store maps in the folder structure without using wads, which sounds like more of a suggestion towards GZDoom than GZDB-BF (though, if such a thing were to exist in GZDoom, I reckon GZDB-BF would be updated to support that).
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Wouldn't you eventually run into problems with several people fudging with already existing stuff? Multiple people working on the same map at the same time is a bad idea. If someone draws an area south of center, and then another person at the same time is drawing another area south of center, only one person's changes could realistically be accepted without complete fuckery.
- kevansevans
- Spotlight Team
- Posts: 420
- Joined: Tue Oct 05, 2010 12:04 am
- Graphics Processor: nVidia with Vulkan support
- Contact:
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
This is probably the only downside to this, but it's already an existing problem regardless if this gets added or not.Lud wrote:Wouldn't you eventually run into problems with several people fudging with already existing stuff? Multiple people working on the same map at the same time is a bad idea. If someone draws an area south of center, and then another person at the same time is drawing another area south of center, only one person's changes could realistically be accepted without complete fuckery.
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
... Then your request won't solve the problem.
- kevansevans
- Spotlight Team
- Posts: 420
- Joined: Tue Oct 05, 2010 12:04 am
- Graphics Processor: nVidia with Vulkan support
- Contact:
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
That's not the problem it's targeting.Lud wrote:... Then your request won't solve the problem.
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Proper multiplayer mapping should be relatively easy to achieve. I don't have any interest in this right now though.
/me hides
/me hides