The mesh goes invisible when the center of the actor (the actor
) is not in view at certain angles (when it's behind you for example).
It's not exactly a bug, it was an intended engine optimization so that meshes behind you wouldn't get rendered, which for the normal game it works since meshes were not meant to ever be that big, but once you go for something like that, that kind of problem occurs.
Unreal 227 "fixes" this by giving you an option, in the form of a new actor boolean property, to force the mesh to render regardless of where it's located relative to you and your view.
In UT99 however, unfortunately you do not have this option.
However, I also have developed a "fix" for that one, for UT99, since in NW3 I wanted to have "forcefields", and if you were inside one, at certain angles it would disappear, which was a big problem for me.
So what I ended up coming up with was fairly simple: since the mesh disappears when its actor location is behind you, all you have to do is ensure the actor (with the mesh) is always on front of you, at all times (every tick).
From there, to keep the mesh visibly where it's supposed to be, you set the
in such way that the mesh is rendered in the location you actually want it to be rendered at.
establishes where the mesh is rendered, as an offset from the actor's location, or to put it in more technical terms: the real rendering location of any mesh is
Location + PrePivot
, which is a quite neat feature of the engine, which I used and abused for other things other than this kind of fix.
So, you have to do something like this (simplified version):
Code: Select all
var vector RealLocation;
var float RenderDistance;
function update(vector ViewLocation, rotator ViewRotation)
SetLocation(ViewLocation + vector(ViewRotation) * RenderDistance); //set the actor on front of the player, at a distance set by RenderDistance
PrePivot = RealLocation - Location;
This works fairly well most of the time, however due to the order of updates in a tick (when each actor is updated), which is decided by the order each actor was spawned (at least pre-v469, not sure if it will remain like this with the incoming fixes and optimizations), if the
corresponds to another actor other than the
itself (such as a guided Redeemer missile for example), since those actors are generally updated later by being spawned afterwards, the
you use in those cases is highly likely to be outdated by the time the tick finishes, creating a flickering or disappearing effect again if the actor is set to be too close in front of you or if the actor is rotated quickly enough.
For normal cases, such as yours, setting a
to just far away enough, should suffice for the time being.
But if you want to check what I did to solve that problem, as well including some other features (such as only do this processing when you're "inside" the actor, to keep the optimization working when you're not), you can check the
class from NW3, namely from the NWCoreVIII package (all my sources are here: viewtopic.php?t=5638