UT99.org | Unreal Tournament Community

I think the bot teleporter issue can be handled.

The only thing is to make sure the bot roaming is enforced away from the teleporter so it prevent teleport blocking issue in team games. But the bot can roam at a certain distance as well but not too far.

Tbh there can be an increased enhancement on the bot's AI. I'm not sure how to exactly fit in the approval of Epic's intention other than fixing up possible game-breaking ability. Will discuss this, but I gotta experiment more with the regular UT bots. I'm sure other bot lover can also point out the bot issue and what's causing it so we can see what we can do about it.

I'm not having a clue why it's that hard to look at map AS-Rook having items behind teleporters and how bot returns to base with no issues, else Teleporter has VELOCITY settings, do use these... I'm playing a lot of games with Bots - in fact NO GAME without Bots, as long as I use that TelTweak thing No bot will ever lock Teleporter because if he goes crazy, Teleporter is blowing it up. Yes, hard-way works all time. I think I posted this already, can we get into serious problems now ? This is a pity.

sektor2111 wrote: ↑Wed Apr 15, 2020 6:18 pm I use that TelTweak thing No bot will ever lock Teleporter because if he goes crazy, Teleporter is blowing it up. Yes, hard-way works all time .. I think I posted this already

Yes, you did - I've been using it for ages - it works very well indeed, very effective

To the point.
Teleporter is heading Pawn to a location. When said teleporter Target is receiving pawn, "Accept" is called that function, it should made sure about pawn's featured movement capabilities and doing a check for physics vs zone, exactly here, a few lines - nothing to do with Bot, including FALLING player which was WALKING in Teleporter and blocking it exactly AS BOT does. Not a single time I blocked teleporters against rushing - just for fun.
Hey, you can update main Engine file and conform it with original plain Engine and... hello everybody, now I'm falling unable to block Teleporter...
That's all about "updates", for fans of Vanilla UT, previous mutator might be helpful...

New random errors....

Hi,

First of all, thanks to do this amazing job to keep ut99 alive!

Anth, what do you think about porting ucc to ARM platform? Would be amazing to deploy a server on a raspberry pi! =D

How is going the mac port? Do you still accepting beta testers on mac platform? Im realy tired of using windows virtual machine to play UT hahaha

Thanks in advance.

59) A way to let attached actors to follow the pitch and roll of the base actor. For now when an actor is attached to another actor, it will only follow its yaw;

60) Making 469 to work on older systems like ALL predecessors...

sektor2111 wrote: ↑Mon May 04, 2020 10:31 am 60) Making 469 to work on older systems like ALL predecessors...

Yeah man, suck on this 65C02. Look at all those hertz!

I'm more interested on it actually working under Wine, I've got no time machines for this.

News in 469 only... You can remove that warning because it doesn't make any sense - 436 440 451 doesn't have it. Just give me: Start = None, End = None, 0, 0 because this is the logic result of a None in this case... and such a report: Or hint me how to find specs without using "paths undefine" command... and without to start counting them one by one until I'm hitting boundary.

Next Stage: UZ
Ferali's map whatever Blice is NEVER compressed UZ. U227 is compressing it but, doesn't have compatibility with UT.
How did I see that won't compress ? After 2 minutes TaskManager was showing 0 bytes I/O writes and CPU goes to 100% for 1 Core. It loops.
I recommend a Warning or anything else instead of waiting a never ending compression task.

That Warning doesn't exist in UT and neither in UGold227 so it was ADDED - before "last priorities" - I might ask: Why ? I don't get what for, because like I said, I can have reachspecs at UScript Level until Start = None and End = None, and then listing stops because there is no reason to move ahead - or else it will crash Editor.
Given newer "ScriptWarning" "user made" not "Epic made" I don't have plans with this Editor... Any of older Editors works without flaws here and no warning is pointed anywhere.

I know that I could use XC_Engine but I wanted something simple out of XC_Engine - it worked, and it works. DescribeSpec function has been already modified and this is one of useful things which plain UT has - get it back or let me revert it with a Boolean variable "bUseOldDesc" because I did not asked any "fix" here.

DescribeSpec accessing memory outside of the dynamic array is undefined behaviour.
ReachSpec results beyond the maximum may put you outside of allocated memory in the worst case, and may return a reachSpec with up to two pointers to deallocated actors.
Both yield a possibility of causing a Segmentation fault.

The code now prevents any access outside of the reachspec array and issues a warning when attempting to do so, and the warning stays.

I did not say to access memory in this case.
If UScript coder is Moron (like me) you can simply return some HARD-CODED zero-ed results for any Number out of said Array Without trying to access anything over boundaries - like Chris said elsewhere... Why accessing them if these do not exist ? Return zero and an InfoLog more useful... which I can happily capture as string and using it as direct response. Yes, I did such things when I caused my Memory reporting tools and ticks, I used Log printed.
Yes, in one of my lab testing sessions, by enforcing DescribeSpecs much over array, I had to reboot machine - seriously speaking. The Flaw here is trying to get something from a nothing instead of a decent TEXT and Null values, and no memory operations from any kind if we are over board. Even If I ask DescribeSpec 100022343 I should get None None 0 0 instead of accessing that table nearby computer, c'mon. Is that hard to define anti-moron constants ?

Next point: Geometry hit
Said map CTF-Valley has a "wall" which in fact is a sort of non climbable slant, not a wall and not a navigable surface. However engine is driving pawn into a constant run in place with less hopes to pass. OldsKool type fix - cover crap with a BlockAll smoothing movement a bit - an old fox mapper know the trick but not new comers.
PLEASE call Hitwall for any surface which is not navigable more exactly if pawn is sliding on a surface with certain 70 degrees angle, try to call a "hitwall" instead of a fake Plane field never usable as a plane field. I got tired of how many maps have this dumbness because of design bran-fart and making a mess. At this moment only vertical surfaces are walls even if other angles have the same barrier property - total blockers and they should be WALL from Monday to Sunday.
Else... Cause a movement Jump recommendation (like around ledges) if HitWall is damaging BT - not sure about this.

Edit:
ScriptedPawn - I see State Guarding probably unchanged, Enemy whatever called. Pawn actually can take damage without any enemy, just because... it's possible. Berserker do looks original. Codes are stripped here ?

The thing is, out-of-bounds indexes are not supposed to be calculated in the first place. They suggest an error in whatever algorithm originates them. Any checks for their validity should be stripped from a Release build, as they, like any other branching code, may impact performance.

This is also why I prefer Rust over C++, but you can't really want luxuries when you work with such old source code that predates even proper standardization of C++ compliance in compilers!