- Posts: 1853
- Joined: Sat Sep 17, 2011 4:32 pm
- Personal rank: Dame. Vandora
- Location: TN, USA
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.
Yes, you did - I've been using it for ages - it works very well indeed, very effective
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...
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.
- Classic 220.127.116.11:7777
- Madruga 18.104.22.168:7777
- Duel 22.214.171.124:6666
- RA 126.96.36.199:8888
- Custom 188.8.131.52:7777
Code: Select all
ScriptWarning: MapGarbage Transient.MapGarbage2 (Function MapGarbage.MapGarbage.ListNumberOfSpecs:011A) describeSpec: invalid ReachSpec index: 649/649 MaxNumFound: I found 649 reachspecs, from 0 to 648.
Code: Select all
Log: ReachSpecs array ends at X value.
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.
CacoFFFYesterday at 12:21 PM
ReachSpec 'api' has always been non-existant in UT.
Moving NavigationPoint funcs to UT would be the last of priorities, until then we have XC_Engine
(Not yet out for v469)
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.
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.
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.
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 ?
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!