MH-Wolf3D

[OjitroC]

That crash will happen in any environment and in any map - I've just put a bunch of DoomPawns into a MH-GardenofDeath map to play off-line in 469c. Playing the map from the Editor, I immediately got this crash

Code: Select all

Critical: HeavyTrooper Autoplay.HeavyTrooper20 (State DoomPawns.HeavyTrooper.AttackEnemy:002F) Runaway loop detected (over 10000000 iterations)
Critical: Windows GetLastError: Not enough memory. (8)
Exit: Executing UObject::StaticShutdownAfterError
Exit: Executing UWindowsClient::ShutdownAfterError
Exit: UGalaxyAudioSubsystem::ShutdownAfterError
Log: DirectDraw End Mode
Exit: UOpenGLRenderDevice::ShutdownAfterError
Critical: FFrame::Serialize
Critical: AActor::ProcessState
Critical: Object HeavyTrooper Autoplay.HeavyTrooper20, Old State State DoomPawns.HeavyTrooper.AttackEnemy, New State State DoomPawns.HeavyTrooper.AttackEnemy
Critical: AActor::Tick
Critical: TickAllActors
Critical: ULevel::Tick
Critical: (NetMode=0)
Critical: TickLevel
Critical: UGameEngine::Tick
Critical: UpdateWorld
Critical: MainLoop

[sektor2111]

Bingo !

Edit: However, MH-Wolf3D is a map that can be still played after "a bit" of patching.
A potential Patch plugin will solve problem right in first tick of the game... All junks can be happily replaced with something else and map will get back to normal... if you want to play it... because in original state is frankly useless as the package used for doing it.
Edit2:
Right now I'll stop looking at those codes because all I see it's just stupid. Pawn going to alarm - alarm should destroy Pawn reached here. Code says destroy but keep assigning next alarm and once again "Goto('Begin')" - yeah, sure, destroyed Pawn should go ahead, no doubt it will do that...
Subject of type "losers muppets".

Code: Select all

		if( Physics==PHYS_None )
		{
			if( bCanFly )
				SetPhysics(PHYS_Flying);
			else if( Region.Zone.bWaterZone )
				SetPhysics(PHYS_Swimming);
			else SetPhysics(PHYS_Falling);
		}

I'm wondering if this Pawn capable to fly is thrown in water and Physics flying are set right in first case. Next... if Pawn is in water we want physics swimming - if I'm looking at bCanSwim property in 469c - it's False. Let me know if Pawn will ever swim. If yes, let me know what are logic considerations for swimming if bCanSwim = False.

[OjitroC]

Perhaps though just started playing MH-Wolf3dv5 off-line from the Editor and got the following crash which I have never seen before

Code: Select all

Critical: Failed to find function PlayMyAnim in enforcer Autoplay.enforcer3 Global 0
Critical: Windows GetLastError: Not enough memory. (8)
Exit: Executing UObject::StaticShutdownAfterError
Exit: Executing UWindowsClient::ShutdownAfterError
Exit: UGalaxyAudioSubsystem::ShutdownAfterError
Log: DirectDraw End Mode
Exit: UOpenGLRenderDevice::ShutdownAfterError
Critical: AActor::ProcessState
Critical: Object enforcer Autoplay.enforcer3, Old State State Botpack.TournamentWeapon.Pickup, New State State Botpack.TournamentWeapon.Pickup

For me, the map is a real pain to set up because of the file name conflicts with a number of other .u and .uax files, not least with the Wolf3D mod produced by Leo.

[Buggie]

It is map itself (embed code). Not related to other packages. I almost catch bug by tail. Still in debug.

There one pitfall - you (any player) need die from this WolfSS monsters. So if you try run locally with god mode, then no crash happen. No player deaths = no crashes.

So for crash need run with enforcer in practice session. After few deaths game can crash. It is random.

---

Automatically merged

That crash will happen in any environment and in any map - I've just put a bunch of DoomPawns into a MH-GardenofDeath map to play off-line in 469c. Playing the map from the Editor, I immediately got this crash

Code: Select all

Critical: HeavyTrooper Autoplay.HeavyTrooper20 (State DoomPawns.HeavyTrooper.AttackEnemy:002F) Runaway loop detected (over 10000000 iterations)

Well in map embed only part of DoomPawns. So even if I fix it here, it possible need additional review code in DoomPawns package. And possible out conformed version for it.

[OjitroC]

Well in map embed only part of DoomPawns. So even if I fix it here, it possible need additional review code in DoomPawns package. And possible out conformed version for it.

Indeed that is true - there is a problem with the subclasses of DoomTrooper. There is or are different problems with some of the other pawns like

Code: Select all

ScriptWarning: Demon MH-XV-DoomHell-GardenOfDeath.Demon437 (State DoomPawns.Demon.Idling:039E) Accessed None 'Dinner'
ScriptWarning: Skull MH-XV-DoomHell-GardenOfDeath.Skull0 (State DoomPawns.Skull.AttackEnemy:012E) Accessed None 'Enemy'

Though the Skull's AttackEnemy Accessed None doesn't give rise to a crash.

[Eternity]

It is map itself (embed code). Not related to other packages. I almost catch bug by tail. Still in debug.

There one pitfall - you (any player) need die from this WolfSS monsters. So if you try run locally with god mode, then no crash happen. No player deaths = no crashes.

So for crash need run with enforcer in practice session. After few deaths game can crash. It is random.

---

It could be the same problem my test server setup already has workaround for... I'll try to test it again when come home, after tomorrow. (Btw, that XV test server has the same setup and is still there ready for any tests...)

[OjitroC]

Next... if Pawn is in water we want physics swimming - if I'm looking at bCanSwim property in 469c - it's False. Let me know if Pawn will ever swim. If yes, let me know what are logic considerations for swimming if bCanSwim = False.

bCanSwin=True is set in DoomPawns.DoomTroop (the parent class of the HeavyTrooper from which WolfSS is subclassed).

As a matter of interest the Skaarj Trooper inherits bCanSwim=False from the class Pawn (check the Hidden Properties).

There is obviously more than one type of crash in this map and each crash has a different cause. The runaway loop crashes (HuntingEnemy, etc) occur in other maps with DoomPawns per se rather than with the part of DoomPawns embedded in MH-Wolf3dv5 - so must be unrelated to this map.

It looks like some of the code/functions of DoomPawns (function PlayMyAnim for example) is being called outside of DoomPawns, hence my crash with the Enforcer - put crudely, something somewhere is leaking.

[Buggie]

v6

- Fixed crashes.
- Improved paths.

Updated in first post: viewtopic.php?f=5&t=14763

Thanks for help all, ESP Anth and Marco (DoomPawns creator).

[OjitroC]

That's good. Is it possible to say what caused the crashes?

[Buggie]

Mistake in state code.
Partially it related to next bugs:
https://github.com/OldUnreal/UnrealTour ... issues/422
https://github.com/OldUnreal/UnrealTour ... issues/835

In short: Attempt change state of actor on few edge cases can produce crash, because on another actors called wrong state or used unexists offset in state, unexists state functions and so on.

[Barbie]

Just played it online - without crash!

[OjitroC]

Am I right in thinking that these are the changes to the code of DoomPawns.DoomPawns

Code: Select all

{
		WalkBob.X = PlayMyAnim('Melee');
		Sleep(WalkBob.X);
	} else if( bHasRangedAttack ) {
		WalkBob.X = PlayMyAnim('Fire');
		Sleep(WalkBob.X);
	}

Code: Select all

function bool IsAlivePawn2(Pawn P)
{
	return P != None && !P.bDeleteMe && P.Health > 0;
}

Code: Select all

function bool SetEnemy( Pawn NewEnemy ) // Simply.
{
	if ( !IsAlivePawn2(NewEnemy) ||
	     NewEnemy == self ||
		 NewEnemy.IsA('Spectator') ||
		 NewEnemy.IsA('FlockPawn') ||
		 NewEnemy.GetStateName() == 'PlayerWaiting' ||
	    (!bCanWalk && !bCanFly && !NewEnemy.FootRegion.Zone.bWaterZone) )
	    return false;
	if( NewEnemy==None || NewEnemy.Health<=0 || NewEnemy.Class==Class || Enemy==NewEnemy ) Return false;
	Enemy = NewEnemy;
	Return True;
}

and that if I amend the code of DoomPawns.u accordingly, I should remove the possibility of any of the crashes noted in this thread?

[Buggie]

Code: Select all

{
		WalkBob.X = PlayMyAnim('Melee');
		Sleep(WalkBob.X);
	} else if( bHasRangedAttack ) {
		WalkBob.X = PlayMyAnim('Fire');
		Sleep(WalkBob.X);
	}

It is for crash fix. One you miss in HeavyTrooper.

In general you must avoid use in-line call functions in parameters of Latent functions. Better avoid any such calls at all. Save to variable, variable pass to function as parameter.
This will be fixed in v469d, but before result vary. in best case it can randomly crash.
In worst case (436) can stuck with 100% CPU load. Possible you need reboot PC after such if not able reach desktop and kill UT.

Also avoid stuff like chained execution:
if (myfunc() && doanother()) ...
This too dangerous.

I talk only about state code. Outside state code it is fine.

In general it is fine in state code too until you not change state of actor inside calls.
But it is really thin ice. Better avoid that.

For example DoomPawns be good with PlayMyAnim, but it override in subclass, where function start change state. So you never be sure. Even if you make function final, someone can alter your code and get bad stuff.

---

Automatically merged

Other changes from previous tune. And not all suitable for doom monsters. For example original Doom monsters in game attack each other. In Wolf3D - no. So I blocked it. At least when class match. Not know what proper for UT.

[sektor2111]

Yeah, interesting... However at "setenemy" my solution is different as long as we do have Biterfish and some "AnygryBirds" from community which somebody else can mix and these will only stupidly dying without doing anything.
Also is fascinating terms of performance - instead of checking "PlayerWaiting", I'd rather prefer something more simple (disregarding useless comment "//simply"). Testing bHidden and bCollideActors - both checks are faster than testing state name, and discard attacking something that doesn't collide anyway...
The rest of issues from states are getting vanished when people will understand How to wrap functions and not using particular functions only in certain state.
One of such things is FindViewSpot specific to state hunting. Any call outside of the state is crashing. By using this outside of state NOTHING bad will happen. Yes, MBots are not crashing here and I like those "aliens" running with and without XC_Engine. I was chasing functions from states for not getting called from another state - that's a problem based on Engine design. Modders and coders should adapt code at this design instead of reinventing warm water. Why did they even put FindViewSpot inside state ? States are changing faster and timings are not always perfect, messing with "dedicated-at-this-state" functions is a dumb practice.

[Eternity]

Monster might attack Player that has left - Has anybody thought about that ? It's just a mindless loop that doesn't break.

It is exactly that problem i did mean...
v436/v451 has serious issue in class 'ScriptedPawn' and some of its subclasses that in specific conditions (on Player logout, on other Pawn destroyed or whatsoever) may produce a runaway loop crash or just application hang (if that crash not handled properly). Involved functions are "SetEnemy", "AttitudeTo" and "WhatToDoNext". Some mods have inherited and/or copy-pasted this bug. Some mods have similar bugs (e.g., DC-Pawns3).
A workaround for this problem was ugly, but was no any better solution found, and it was still better than random crash now and then.
It appears, this problem is (or at least should have been) fixed in the v469c release by altering a States processing behavior, but some related issues may still exist (unless proven otherwise by proper tests)...