[Release] DM-WreckingBall

[UnrealGGecko]

Not a Miley Cyrus reference I swear!
Another map that took me way too long, small 2-8 player DM map.

Things I need especially help/feedback with:
- botpathing, especially the lift
- technical problems

EDIT: Version 1 released!

Code: Select all

-Re-botpathed and added some new actors by Aspide, huge thanks to him!
-added a few extra details in the kitchen and outside,
-aligned a couple of textures.

[sektor2111]

That "JanitorLift" to me makes no sense. Route goes down and back - What's up there ? Other JumpSpots placed in air ? Assuming that Bot can reach there, what will do next ? Falling ? Or just bugging Pawn to gain something ?

[UnrealGGecko]

Yea that's me being bad at botpathing lol

EDIT: Aspide sent me a re-botpathed version with a custom actor, gonna do a few more tweaks, wait for more feedback then release it    
Auto merged new post submitted 23 hours 12 minutes later

---

Version 1 RELEASED! Go back up to the first post to grab it!

[jmartin]

Thanks UG

I'm receiving a Critical Error warning...

Just wondering though, is there an actual wrecking ball in this map?

There should be a wrecking ball with Miley Cyrus hanging on it that crushes people.

[OjitroC]

I'm receiving a Critical Error warning...

There is indeed a wrecking ball in the map!

As the error message indicates, the texture HookSkull is the problem - it is 512 x 512 without mipmaps - the basic D3D renderer can't handle that. Perhaps you have another renderer you can try?

[jmartin]

Got it. Yeah, switched over to software rendering and it ran fine.

Thanks OjitroC

[sektor2111]

Ummm... Nah... I don't get the point for screwing up settings... Not only "TEXTURE" has problems - actually for no purpose, but others too... Navigation Chain from a client game is going into ruins and actors referenced in ReachSpecs are nowhere.

Code: Select all

StaticsCheck: Bork >> LiftExit22 won't be seen in clients. Class has bStatic True and has been screwed to False.
StaticsCheck: Bork >> LiftExit23 won't be seen in clients. Class has bStatic True and has been screwed to False.
...
NoIncomingPath: PathNode90 is not having incoming connections. //It's visible stupid
...
UnReachableNodes: PathNode90 looks much over ground for normal Human Size, check it. //Clearly this one is useless
UnReachableNodes: InventorySpot155 looks much over ground for normal Human Size, check it.
UnReachableNodes: InventorySpot156 looks much over ground for normal Human Size, check it.
UnReachableNodes: InventorySpot157 looks much over ground for normal Human Size, check it.

Inventoryspots described can be a problem or not depending on their item - if available or not. Perhaps those vials are not 100% recommended on those stairs but... here only "run-time" stage can show what's up when these are picked up and Pawn wants to go for Minigun from top passing through stairs.

Other technical problems ?
Let's see that I'm not very interested about "JumpMan" which has similar problems with plain Teleporters... when it comes to "BOTS" not "Bot". It allows routing forward but Pawn not Bot is blocked in front of this node - Any purpose for not allowing generic player that can pick up items ? Even Bots types can be used in DeathMatch not only "Bot" type. Custom things can bring in game such types which would be locked around such a Combo for some reason which I don't get.

Code: Select all

event int SpecialCost(Pawn Seeker)
{
    return 0; //Always routing
}

but

Code: Select all

function Actor SpecialHandling(Pawn Other)
{
    local Bot B;

    if ( !Other.IsA('Bot') ) //Awesome ??? Why ?
        return None;

    if ( (VSize(Location - Other.Location) < 200) 
         && (Abs(Location.Z - Other.Location.Z) < Other.CollisionHeight) )
        return self;

    B = Bot(Other);

    PendingBot = B;
    GotoState('PendingJump');

    return self;
}

C'mon boys...
The logic would be different to me: If "NON-Bot" Pawn won't jump here, then it's advisable to block routing too, right from the start instead of bringing Pawn here and blocking it in front of node... SpecialCost has a purpose which should match somehow with SpecialHandling not doing two things in opposite directions. Also "If" condition if it doesn't match, the code still "return self", in such a stage "if" check has no purpose.

The rest is... Goblin in its hooligan suit...

Code: Select all

LostData: ________________________________________________________________
LostData: ReachSpecs missing from Paths[0-15] 		= 30.
LostData: ReachSpecs missing from upStreamPaths[0-15] 	= 11.
FixedWithSuccess: ReachSpecs successfully attached 	= 41.
FixFailures: ReachSpecs attaching failures - probably no place = 0.
LostData: ________________________________________________________________

   
Auto merged new post submitted 5 hours 39 minutes later

---

And this is map with D3D problem solved using 469b (because 469c was drunk at some "LazyLoader" blah blah). It doesn't crash, either way not using Mips to me makes no sense... Why reinventing the wheel ?

Take this as tutorial in "How Not to Import a Texture": No Mips, No masking - it looks like something felt at bottom of a dark box. But hey, everyone has to change render because this is supposed to be a "Texture".
In end, it can be like this... with ZERO problems.

[UnrealGGecko]

I'll upload a fix probably tomorrow, the non-masked texture actually is on purpose, it's meant to be a like a poster, but I did forget older renderers don't support anything higher than 256x256, and that one texture being this hi-res was dumb by me. Also forgot which texture is meant to have Mips and which do not lol.

EDIT: on second thought, think I'm good, feel free to edit this map if you feel like you can fix anything the others said.

[sektor2111]

It's up on you if you believe me or not, D3D is supporting 512 × 512 and even 1024 × 1024 - this is not a problem at all if Texture is Normal. It ensures a quality view. This "skull" is actually 512 × 512 and... has no problems with all render requirements. Map has grown with 50-60 KB but this is nothing when map is under 2 MB, it's a real UE1 map - after tinkering Nodes a bit I can recommend it as a quality work because...
The rest of design to me it's really good - "WreckingBall" is here properly set as an UT MAP - no complains.

Edit: The rest of "tech" in my view...

Code: Select all

class JumpMan expands JumpSpot;

event int SpecialCost(Pawn Seeker)
{
	if ( Seeker == None || Seeker.bDeleteMe ) //block any lousy call
		return 100000000;
	if ( Seeker.bCanJump || Seeker.bCanFly ) //Only compatibles are allowed. "Flying is the best jump".
	    return 0;
	return 100000000; //Anything else is locked
}

function Actor SpecialHandling(Pawn Other)
{
    local Bot B;

	if ( Other == None || Other.bDeleteMe )
		return None;
	if ( !Other.bCanJump && !Other.bCanFly ) //Deny all incompatibles suddenly joined in spot
		return None;
	if ( Other.IsA('Bot')) //Assign Bot only if Pawn is Bot and nothing else.
		B = Bot(Other);
	if ( B != None ) // if exists "The Bot" let it do what knows to do
	{
    		PendingBot = B;
		GotoState('PendingJump');
		return self;
	}
	return self; //Others are allowed to manage this spot with their own code - if are not losers (Humans, Botz, Bots, Skaarj, Krall, etc.)
}

   
Auto merged new post submitted 16 hours 57 minutes later

---

After testing game in 469c with plain stock Bot (MBots are not failing that ugly) I can see what's up at "JanitorLift" with that second forced attached combo and causing paths through walls when lift is moving and doing lousy moves. That's f..kery not pathing ... Simply the second attached combo is useless, all UT lifts are supporting 3-4 entries/exits and Bot understands when lift is moving without attempts to move through walls trying to follow attached paths that are pulled through map's BSP. Hint for brain poking: Use DrawPaths mutator and look at spot - "nice" no doubts...
On the other spot, "JumpMan2" aka "BootsWindow" does more damage than it helps, it's not even needed, all is getting connected normally...

I remember what Hook said in the past: K.I.S.S. = Keep It Simple Stupid.