Context-sensitive actions

[Player701]

I also found .locktype but that doesn't seem to mean what I thought it would.

It is actually locknumber, and I think it corresponds to the lock number defined in [wiki]LOCKDEFS[/wiki]. Default lock numbers can be found here, and it is also possible to define custom ones.

On the sector, when looking at a floor I'd like to show an indication if it is damaging. I see there are several ways to add damaging effect in mapping, but not finding much documentation on how to detect that from zscript.

Check the value of the damageamount field: the sector is damaging if the value is greater than zero.

[Sir Robin]

I also found .locktype but that doesn't seem to mean what I thought it would.

It is actually locknumber, and I think it corresponds to the lock number defined in [wiki]LOCKDEFS[/wiki]. Default lock numbers can be found here, and it is also possible to define custom ones.

Oops, yeah that's right. But it still doesn't give me what I'm looking for. I'm testing on Doom2 MAP02, those red bars near the beginning require a red key, but their locknumber is still 0 so that lock must be stored elsewhere. Their special is 13, Door Locked Raise. Creating a test map with a line special 13 doesn't appear to function any different than 12, so the lock is not in the special type as it was with stock doom map format.

For anyone following along: You can check that line.activation flags against SPAC_* flags listed [wiki=GetLineActivation]here[/wiki]. Note that the repeatable is not stored there, it is stored in line.flags, flag 512. Note that when a non-repeatable line is used, it's special will be set to 0.
To know if a line is a secret, check line.flags for 32 (1-sided on map) or 128 (not on map)
I don't see these flags documented anywhere, I'm just finding them by observation.

[Sir Robin]

Hmm, I notice in UDB that for special 13, argument 4 is called "Key Number". So I think I can detect a lock like this:

Code: Select all

		//Passed in: line l
		bool isLocked=l.locknumber || (l.special==13 && l.args[3]);

[Sir Robin]

For reference, I found somewhere the LineDef flags are documented: In the [wiki]PickActor[/wiki] function. direct link

And copied here for reference:

---

Linedef flags
ML_BLOCKING: The linedef is solid.
ML_BLOCKMONSTERS: The linedef blocks monsters.
ML_TWOSIDED: The linedef has two siedes (two sidedefs).
ML_DONTPEGTOP: Upper texture unpegged.
ML_DONTPEGBOTTOM: Lower texture unpegged.
ML_SECRET: Displays on the automap as a one-sided line.
ML_SOUNDBLOCK: Stops sound propagation after two of these linedefs have been traversed.
ML_DONTDRAW: Prevents this linedef from displaying on the automap.
ML_MAPPED: This linedef will be present on the automap from the start of the level.
ML_REPEAT_SPECIAL: This linedef's special is repeatable.
ML_ADDTRANS: Drawn with additive translucency (internal flag).
ML_MONSTERSCANACTIVATE: Monsters can activate this linedef.
ML_BLOCK_PLAYERS: This linedef blocks players.
ML_BLOCKEVERYTHING: This linedef blocks everything.
ML_ZONEBOUNDARY: This linedef indicates a sound zone boundary.
ML_RAILING: This linedef uses Strife's railing collision logic.
ML_BLOCK_FLOATERS: This linedef blocks floating monsters.
ML_CLIP_MIDTEX: This linedef's middle texture is clipped by the ceiling and floor.
ML_WRAP_MIDTEX: This linedef's middle texture wraps around.
ML_3DMIDTEX: This linedef clips actor movement based on it's middle texture.
ML_CHECKSWITCHRANGE: Forces a check to see if the player can really reach a switch.
ML_FIRSTSIDEONLY: This linedef will only be activated when crossed from it's front side.
ML_BLOCKPROJECTILE: This linedef blocks projectiles.
ML_BLOCKUSE: This linedef blocks use actions.
ML_BLOCKSIGHT: This linedef blocks actor sight.
ML_BLOCKHITSCAN: This linedef blocks hitscan attacks.

Can also be found in the source file doomdata.h, look for enum ELineFlags

[Player701]

Hmm, I notice in UDB that for special 13, argument 4 is called "Key Number". So I think I can detect a lock like this:

Code: Select all

		//Passed in: line l
		bool isLocked=l.locknumber || (l.special==13 && l.args[3]);

Yeah, looks like locknumber is UDMF-specific. To support maps in other formats, you will have to check for "lockable" specials and their corresponding arguments signifying the lock type. It seems there aren't too many of these; aside from Door_LockedRaise, there are only [wiki]ACS_LockedExecute[/wiki] (83) and ACS_LockedExecuteDoor (85). Though there may be more if the name doesn't have to include the word "locked".

upd: This wiki article also points to a few more: [wiki]Generic_Door[/wiki], [wiki]Door_Animated[/wiki].

[Sir Robin]

I wonder why those special types get their own locknumber, instead of just relying on the line's locknumber. The only thing I can think of is that they wanted to handle their own "locked" message instead of relying on the default. It seems that the line locknumber is checked first, and then the args one. For example if I set locknumber to blue card and use special 13 with arg3 set to redcard, then:
trying with no card says I need blue card
trying with just blue card says I need red card
trying with just red card say I need blue card
trying with both cards opens the door
If I have the automap set to color a line for it's lock color, it colors this door as blue.

That wiki page says that valid lock numbers are 1-255, inclusive, and all other values are unlocked. Knowing that and those special action numbers and their locknumber args, this is my lock check logic:

Code: Select all

		int LockNumber=l.locknumber;
		if (LockNumber<1 || LockNumber>255){
			if (l.special==13 || l.special==14){LockNumber=l.args[3];}
			if (l.special==83 || l.special==85 || l.special==202){LockNumber=l.args[4];}
		}
		bool isLocked=(0<LockNumber && LockNumber<256);

[Player701]

I wonder why those special types get their own locknumber, instead of just relying on the line's locknumber. The only thing I can think of is that they wanted to handle their own "locked" message instead of relying on the default.

No, I think it's simply that the line locknumber is part of the UDMF spec and was implemented after the lockable specials, which are part of the Hexen map format. The message is defined in [wiki]LOCKDEFS[/wiki] in both cases.

It seems that the line locknumber is checked first, and then the args one.

Good to know that it at least works - don't know why anyone would want to use both, but hey, this is Doom, with all its ugly hacks and stuff...

[Sir Robin]

I'm seeing another glitch effect on the 3d cursor. If it starts on a 2-sided wall that is attached to a moving floor or ceiling, then it glitches for the first few frames before going steady. For floors (platforms, elevators, etc) it happens if the floor is moving up or down. For ceilings (doors, crushing ceilings, etc) it only happens when the ceiling is moving up.
Also, it seems that the cursor is placed behind the geometry move operation. For example if the cursor is placed on a floor moving up or a ceiling moving down then the cursor goes inside the geometry. Same for if the cursor lands on a polyobject moving toward the cursor.

[url=https://drive.google.com/file/d/1ZC6P_J ... sp=sharing]current code[/code]
Cursor placement happens in cursor3d.zsc, in MWR_Cursor3dInv.Show3dCursor()

[Sir Robin]

Update: I said before I couldn't find documentation of the sector and line types that flinetracedata contains as HitSector and HitLine respectively.
I have found documentation for the sector in [wiki]Structs:Sector[/wiki]
Still haven't found any for the Line or F3dFloor.

An issue I'm seeing now: If I get a hit on the floor I want to see what is the damage type and amount for standing on that floor. If I use HitSector.DamageType and HitSector.DamageAmount, those only work for the true floor of the sector. I need to find out how to get those values from the hit 3dfloor. The F3dfloor type does not have .DamageType or .DamageAmount variables on it.

[Player701]

I'm seeing another glitch effect on the 3d cursor. If it starts on a 2-sided wall that is attached to a moving floor or ceiling, then it glitches for the first few frames before going steady. For floors (platforms, elevators, etc) it happens if the floor is moving up or down. For ceilings (doors, crushing ceilings, etc) it only happens when the ceiling is moving up.
Also, it seems that the cursor is placed behind the geometry move operation. For example if the cursor is placed on a floor moving up or a ceiling moving down then the cursor goes inside the geometry. Same for if the cursor lands on a polyobject moving toward the cursor.

This might be due to the fact that during a game tick, the movement happens after the LineTrace coordinates have already been set, so you never see the cursor in the "correct" position for any given tick. I'm not sure if there is a way to account for this - you need to know if the movement is happening right now, and if it is, also which direction. It seems that sectors have a method called PlaneMoving to check for the former, but so far I couldn't find any way to determine the movement speed and/or direction.

An issue I'm seeing now: If I get a hit on the floor I want to see what is the damage type and amount for standing on that floor. If I use HitSector.DamageType and HitSector.DamageAmount, those only work for the true floor of the sector. I need to find out how to get those values from the hit 3dfloor. The F3dfloor type does not have .DamageType or .DamageAmount variables on it.

F3DFloor has a field called model which points to the control sector. Its floor should correspond to the 3D floor's ceiling, and vice-versa.

Still haven't found any for the Line or F3dFloor.

Look for zscript/mapdata.zs in gzdoom.pk3, it contains all the relevant declarations. Some of them even have helpful comments.

[Sir Robin]

Back to the static handlers, my addon describers are class MWR_DescriberAddOn : StaticEventHandler and I'm using your provided example to add them to my describer handler:

Code: Select all

	private void RegisterAddOnImpl(class<MWR_DescriberAddOn> d){
		let AddOn=MWR_DescriberAddOn(new(d));
		_describers.Insert(0, AddOn);
		AddOn.InitializeYourself();
	}

Because of that new(d) call, there are 2 instances of the class, one registered as a static handler and the other kept locally here in the array. I notice that because class variables are not synchronized between the two. To keep it simple I should eliminate on of these instances.
If I only want the static handler, how do I change this register function to pull that one?
If I only want the local copy, where in code do I call the register function? Right now I'm calling it from MWR_DescriberAddOn.OnRegister() so that it registers itself with the handler as soon as it gets registered as a static handler.

Also, does the class have a function that is automatically called when it is instantiated? so I can eliminate that manual InitializeYourself() call.

[Player701]

there are 2 instances of the class, one registered as a static handler and the other kept locally here in the array.

I don't see 2 instances here. d is instantiated once and stored in the variable AddOn, which is then added to the array.

Also, does the class have a function that is automatically called when it is instantiated? so I can eliminate that manual InitializeYourself() call.

Not that I know of.

[Sir Robin]

I think it exists in the Static Handler array and then also another one here locally in the _describers array. I think that because if I take that InitializeYourself() out of this register function and instead call it from the MWR_DescriberAddOn.OnRegister() function, it does indeed get called (I put a console.printf() in there to verify) but the AddOn.variables are not initialized. That's why I think that OnRegister() is getting called from a different instance.

[Sir Robin]

My actual code for the MWR_DescriberAddOn:

Code: Select all

class MWR_DescriberAddOn : StaticEventHandler {
	override void OnRegister(){
		string ThisClassName=GetClassName();
		console.printf('MWR_DescriberAddOn Registered: '..ThisClassName);//DEBUG
		MWR_Describer.RegisterAddOn(ThisClassName);
	}
	

If removed the StaticEventHandler inheritance, the OnRegister() function override, and the AddEventHandlers call in MapIfno, that would eliminate the class as a Static Event Handler. But then where do I call the MWR_Describer.RegisterAddOn(ThisClassName) from?

The other option is to leave it as a Static Event Handler, and change that RegisterAddOn() function to take the instance instead of the classname to create a new instance, but I don't know how to do that either.

[Player701]

Sorry, it seems I no longer understand what is going on here. Please show the entire code and describe the problem again, if you think there is one.