HEXEN HUB MONSTER CLONING GLITCH - SETTING A SPAWN LIMIT [RESOLVED]

[Psychojack88]

I've been recently updating a mod that I've posted here called the Daisy Eternal Companion Mod, which can be found on ModDB. I would post it here but the 52kb limit is a killer.

I'm trying to fix an issue specifically with Hexen hub levels. My mod normally doesn't duplicate the character but when entering these hubs, the character clones itself. I think it's something to do with the hub levels and could use some help with figuring this glaring glitch out.

Ideally maybe an enforced spawn limit might help at least stop this, but I don't know how. If anyone has had experience with setting spawn limits on a specific monster or with Hexen hubs I would greatly appreciate any help.

[Enjay]

I haven't checked the full details of the mod but I notice that you have enter, return and respawn scripts set up to give DaisyEternalProtection (which I assume has something to do with the spawning of the companion (great artwork BTW)).

You probably know some of this, but bear with me:
An enter script is deemed to be run by the player when they first enter a map.
A respawn script is for when you respawn in a multiplayer game.
A return script is run when you (you guessed it) return to a map - usually one in a hub, because that's really the only kind of map you can go back to and find things as you left them.

In most Doom maps, most of the time, only the Enter script will trigger. If you are playing multiplayer, you will also trigger the respawn script if you die and respawn.
However, in a game like Hexen, with hubs, the enter script gets run when you enter the map, and the return script gets run when you return to a map in the hub that you have already visited.

So, my guess is that the duplicate helpers are spawning because you have no safeguard on the return script (and perhaps one is needed on the respawn script too) to check whether a helper is already present and, if they are, to not spawn a new one. So, when you return to a map in a hub, the game remembers there was a helper present the first time (and it will still be there), but also runs the return script and spawns a second one.

[Psychojack88]

Oh I see. I was wondering about what about the hub levels in particular was causing the cloning. I only guessed that the hub was reusing the script due to being a hub levels. So the lack of a proper check was the culprit? Okay then, so I just need this "return script check". That's perfect!

Just in case, would you advise this for ACS or Zscript. Just looking to make sure before I go about messing with this.
Where's a good place to find the structure for this kind of check? There a ZDoom wiki page you can point me to to allow me to do this "check return, if already read don't run, if not run" addition to the code.

(Sorry for asking but the original spawner logic was based on NienerWiener's original companion template he posted here some time ago. Just wanted to also understand how things work to improve on coding through this. )

Thanks once again Enjay for the prompt response. I highly appreciate everything you've explained and for making it clear for me to understand what specifically is going on with the script to trigger this issue. I am really grateful for the help!

[Enjay]

It can probably be done in either - but I wouldn't know how to do it in ZScript.

It all depends on what you can detect that will confirm whether a helper has already been spawned or not. For example, I notice that your scripts give an item to the player's inventory. If that item is persistent (i.e. remains in the player's inventory after the helper has spawned) then you could do a check for it in your return script and, if the check finds the inventory item to be present, it will do nothing.

e.g. something like this *might* work:

Code: Select all

SCRIPT "DaisyEternal_Return" RETURN
{
	if (CheckInventory("DaisyEternalProtection") == 0)
		{
				GiveInventory("DaisyEternalProtection", 0x7FFFFFFD);
		}
		
	else 
		{
			delay(1);
		}
}

That checks the player's inventory. If they don't already have a DaisyEternalProtection item, the script gives it to them. If they do have one, the script delays for a tic (probably not needed) and then finishes having done nothing.

There might be a neater way to do it in ZScript.

Also, do you really need to be giving 0x7FFFFFFD copies of the item to the player? I bet it isn't set up for anything like that number to even be possible. (I think the default max for inventory items is 25.)

Also also, thinking about it - do you actually need the return script at all? i.e. when you first enter the map, the enter script will run, and the helper sticks around. Will you ever be in a situation where you are returning to a map where you didn't have a helper the last time you were in the map? So, it *might* be possible just to do away with the return script entirely.

[Psychojack88]

Thank you Enjay for the prompt response. I really appreciate the effort you put into explaining this to me so that I can understand and think things through as I try to patch this.

I'll start with the RETURN script removal method as the first test. Because you are right, there's not really a situation where I could see the helper being away from the player/not in the hub level and then really needing the RETURN script to activate the spawn. Unless it's for an RPG kind of scenario/wad where there are scripted "departures" or separations. Other than that I can't really imagine this being the case. If anything, if this works it would be a really swift and straightforward method to get the results I am looking for. Could always keep the code in case I have need of it for later.

If not I'll give the player inventory check a shot. Even if it doesn't work the foundation is a start. It's straightforward as well and may just need a few additions to make it run properly if it doesn't work at first.

The copies of the item were a universal thing I've noticed in NienerWiener's original template and companion mods on ModDB. If he were still active I would have asked him specifically why this was the case. Perhaps it was the most surefire way to guarantee an infinite or numerous amount of the "item" that allows the spawning in the case of mods that change inventory? Or in the case to ensure maximum compatibility with other wads/gameplay mods at the time? I don't know at this current time, but I'll leave that one well enough alone for now, at least until I know more.

[Psychojack88]

Just wanted to post an update I was able to get the cloning glitch to stop within the ZScript using a check in the Daisy SpawnEventHandler. Thank you @Enjay for the help you have given me and really appreciate the efforts you put to explaining things for me to keep in mind when dealing with the different script types. Much appreciated and thank you so much.

[Enjay]

No worries. Happy to help. I'm glad you got it working.

[Psychojack88]

Thank you so much for helping, Enjay. I'm glad that I was able to make this as compatible as possible with games like Hexen and potentially other wads with similar return scripts. Definitely helps set the base for any rpg-oriented wads or more hub based wads.