Ultimate Doom Builder

[CoderGrizzly]

I see, I see.
That's a pity , but explains a lot.

Thanks for the fast reply, @boris, much appreciated.

[Shatter-Thought[V-4]]

An error to report (I had been just drawing lines inside of a sector to make new ones when this happened):

***********SYSTEM INFO***********
OS: Microsoft Windows 10 Home
GPU: AMD Radeon(TM) Vega 3 Graphics
UDB: R4213
Platform: x64

********EXCEPTION DETAILS********
This array is locked for modification and cannot currently be enumerated.
at CodeImp.DoomBuilder.Map.MapElementCollection`1.GetEnumerator() in c:\build\UltimateDoomBuilder\Source\Core\Map\MapElementCollection.cs:line 71
at CodeImp.DoomBuilder.Config.ProgramConfiguration.FindDefaultDrawSettings() in c:\build\UltimateDoomBuilder\Source\Core\Config\ProgramConfiguration.cs:line 856
at CodeImp.DoomBuilder.BuilderModes.DrawGeometryMode.OnAccept() in c:\build\UltimateDoomBuilder\Source\Plugins\BuilderModes\ClassicModes\DrawGeometryMode.cs:line 812
at CodeImp.DoomBuilder.Editing.EditingManager.AcceptMode() in c:\build\UltimateDoomBuilder\Source\Core\Editing\EditingManager.cs:line 453
at CodeImp.DoomBuilder.BuilderModes.DrawGeometryMode.FinishDraw() in c:\build\UltimateDoomBuilder\Source\Plugins\BuilderModes\ClassicModes\DrawGeometryMode.cs:line 1004
at CodeImp.DoomBuilder.Actions.Action.Begin() in c:\build\UltimateDoomBuilder\Source\Core\Actions\Action.cs:line 269
at CodeImp.DoomBuilder.Actions.ActionManager.BeginActionByKey(Int32 key, Boolean repeated) in c:\build\UltimateDoomBuilder\Source\Core\Actions\ActionManager.cs:line 569
at CodeImp.DoomBuilder.Actions.ActionManager.KeyPressed(Int32 key) in c:\build\UltimateDoomBuilder\Source\Core\Actions\ActionManager.cs:line 519
at CodeImp.DoomBuilder.Windows.MainForm.display_MouseDown(Object sender, MouseEventArgs e) in c:\build\UltimateDoomBuilder\Source\Core\Windows\MainForm.cs:line 1167
at System.Windows.Forms.Control.OnMouseDown(MouseEventArgs e)
at System.Windows.Forms.Control.WmMouseDown(Message& m, MouseButtons button, Int32 clicks)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

[Ravick]

I'm not sure if it is the right place to post it. I apologize if it isn't.

By mistake, I tried to save the map while GZDoom was open and running it, and this happened: https://imgur.com/a/ydmDiru ( )

I know it was my mistake to forget to close GZD first, but could it be considered a bug? Maybe, giving the mapper another chance to save the map before closing the application?

Please, don't take this as a complaint or so. Just reporting.

[Enjay]

I have an interesting problem.

I recently converted a whole bunch of DECORATE code to ZScript. It was a big task, but I got there. GZDoom is happy with the result. I have checked most of it quite thoroughly, and everything I have checked seems to work in game. However, I just fired up UDB and it is giving me warnings that I can't resolve (almost 1,000 of them - 982 to be precise, and only one of them should be happening, a warning about not finding the sky texture because I haven't loaded that file deliberately).



Here's an example:
UDB Warning:

Code: Select all

ZSCRIPT error in "00BaseControlText.pk3\zscript\Weapons\NJZS_Weapons.zs", line 3180. Expected identifier, got <Token.Whitespace ( )>.

Relevant code:

Code: Select all

CLASS NJBluePuff : NJBulletPuff { 
	Default {
		
		Scale 0.5;
		RenderStyle "Add";
		Alpha 0.7;
	}
	States
	{
		Spawn:
			BPFF A 1 Bright;
			BPFF A 0 A_Jump(24, "Rick01", "Rick02");
			BPFF A 3 Bright;
			BPFF B 4;
			goto Melee;
			
		Rick01:
			BPFF A 0 Bright A_StartSound("puff/ricalways");
			BPFF A 0 BRIGHT A_SpawnItemEx ("NJPuffSparkBlue", 0, 0, 0, frandom(7, 16)*((random(0, 1)*2)-1), frandom(7, 16)*((random(0, 1)*2)-1), frandom(7, 16)*((random(0, 1)*2)-1), 0, SXF_NOCHECKPOSITION, 0);
			BPFF A 3 Bright;
			BPFF B 4;
			goto Melee;
			
		Rick02:
			BPFF A 0 Bright A_StartSound("puff/ricalways");
			BPFF AA 0 BRIGHT A_SpawnItemEx ("NJPuffSparkBlue", 0, 0, 0, frandom(7, 16)*((random(0, 1)*2)-1), frandom(7, 16)*((random(0, 1)*2)-1), frandom(7, 16)*((random(0, 1)*2)-1), 0, SXF_NOCHECKPOSITION, 0);
			BPFF A 3 Bright;
			BPFF B 4;
			goto Melee;
			
		Melee:
			BPFF C 4 A_SetTranslucent(0.4, 0);
			BPFF D 4;
			Stop;
	}
}

Line 3180 is the long one in Rick02 that starts BPFF AA 0 BRIGHT A_SpawnItemEx ("NJPuffSparkBlue"...
I can't see anything wrong with it. You'll notice an almost identical line above doesn't seem to cause a complaint. I've tried editing it in a few ways, and still get the problem. If I comment it out entirely, then another warning about a line much earlier in the same file, in a different actor, flags up a warning instead.
It's worth pointing out that this line in its DECORATE (basically without the ; at the end) form did not cause a problem to UDB.

However, the above error is one of a kind. The vast majority of errors are about DECORATE classes not existing, either from my ModelDef files, or my GLDef files.

The following error is typical of one that gets repeated several hundred times:

Code: Select all

MODELDEF warning in "BaseModels.pk3\MODELDEF.000.TXT", line 224. DECORATE class "YellowTracer" does not exist.

It's quite correct, that DECORATE class does not exist. No DECORATE classes exist in my project. A ZScript class of the same name does though.

Code: Select all

///////////////////////////////////////
//Yellow Tracer
///////////////////////////////////////
 
CLASS YellowTracer : FastProjectile { 
	Default {
		
		Radius 4;
		Height 4;
		Scale 0.3;
		Speed 75;
		Damage 2;
		PROJECTILE;
		+FORCEXYBILLBOARD;
		RenderStyle "Add";
		Alpha 0.9;
		
	}
	States
	{
		Spawn:
			YEL2 A 1 Bright;
			Loop;
		Death:
			YEL2 A 1 Bright;
			Stop;
	}
}

ModelDef

Code: Select all

Model YellowTracer
{ 
   Path "models"
   SKIN 0 "tracery.png"
   MODEL 0 "tracer.md3"
   Scale 1.5 1.5 1.5
   PITCHFROMMOMENTUM
   
   FrameIndex YEL2 A 0 0
}

I can't see anything amiss with any of that. I have tried moving the ZScript definition into a different file (including the top level ZScript file that I use for #include-ing other files but still no joy.


Yellow tracer model working perfectly in game!

I have checked and double checked, and UDB is loading the required PK3 files. In fact, I know it is because some other actors in the exact same files are working!
UDB 3D mode screenshot.

These models are in the same files as other models that UDB claims do not exist.

And, again, all these files worked when the actors were in DECORATE format. It's only since the conversion to ZScript that the warnings have appeared and, like I said, GZDoom is happy with them.

Any ideas?

[Enjay]

In fact, see that Duke Nukem spherical globe thingy in the picture I posted? UDB does not throw up an error about it not existing in MODELDEF but I've just noticed this for the GLDefs file...

Code: Select all

GLDEFS warning in "00BaseControlText.pk3\gldefs/lights.txt", line 7179. DECORATE class "SpaceGlobe" does not exist.

Yes, yes it does exist. That's it in the picture!

And, for what it's worth, UDB warns me that some barrel model actors do not exist. The ones it claims do not exist are in the same file as those stripey ones in the picture.

To be clear, the MODELDEF files and the GLDEFS files are the exact same ones that I was using before. Only the DECORATE files have been changed (converted to ZScript and the originals removed).
I'm bamboozled!

Edit: Additional info. I kept a backup of the old version of my game (with the DECORATE files) and if I go back to it, UDB starts without complaining. That is, all I am doing with this is replacing the current directory by renaming it, and then renaming my backup to have the proper active directory name. All the PK3 files within have the same names, so UDB is definitely loading all the right files in both cases.

[boris]

Here's an example:
UDB Warning:

Code: Select all

ZSCRIPT error in "00BaseControlText.pk3\zscript\Weapons\NJZS_Weapons.zs", line 3180. Expected identifier, got <Token.Whitespace ( )>.

UDB doesn't like if you have whitespace before flags or in dotted identifiert. So something like this is valid ZScript, but results in the error in UDB:

Code: Select all

+ FLATSPRITE
Armor. Saveamount 5;

You'd have to change it to this for it to work in UDB:

Code: Select all

+FLATSPRITE
Armor.Saveamount 5;

The following error is typical of one that gets repeated several hundred times:

Code: Select all

MODELDEF warning in "BaseModels.pk3\MODELDEF.000.TXT", line 224. DECORATE class "YellowTracer" does not exist.

When UDB encounters an error it'll stop parsing, so it doesn't know of the classes that are later used in MAPINFO or MODELDEF. The warnings should go away once the ZScript is parsed correctly.

[Enjay]

Aha! That was very helpful, thank you.

I did indeed have a few flags with spaces between the +/- and the flag name (mostly - COUNTKILL for some reason).
It also flagged up a few places where clumsy copy/pasting had meant I had BRIGHT BRIGHT in some states, where (obviously) it should just have been BRIGHT. I'm surprised that GZDoom didn't pick that one up. It was even there in the original DECORATE files before I converted to ZScript too.

I have to say that UDB really isn't very good at identifying which line an error is on. GZDoom gets it bang on every time in my experience. UDB got the file names right, but the line references were always wrong. Maybe it disregards comment lines? Sometimes the actual problem could be more than 100 lines away from where UDB told me it was. At least I knew it would be somewhere in the file, so I just searched for either "+ " or "- " or, in the case of "cannot use bright more than once", I searched for "Bright Bright". So, eventually I got everything.

The only one that took me a moment to realise what the problem was, occurred with this code. As far as I know, it's legitimate, but UDB really doesn't like it.

Code: Select all

	States
	{
		Spawn:
			TNT1 A 0;
			POSS A 0 A_JumpIf(args[0] == 0, "12Plates");
			POSS A 0 A_JumpIf(args[0] == 1, "09Plates");
			POSS A 0 A_JumpIf(args[0] == 2, "06Plates");
			POSS A 0 A_JumpIf(args[0] == 3, "03Plates");
			
		12Plates:
			POSS A -1;
			Stop;
			
		09Plates:
			POSS B -1;
			Stop;
			
		06Plates:
			POSS C -1;
			Stop;
			
		03Plates:
			POSS D -1;
			Stop;
	}

UDB told me that sprite names cannot be more than 4 characters (which is obviously correct) and that it got "12Plates" instead. As you can see, 12Plates is a state sequence label, and not a sprite name. I don't think that there is anything wrong with the code.

Eventually, I figured that it was the actual state sequence labels (i.e. not the ones in the A_JumpIf statements).
I did that by changing A_JumpIf(args[0] == 0, "12Plates"); to A_JumpIf(args[0] == 0, "13Plates"); and leaving the actual state sequence label at 12, and the error still reported that "12Plates" was a problem sprite name (not 13Plates).

Eventually, it dawned on me that the issue might be that UDB doesn't like state sequence labels that begin with a number. Apparently, that's the case. When I changed the labels to "Plates12" (etc), the errors went away. I did it one at a time, just to be certain, and sure enough, once I had Plates12 (instead of 12Plates), UDB told me that "sprite names cannot be more than 4 characters, got 09Plates". After fixing 09, I got told that 06Plates was the error...


So, perhaps that is a problem with UDB? I'm not aware of any restriction that says state labels cannot begin with a number?

A state label can be any alphanumeric string (within reason) and is not case sensitive.

Perhaps UDB thinks it's not reasonable to start a state label with a number?


Anyway, thanks again for the help. My project loads without errors now, and UDB has helped me flush out a few bits of sloppiness in my code too. So, it was actually quite useful for this to happen.

[boris]

UDB will never be able to parse ZScript/Decorate 100% correctly. But if it's well formatted it should usually work.

Fun fact: the following is valid Decorate code (and no, UDB does not parse that correctly):

Code: Select all

actor~:Medikit"replaces""Zombieman""600" {
    inventory "." "amount" "1"
    +"ACTOR" "." SHOOTABLE
    states {
        "Death" ".": :
            \::\["RANDOM""(""1"",""2"")"
            loop
    }
}

[Enjay]

That's quite some DECORATE.

At least I know now that starting a state sequence label with a number won't be read properly by UDB, so I can avoid doing that. To be fair, I pretty much already have. It was only one actor in several hundred.

In case you were wondering (probably not), the "12Plates" actor is exactly what it sounds like. A stack of plates where you set an argument on the actor to say how many plates you want in the stack.

[Sandro]

Hello! I have a suggestion to request:

There exists a copy properties function in classic mode. Would it be possible somehow to add a copy floor properties and copy ceiling properties for sectors ?

I often polish my ceilings after most of my areas are built and playable. And it's usually tedious to draw new lines above complex sector structures and then edit each one of them.

As no one has asked for it before, I would understand it's not a necessity, but still, I thought I better ask in case someone else finds it interesting to add to the editor.

[Enjay]

Does using shift-ctrl-c and shift-ctrl-v with the appropriate sectors highlighted and making sure the sector characteristics that you want to copy are selected in the pop-up that appears when you hit shift-ctrl-v not do what you are asking?

[Sandro]

I assume you are referring to these controls in visual mode ? It actually works, yet it modifies both floor and ceiling. So if I want to copy properties of only one of the two, I think this isn't possible, is it ?

I was asking about this in classic mode, but I would definitely love to have this feature in both modes.

[boris]

The "paste properties special" Enjay mentioned work in both the classic and visual modes. When pasting it optens a dialog where you can select what should be pasted. If it doesn't work you either changed the keybinds or are doing something wrong.

[Sandro]

My mistake then, I simply wasn't aware of such feature and had no keybind preselected for it.

In my opinion, having to verify 47 checkboxes costs too much time compared to manually build what you'd want. Moreover, 26 out of these 47 are either concerning floor or ceiling properties ; so if one wants to just copy a ceiling's properties, they'd have to check (or uncheck) 13 checkboxes at least ; and if they want to copy a floor's properties after that, it's 13 checkboxes again...
I was requesting something more effective, like a single keybind for each of these, so it'd require 2 seconds maximum to copy-paste what you want.

Anyway, you showed me that something similar already exists, so I understand it's not really necessary. Thank you for your reply.

[Enjay]

I find it straight forward enough. Usually, I do want to want to copy everything. However, if there are one or two things I don't want to copy, it's easy to toggle them off. If I only want to copy a small number of properties, then I hit the toggle all button and then re-enable the few that I want.

And the good thing is, you don't have to do it every time. Once you have changed which features are selected, the same set will be selected the next time you press shift-ctrl-v. So, if your are doing the same, or a similar style of copy/pasting, there is minimal, if any, reselecting of features.