Player cannot rotate in map MH-[WKA]SpaceMonsters

[OjitroC]

There's a few other 'odd' things as well

Spoiler

ScriptWarning: Mover MH-[WKA]SpaceMonsters.Mover53 (State Engine.Mover.TriggerControl:0031) Accessed None
ScriptWarning: Mover MH-[WKA]SpaceMonsters.Mover54 (State Engine.Mover.TriggerControl:0031) Accessed None
ScriptWarning: Mover MH-[WKA]SpaceMonsters.Mover55 (State Engine.Mover.TriggerControl:0031) Accessed None
ScriptWarning: Mover MH-[WKA]SpaceMonsters.Mover56 (State Engine.Mover.TriggerControl:0031) Accessed None

ScriptLog: MH-[WKA]SpaceMonsters.MSSquid0 Error - PlayRangedAttack should be implemented in subclass

[Buggie]

It looks like there are several (or very many) problematic Movers. I deleted the part and when viewing, before starting the game, lock does not occur. However, once the game starts, a lock occurs.

It looks like map is very buggy and it is not clear whether it makes any sense to reanimate it.

Perhaps if you remove all Movers and recreate them by replacing them with simpler ones, then the problem can be eliminated.

Instead of all these various doors, put the usual simple moving blocks. But this is a huge amount of work. I'm not sure if it's worth it.

[sektor2111]

If I'm thinking back without XC_Engine, some of those pupaes ( if not even all ) can be killed before to open that stupid platform and pupae boss has always head directly visible being an easy target, this lacks at logic settings, as overall that zone concept for me it's less intelligent.

[Buggie]

In theory, you can look for problematic movers with binary search.
Select one Mover. Through the context menu, select all Movers. Click the "show only selection" button.
With ctrl + alt pressed, select the Movers part, delete them.
Rebuild the geometry. Save the map with a new name. In the dedicatated server, execute servertravel on the new map.
In the client, we check whether there is a lock before the start of the game and after its start. If there is no lock, then we reconnect several times to make sure that the problem is fixed, and not temporarily disappear.

If the problem persists, try to remove some of the remaining Movers. and repeat the whole process again.

If resolved, then load the previous version of the map into the editor and try to delete a smaller number of Movers.

After the search has narrowed down to one Movers, we correct it in the original map and repeat the process again.

And so until all problematic Movers are found and fixed.

Long and very laborious.

There is a slightly simpler option - to outline an exemplary group of Movers, upon removal of which the problem disappears and just recreate them all.

A little faster, but still quite laborious.



Perhaps it will be easiest for Barbie to add a message when entering this level - "if you have a locked rotation, click the Windows button and go back to UT." Or another option for such a solution if the problem arises not only on Windows.
Or simply delete this map from the server.

[Barbie]

If I could reproduce the error, I'd search for it... But every time I run this map there is no issue for me.

[Eternity]

I could not reproduce that problem with locked rotation too.
The only significant issue i have seen with this map is RotatingMover0 and RotatingMover1 that work improperly and block players.

[Buggie]

Barbie, if you on Windows, try install UT from links above. Maybe it help you reproduce issue.
I even use default Direct3D render. Nothing custom.

Also you can simple replace all Movers on level with your own.

I can test map, if you post file here.

[OjitroC]

I can test map, if you post file here.

The map is on Shrimp's site https://unrealarchive.org/maps/unreal- ... 1885f.html.

As a matter of interest, do you still get the issue if you use an up to date renderer?

[sektor2111]

Good luck with that default D3D render...

[OjitroC]

Good luck with that default D3D render...

That's what I thought - but I'm not sure that it will run with that old renderer as I tried to load the map with it and got the usual 'oversized textures' message (perhaps that's due to my settings for that renderer though).

[Buggie]

Usually I use D3D9 Render. But lock exists on both renders.

[OjitroC]

Usually I use D3D9 Render. But lock exists on both renders.

I see - from what you said I thought you meant the D3DDrv renderer.

Since the lock issue isn't intrinsic to the map in that the issue only affects certain players, that suggests it is something to do with those players' 'setup' and the way forward might be to try to identify what (if anything) is common to the setup of affected players?

[Red_Fist]

Nope, not a map for me I despise that jumping crap.

Seems like the map has a lot of problems, then those crushing movers.

[Buggie]

Judging by what is known, the map contains a large number of errors that lead to the indicated problems.
However, something else is needed for the lock to appear.
Perhaps the turn lock is part of the engine’s work, and early exit or some kind of execution branch, due to errors, does not remove this lock.
Changing the active window produces a code that sets and removes the lock, so this solves the problem.
This also explains why, in rare cases, loсk does not happen - some conditions are not met at the entrance, and the code runs on a different branch.
It is possible that there is a bug in the UT code that is triggered by map errors. And this bug does not exist in all UT builds, or appears only if there are some OS features.

Based on this information, the only possible solution to the problem is to correct the map, since it is impossible to change the UT code for clients.

[Barbie]

I have a nearly vanilla UT installation in a VM and the problem occurs there. But if I check Options > Preferences > Input > Auto Aim, the problem vanishes. (UT runs in window mode there and the mouse even didn't appear outside the UT window before.)