trying (and failing) to make a monster hop off ledges but I got help, thank you

[bimshwel]

the references to "fyip" are tentatively what the monster is called

FYPa abcdefgh 3 { if (Checkinventory("hopmaker", 1)); { return resolvestate("hop"); } A_Chase (); A_StartSoundIfNotSame ("bell/small" ,0); return resolvestate(null); loop; }
The jump to "hop" should only occur if one or more "hopmaker"s is had. in this checkinventory setup the jump always occurred, even before I had a system to give fyip the hopmaker. I converted it from an old setup in decorate that I also needed help with but that does now work, well enough. This is definitely checking SOMETHING since the game freaks out if the item name is invalid.
FYPa abcdefgh 3 { A_Chase (); A_spawnitemex ("groundchequer", 32, 0, 22, 0, 0, -16, 0, SXF_SETMASTER) ; A_StartSoundIfNotSame ("bell/small",0); //A_Checksolidfooting ("landing"); A_JumpIfInventory("hopmaker", 1, "hop") ; } loop;

this other way, the hop never occurs. Though I may have made the item-giver improperly. this stuff wears me out
this ground checker is launched by the monster on every frame of its walk cycle. it DOES show up, but it doesn't seem to fulfill its purpose.

class groundchequer : eepActor { Default { scale .1; Radius 4; Height 4; Speed 20; gravity 4; +ismonster +noblockmap //setting missile will make it "die" when it hits ground but that will also make it go through impassible lines //the idea is for it to explode if it hits the ground but if it falls instead, and more than 24 units below the ground, to give the fyip an item that will make it jump forward //terribly hacky but all i understand //the fyip will need to both launch this ground checker and check for the jump item on every frame. stupid nuisance } states { spawn: A___ a 1; // if this works theoretically you can have it try to jump UP if it reaches solid ground right away b___ a 1 A_Checksolidfooting ("nope"); // i do NOT want it to hop if there are simple stairs c___ a 1 A_Checksolidfooting ("nope"); //someone more competent than you ("you" being me, I write notes to myself) could automatically track how far the thing fell but such a person wouldn't need to make a separate ground checking object either d___ a 1 A_RadiusGive("hopmaker", 64, RGF_MONSTERS|RGF_NOMASTER|rgf_inclusive, 1); //meant to trigger the state change in its "master" e___ a 1; //just a placeholder stop; //these letter-named sprites were to help me know at what point the object had dropped past 24 below the ground. if this had worked I would have turned these invisible next stop; a___ d 1; stop; } }

and i "need" it as zscript because it relies on a custom function "check solid footing" that uses zscript
as part of my hacky attempt to make a creature check for elevation differences to hop into
which there is surely a less hacky way to do but I wanted to see if i could at least implement it to some degree without asking for help since I hate asking for help
nope


hop: fyij e 3 ; fyij a 3 A_SetUserVar("user_fyipground", 0); fyij a 0 a_changevelocity (0,0,random(4, 8),0,0); //they seem to want to jump backwards whether the first value is negative or positive //recoil is more consistent fyij a 0 A_Recoil (-4); fyij bc 3; falling: //fyij d 3 A_JumpIf(user_fyipground == 0, "painfalling"); jumpifuser would be used within its pain state fyij d 3 A_Checksolidfooting ("landing"); goto falling; landing: fyij e 3 A_SetUserVar("user_fyipground", 1); fyij a 3; goto see;
the hop itself works, thankfully, though gzdoom whines at me about user variables being "deprecated." I tried looking into "actor variables" and it SEEMED to be related to map editor stuff, which this isn't. is it?

thank you for looking! I have a backup "plan" that will make specific sectors prompt chosen monsters to jump If this is not able to be salvaged.

[Jarewill]

The jump to "hop" should only occur if one or more "hopmaker"s is had. in this checkinventory setup the jump always occurred, even before I had a system to give fyip the hopmaker.

The reason why it always triggers is because of the stray semicolon, which causes this code:

Code: Select all

if (Checkinventory("hopmaker", 1)); //<--- This one
{
	return resolvestate("hop");			
}

To be interpreted as this:

Code: Select all

if (Checkinventory("hopmaker", 1)){ } //Empty block

return resolvestate("hop"); //Outside said block

this other way, the hop never occurs.

That's because of how jumps work in anonymous functions, you will have to use Return here:
Return A_JumpIfInventory("hopmaker", 1, "hop") ;

and i "need" it as zscript because it relies on a custom function "check solid footing" that uses zscript
as part of my hacky attempt to make a creature check for elevation differences to hop into
which there is surely a less hacky way to do but I wanted to see if i could at least implement it to some degree without asking for help since I hate asking for help

You don't need to use ZScript exactly, as you can put those ZScript functions into a base class and inherit your DECORATE monsters from that one.
However it's encouraged to keep using ZScript.

Which, as you are already using it, you can use the following custom function instead of that actor:

Code: Select all

	action state A_CheckNoGround(statelabel label, int dist = 24){ //This is the custom function
		FLineTraceData h;
		LineTrace(angle,dist,90,TRF_THRUACTORS,1,radius*2,data:h); //LineTrace will fire a hitscan attack to check for solid ground
		If(h.HitType==TRACE_HitNone){
			Return ResolveState(label); //If nothing was hit in specified distance, jump to the specified state
		}
		Return null;
	}
	States{
	See:
		SARG AABBCCDD 2{
			A_Chase();
			Return A_CheckNoGround("Hop"); //Example use of this function, if you want to modify the range for per actor basis you can put ("Hop", 32) in the function for example
		}
		Loop;
	}

the hop itself works, thankfully, though gzdoom whines at me about user variables being "deprecated." I tried looking into "actor variables" and it SEEMED to be related to map editor stuff, which this isn't. is it?

In ZScript you don't need to use user variables, as you can define custom ones, like so:

Code: Select all

Class NewDemon : Demon replaces Demon{
	bool fyipground;
	States{ //...

And then modify them like this:
fyij a 3 { fyipground = 0; }

(image)

Oh, I adore how they look!

[bimshwel]

thank you for looking into it! this seems much more trustworthy than what I was doing. It makes a big difference.
I found that they were jumping too far from the ledge, but when i increased the 90 to 120 they were better about it.

however, they now try to jump up ledges too high for them or through impassible 2-sided lines. I had set the previous ground checking object as a "monster" to try and keep it from going past certain barriers (though it probably would not have worked like I thought it would). Is there a way to stop that? If not, there are ways to control this present behavior, or i can simply use a non-jumping variant when necessary. I appreciate that they TRY to jump up ledges. The more stuff they try to do the less they seem like regular doom monsters.

the inheritance stuff has gradually made more sense to me; before yesterday I had defined the custom action for every actor that used it! There have only been three so far fortunately.
I have seen that "jumps work differently in anonymous functions" bit a whole bunch of times but not quite been able to grasp the concept, but hopefully with working examples in decorate AND zscript I won't be whining over that again.
I included the picture the first time to put my cluelessness level into context, but I am glad if the creatures' appearance is pleasant! They definitely have more personality when jumping occasionally, even if not always in appropriate places.

[Jarewill]

however, they now try to jump up ledges too high for them or through impassible 2-sided lines. I had set the previous ground checking object as a "monster" to try and keep it from going past certain barriers (though it probably would not have worked like I thought it would). Is there a way to stop that?

Oops, that was an oversight on my part, apologies.
This updated function should do the trick:

Code: Select all

	action state A_CheckNoGround(statelabel label, int dist = 24){ 
		FLineTraceData h, i;
		LineTrace(angle,dist,90,TRF_THRUACTORS,1,radius*2,data:h);
		LineTrace(angle,radius*2,0,TRF_BLOCKSELF,1,data:i); //Call another linetrace to check if there is something blocking the monster's movement
		If(h.HitType==TRACE_HitNone && i.HitType==TRACE_HitNone){
			Return ResolveState(label);
		}
		Return null;
	}

[inkoalawetrust]

hop: fyij e 3 ; fyij a 3 A_SetUserVar("user_fyipground", 0); fyij a 0 a_changevelocity (0,0,random(4, 8),0,0); //they seem to want to jump backwards whether the first value is negative or positive //recoil is more consistent fyij a 0 A_Recoil (-4); fyij bc 3; falling: //fyij d 3 A_JumpIf(user_fyipground == 0, "painfalling"); jumpifuser would be used within its pain state fyij d 3 A_Checksolidfooting ("landing"); goto falling; landing: fyij e 3 A_SetUserVar("user_fyipground", 1); fyij a 3; goto see;
the hop itself works, thankfully, though gzdoom whines at me about user variables being "deprecated." I tried looking into "actor variables" and it SEEMED to be related to map editor stuff, which this isn't. is it?

User variables (Like user_fyipground) in DECORATE were a hack to have more proper programming variables instead of using inventory tokens. Since they were a hack in the DECORATE days, that also means that they needed special access functions to read and modify them (Like A_SetUserVar). But ever since DECORATE was deprecated by ZScript, which supports normal, proper class members. User variables have no longer needed to be used for internal variables. Which is why using A_SetUserVar is giving you that deprecation warning, because you can just directly read and modify that user_fyipground variable in ZScript, without needing A_SetUserVar.

And the reason that looking up "Actor variables" on the wiki brings up exposing variables to map editors (I wrote that documentation lol) is because user variables have been repurposed in ZScript to be a way to expose actor settings to map editors, so that they aren't just kept as a vestigial bit of code from the DECORATE days.


TL;DR, since you are writing ZScript code, you do not need to access variables you define with any special functions, you can just read and write them directly. And you should also remove the user_ prefix from them, because in ZScript that exposes them to map editors.

[bimshwel]

Oops, that was an oversight on my part, apologies.
This updated function should do the trick:

thank you again! it is wonderful to have such little changes make such a big difference. no need to apologize for ME not being satisfied.
Although the endlessly trying to jump version is also fun.
Is there a risk of too many line traces coming too often slowing things down? Would a third and fourth that to check for ground above 25 but below 40 units be feasible? And that would require an OR after the if?

User variables (Like user_fyipground) in DECORATE were a hack to have more proper programming variables instead of using inventory tokens. Since they were a hack in the DECORATE days, that also means that they needed special access functions to read and modify them (Like A_SetUserVar). But ever since DECORATE was deprecated by ZScript, which supports normal, proper class members. User variables have no longer needed to be used for internal variables. Which is why using A_SetUserVar is giving you that deprecation warning, because you can just directly read and modify that user_fyipground variable in ZScript, without needing A_SetUserVar.

And the reason that looking up "Actor variables" on the wiki brings up exposing variables to map editors (I wrote that documentation lol) is because user variables have been repurposed in ZScript to be a way to expose actor settings to map editors, so that they aren't just kept as a vestigial bit of code from the DECORATE days.


TL;DR, since you are writing ZScript code, you do not need to access variables you define with any special functions, you can just read and write them directly. And you should also remove the user_ prefix from them, because in ZScript that exposes them to map editors.

thank you also! I will hopefully understand that later. I get most of my information on this from the zdoom wiki which tends to give less than comprehensive examples for ways features can be used or what syntax is called for to alter them, and typically I make things work by modifying code that I know already works, which could be from any period. That was perhaps more effective in dehacked and decorate sort of situations that couldn't have as many layers or affect as many aspects of the game, and even my attempts at website design over the years. Plainly I ought to investigate more off-site information sources! I even had that very linked page about variables open the other day, but perhaps impatiently only got up to the speedy imp before thinking I might be looking in the wrong place.

this reminds me of algebra! I was not very good at it though I did manage to pass the classes I was in a long time ago.

[Jarewill]

thank you again! it is wonderful to have such little changes make such a big difference. no need to apologize for ME not being satisfied.
Although the endlessly trying to jump version is also fun.
Is there a risk of too many line traces coming too often slowing things down? Would a third and fourth that to check for ground above 25 but below 40 units be feasible? And that would require an OR after the if?

I somehow missed this for a while, sorry for the late response.

I have been using many line traces in many of my mods and I haven't had any performance issues regarding them, but I'm not an engine expert.
It might be worth mentioning that the BFG9000 in Doom fires 40 line traces every time it detonates and I used to put A_BFGSpray during the actual flying frames, so those 40 traces were happening every few tics and even then there were no performance issues on my old laptop.

As for the question regarding more checks, I assume you want something that checks if there's a wall above 25 units, but it ends before 40 units and then you want your monster to jump up?
If so, you can copy-paste the current 2 linetraces and the If check and simply edit some arguments, like so:

Code: Select all

	action state A_CheckNoGround(statelabel fallstate, statelabel jumpstate, int dist = 24){ 
		FLineTraceData h, i;
		LineTrace(angle,dist,90,TRF_THRUACTORS,1,radius*2,data:h);
		LineTrace(angle,radius*2,0,TRF_BLOCKSELF,1,data:i);
		If(h.HitType==TRACE_HitNone && i.HitType==TRACE_HitNone){
			Return ResolveState(fallstate);
		}
		LineTrace(angle,radius*2,0,TRF_BLOCKSELF,25,data:h);
		LineTrace(angle,radius*2,0,TRF_BLOCKSELF,40,data:i);
		If(h.HitType==TRACE_HitWall && i.HitType==TRACE_HitNone){
			Return ResolveState(jumpstate);
		}
		Return null;
	}

This edited code adds a new argument called jumpstate, which will be the state the monster should jump to whenever it passes the jumpable check (>25 and <40).
And if you don't want your monster to either fall down or jump up, you can pass null in the argument responsible for the state.

I hope this helps you.

[bimshwel]

Thank you once more! Gosh that is brilliant! As far as i can tell. Now I can even give the beasts different frames for going up or down, though hopefully I don't. I have put your name in a comment preceding the code in the zscript file so I don't ever forget who supplied it.
I can understand missing my further question heap, it was buried in a rambling reply to someone else. I had started by copying and editing the existing traces and figured there would be if-anding involved, that I imagined I could figure out after reading further into zscript documentation, though I except this is more compact than what I would have come up with, assuming I ever did.