Most recently I had it when summoning a uef461a.m16sniper but have also had when using MBot_C bots and one or two other things (like bots/meshes from mods such as Rampancy).
I see that bViewTarget is no longer in the list of var (AI Flags) declared at the beginning of Botpack.Bot - anyone have any idea why it is no longer there?
Have a look at class'Pawn': var bool bViewTarget;
If it is defined in class'Bot' again, it shadows the variable in the parent Pawn class. Maybe that was the reason why it was removed from class'Bot'.
"If Origin not in center it be not in center." --Buggie
Barbie wrote: ↑Thu Oct 20, 2022 8:34 pm
Have a look at class'Pawn': var bool bViewTarget;
If it is defined in class'Bot' again, it shadows the variable in the parent Pawn class. Maybe that was the reason why it was removed from class'Bot'.
I see - thanks for that - it certainly looks like the only var bool/AI Flag that appears in the list of vars at the beginning of Engine.Pawn and of Botpack.Bot. So I'm sure you're right about the reason.
I wouldn't have removed that. Backward compability is not given, because there may be code that explicit accesses class'Bot'.bViewTarget while class'Pawn'.bViewTarget implicit or explicit might be accessed at another code statement.
"If Origin not in center it be not in center." --Buggie
I removed it because obscuring variables is an extremely ugly thing to do, especially when you're obscuring a parent class' variable with the intention of using it for the same purpose.
The Core Linker class should redirect imports from mods and other packages, in any case it's the linker that could use a fix here.
Google was not my friend when I searched "uef461a.u", any way I can get my hands on the package and dependencies?
Higor wrote: ↑Sat Oct 22, 2022 1:30 am
Google was not my friend when I searched "uef461a.u", any way I can get my hands on the package and dependencies?
Higor wrote: ↑Sat Oct 22, 2022 1:30 am
I removed it because obscuring variables is an extremely ugly thing to do,
And solution would be a different deal instead of removal, UT has already duplicated classes and this doesn't means that removing them is the solution - is not, all it does is to break things.
Turns out it was only a message.
I caused this when made the game probe the linker a second time as a possible dynamic array (which is how we were able to change Touching[4] into array<> Touching;)