[Final] 3072 The Insane Tower

[papercoffee]

The rotation thing:
wow... I don't know but this never happened to me.
Can someone please test this as well and confirm Aldebaran's find?!

@Swanky you tested the map ...do you noticed something like this?

The weapon hide thing:
...I know that UT don't really like warp-zones. You get little hiccups or odd weapon display ...but I didn't notice that the weapons completely disappear. Could you still shoot?
And is this a Super-Shock Rifle?

[Aldebaran]

I have to mention that i tested the maps on a dedicated server, not local.
Perhaps this make a difference?

I use a Shockrifle with Zeroping integrated.

EDIT ( some days later ):
I have tested the map with UT99 clients v4.51 and v4.36.
The Problem does not appear with v4.36, so v4.51 can't handle these warpzones in the right way.

[Swanky]

Experienced getting stuck once due to the Warpzone, just no crashes or anything, could move on thin air before I accidently RocketLauncher.

[papercoffee]

Experienced getting stuck once due to the Warpzone, just no crashes or anything, could move on thin air before I accidently RocketLauncher.

I have no clue how to fix this... especially since I can't detect the cause.
This getting stuck thing happened once on the top warp-zone from the red war goddess section but I couldn't reproduce it.

[Barbie]

I have to mention that i tested the maps on a dedicated server, not local.
Perhaps this make a difference?

A lot of things do work in another way on net play from my experience.

My guess in general for the warp zone mysteries: On some code lines I noticed that a pawn is divided horizontally into sections:

Code: Select all

class Pawn extends Actor abstract native nativereplication;

// Additional pawn region information.
var PointRegion FootRegion;
var PointRegion HeadRegion;

(And furthermore there are events when Head-/FootRegion has changed.) Because your warp zones are horizontally too, there are areas where a pawn is in one region with his head and in another region with his feet. Maybe this causes problems.

[papercoffee]

Sooooo ....I have to change the portal sheets into a 45° angle to fix this?

[sektor2111]

Meh... I'm suspecting other things after working at that MH-3072...
Player being in a zone, server sends info about nearby stuff (also that bStasis thing), hey, we have a player go send render info.
The problem comes that warp-zones are in other areas without player. With an imagination effort try to figure if me server I'm starting to send info about actors which are not in that zone - pretty crappy to load at maximum player slot, right ? We can deliver generally info about actors "meshed" > weapons, decorations, pawns, projectiles (oh well). It's not a fun how much resources are spent, right ?
Personally I believe warp zones must be used in decent loaded levels - no skybox related things, some actors can be set for relevance VIA MyLevel, and such simple stuff. Else effect based on overload returns a garbage Net game which I cannot be sure if is that much desired.

In my map due to some delay and net things I could figured some of those far away TriggeredLights initially turned off, a bit of flickering when I was entering first time in that zone (using a slow machine for tests) - I figured being LATER updated actors. Given annoying effects, I was changing some setup related to net stuff as long as I had only 19 such actors so is not that excessive for being often updated, else I couldn't get rid of those things happening. Then if you have stuff like that in other areas not immediately visible directly, engine will not process their state for player which is pretty far - right into other zone - warp zones seems to not be an exception. I have learned several things while I did a revision to that LongCorridor_d+ and during this time I was writing my relevance stuff which I'm using VIA UScript and which is configurable not fixed native. Else monsters in VIA warp zones at a moment were like stuck in animations, simply engine did not sent info about them at a moment for saving bandwidth - this engine is for old times from Dial-Up ages anyway so take your wise decisions at this point.

Edit: As a shorter note. Engine doesn't seems to update visual related things from actors which are not located in the same zone as the player, except those relevant ones. So, yes, Warp-Zones have problems anyway toward updating actors...

[papercoffee]

Edit: As a shorter note. Engine doesn't seems to update visual related things from actors which are not located in the same zone as the player, except those relevant ones. So, yes, Warp-Zones have problems anyway toward updating actors...

And how can I fix this?

Edit-----------------------------------
Maybe @Higor or @Shadow can explain this?

[papercoffee]

Ooookeeey ...Feralidragon helped me a little bit. He has no UT and therefore no UEd installed but he gave me this.
It will fix the portals for online game.

Well, there's another way in the case of your specific map.
In specifically small maps where you really intend for every area to remain relevant, you can embed a small mod in the map itself which makes every spawned actors to be always relevant.

You could ask someone to do this, but the class and code itself would be something like:

Code: Select all

class AlwaysRelevantSpawns extends SpawnNotify;

function Actor SpawnNotification(Actor A)
{
	A.bAlwaysRelevant = true;
	return A;
}

and you would just need to add it somewhere to your map and everything would work.

Can someone help me and make this usable?
I have no script knowledge and don't know what to do with that code snippet.

[Barbie]

Sooooo ....I have to change the portal sheets into a 45° angle to fix this?

Assuming that Head- and FootZone are identical in shape and that they are congruent in z-axis: what is the orientation of a sheet (warp zone entry) where Head- and FootZone are always in the same zone? The price for the correct answer is a warp field generator. Extra tachyons will be submitted for an explanation.

bAlwaysRelevant = true;

I doubt that this will change the wired behaviour of warp zones in net play: bAlwaysRelevant of an Actor causes that all its changes are transmitted to net clients (on the cost of bandwidth). But mentioned problems concern the player itself in the moment of changing zones and I guess a player is always relevant to itself ;o)

[papercoffee]

Assuming that Head- and FootZone are identical in shape and that they are congruent in z-axis: what is the orientation of a sheet (warp zone entry) where Head- and FootZone are always in the same zone? The price for the correct answer is a warp field generator. Extra tachyons will be submitted for an explanation.

I don't even get the question...

bAlwaysRelevant = true;

I doubt that this will change the wired behaviour of warp zones in net play: bAlwaysRelevant of an Actor causes that all its changes are transmitted to net clients (on the cost of bandwidth). But mentioned problems concern the player itself in the moment of changing zones and I guess a player is always relevant to itself ;o)

Ok then how can I fix the problem that some player (online) seem to get turned around after entering/leaving a warp-zone?
Btw. You tested the last build on your server ...did you notice this as well or is it only Aldebaran who has trouble with the map?

[papercoffee]

It's so sad that those heavily edited lamps don't work as clock hands in UT. They look great in Unreal.

Zwischenablage09.png

I edited the gears in the clock thanks to Barbie.
@Barbie I couldn't use your version of the map because you produced too man HOMs ...I don't know why my last stable version is not affected by a rebuild (in both Editors). But I could use your FastSprocket version and made the clock gear new.

I have to iron out some little quirks with bot pathing and the clock hands and will then upload the fixed version.