XC_Engine megathread

Post Reply
User avatar
sektor2111
Godlike
Posts: 6403
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_Engine megathread

Post by sektor2111 »

I might have a recommendation toward XC_EditorAdds if it's possible...
Select "these two" Navigation Nodes and launch a builder with two boolean values:
- bLinkPoints - with optional ReachSpec definition - reachFlags more exactly;
- bDisconnectPoints - I might want to remove useless "Imposible-To-Jump-At-Low-Skill" routes but connecting other important ones.

By demanding manually aerial connections we might have Jet type maps, aerial alarms, etc.

Or hint me with a code non transient that can be used in Editor for making manual connections...
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

Re: XC_Engine megathread

Post by Higor »

That's too much of a hassle to do, when said path changes can be easily achieved by slapping BlockedPath actors in the middle of a route you don't want traversed and more path nodes in routes you want to ensure traversal.
This path rebuilder follows completely different rules, therefore, you need to [re-learn and] apply completely different pathing methods.

==
On the issue of the netcode, I've made a huge (still experimental) achievement, which is letting the server artificially cap a specific client's update rate based on bandwidth saturation and the client's own framerate.
This means a 120 tickrate server can update clients at rates lower than that, saving up a lot of unnecessarily wasted resources.

The results have been great so far, testing on 120 tickrate on MH with 750 open channels (half of them pawns).
So far it's shown to be playable for clients with netspeed as low as 12000, I assume ANY other scenario where there's no channel overload will run smooth without a problem at such high tickrates.

I guess next is making the server's main loop use super precise timers... I'll figure out something about that.
User avatar
The_Cowboy
Skilled
Posts: 165
Joined: Mon Jan 24, 2011 3:22 am
Personal rank: Codezilla

Re: XC_Engine megathread

Post by The_Cowboy »

Higor wrote: On the issue of the netcode, I've made a huge (still experimental) achievement, which is letting the server artificially cap a specific client's update rate based on bandwidth saturation and the client's own framerate.
This means a 120 tickrate server can update clients at rates lower than that, saving up a lot of unnecessarily wasted resources.
Sounds promising. I am watching this thread now.
Feralidragon wrote:Trial and error is sometimes better than any tutorial, because we learn how it works for ourselfs, which kills any doubts about anything :tu:
Patreon: https://www.patreon.com/FreeandOpen
User avatar
sektor2111
Godlike
Posts: 6403
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_Engine megathread

Post by sektor2111 »

Higor wrote:That's too much of a hassle to do, when said path changes can be easily achieved by slapping BlockedPath actors in the middle of a route you don't want traversed and more path nodes in routes you want to ensure traversal.
Good, and then I will use my "methods" particularly optimized depending on Level, doing nodes with "SpecialHandling" and returning pawn to whatever target.
Higor wrote:...The results have been great so far, testing on 120 tickrate on MH with 750 open channels (half of them pawns).
So far it's shown to be playable for clients with netspeed as low as 12000,...
I'm really hoping a better update for ScriptePawn moving like on stairs when are going down from a ramp - MH-Face and similar ones (okay MH-Face is not a MH map, it's just a sample about what I mean). If you still did not see yet, Scriptedpawn has a borked movement updated on Z axis which I was hoping to see fixed as long as in UScript I'm not sure if I can trigger a Net Update for such case or I don't get the "How To"... or it's about NetPriority (which I did not tested yet)...
I gotta preserve some time for UT next week-end because I want to do some research.
Higor wrote: This path rebuilder follows completely different rules, therefore, you need to [re-learn and] apply completely different pathing methods.
Actually this path rebuilder has the same problems here in which I learned to DELETE messed up paths like these:
Polge's_Document wrote: In some situations, bots may get stuck on the edge of a ledge where it runs into a wall. This occurs because of a threshold problem. Bots won't jump off ledges until the angle of their destination is greater than 45 degrees from the ledge direction. If they run into a wall right around this threshold, they may get confused. The solution is to adjust the NavigationPoint they were trying to reach, or add an intermediate PathNode.
In such case Bot is acting in the same way like in original builder because probably Scout is not stopping at ledges and is a moron pawn used as reference happily created by Polge and incompatible with Bot in more ways - (thanks to myself because MBot is not that dumb-ass). Solution so far is editing Navigation Nodes manually but I would like a quick solution. If it's not possible I can live with my methods because Barbie was so kind to help me in translating numbers into words and for me this is a jewel in tweaking Level, even if it's a slow method requiring extra-attention. At least in 2019 I can do 100 times better paths than I did in 2012, by combining these adds.
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

Re: XC_Engine megathread

Post by Higor »

The new path builder allows you to turn this
Rebuilder_Slope1.PNG
Rebuilder_Slope1.PNG (102.79 KiB) Viewed 991 times
Into this
Rebuilder_Slope2.PNG
Rebuilder_Slope2.PNG (80.07 KiB) Viewed 991 times
Unlike the old builder, you can put as many path nodes you want in small areas without creating a navigation mess.
You can have straight paths with nodes at 1999 distance to each other, and junctions with 20 nodes at 100 distance each without problems.
User avatar
sektor2111
Godlike
Posts: 6403
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_Engine megathread

Post by sektor2111 »

I understand the mitigation, I had maps having already more "way-down" routes, one of them being the evil from stage. In such case my wish was to NOT load more reachSpecs just because another reachSpec should not be there. I'd rather prefer to REMOVE the one having no purpose, that's why disconnecting it it's way more suitable and generating less data in complex maps, to not mention the same loops (not described by Polge) when Bot is trying to reach down through the hole but it's failing landing on the same platform due to EAdjustJump(). More stock maps have the same problem over here, solution is a blocker making moron to bump into it and fall through, but this also it's not suitable in all spots. In this case Disconnecting evil path is the answer, or using a combo (more reachSpecs).
By using current builder indeed I can demand some connections but sometimes I really don't need all those "go down" added as long as one or two paths are enough. Patch plugins for some stock maps are aiming exactly destruction of these evils full of nodes but also having these FAKE jumps where Bot won't manage to move properly.
But... nvm... In such cases I can remove them manually or I'll try to write something in a builder created for this task having a single purpose: set evil reachSpec index to -1. Mad reachSpec will stay in map but it won't be used. Probably in this week-end if I won't be gone elsewhere I'll try to write a quicker basic disconnecting feature - this one might help even to remove paths from combos having Impossible routes... I know such two maps recently described in category "nice/great ones". I still don't get these "nice/great" terms as long as I could see those problems in less than 10 minutes.

EDIT: Routines which I wrote today seems to work (week-end will be relaxed - time to drive deeply in the nature...), the problem comes with PrunedPaths if some of them will attempt some lousy jumps, here I think I will elect a complete removal of them because... it was one of my decisions and... last XC stuff seems to... not use these as well. At least here we do have a common "view"... which is great so far.
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

Re: XC_Engine megathread

Post by Higor »

Just discovered a nice and lazy workaround that allows NFO/Fragnet server renters to use the enhanced XC_Server instead of Server without even having to modify their launch batch file.
This means that "UCC SERVER" can be used to load the new commandlet without problems.

All it takes is creating a couple of unrealscript classes and editing Engine.int like this:

Code: Select all

Object=(Name=Engine.ServerCommandlet,Class=Class,MetaClass=Core.Commandlet)
int
Object=(Name=XC_Engine.ServerCommandlet,Class=Class,MetaClass=Core.Commandlet)
This workaround will be possible for next XC_Engine release, the server admin still has to edit his Engine.int file.

In the meantime, some more XC_Core stuff before the new netcode changes go live in a test server.
https://github.com/CacoFFF/XC-UT99/comm ... c39ba9d3db
User avatar
sektor2111
Godlike
Posts: 6403
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_Engine megathread

Post by sektor2111 »

I see GitHub with XC_Core10c. Are these v10 released elsewhere or are just lab-works ?
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

Re: XC_Engine megathread

Post by Higor »

Those are internal stable builds, but they may not function correctly with XC_Engine v23 so I'm keeping them unreleased until v24 is out.
In the meantime a beta is being tested at the Windows server unreal://23.111.157.138:7777 (120TR)

Edit: the netcode may be causing problems with Nexgen, so don't be surprised if you can't join for now.
User avatar
sektor2111
Godlike
Posts: 6403
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_Engine megathread

Post by sektor2111 »

Higor wrote:Edit: the netcode may be causing problems with Nexgen, so don't be surprised if you can't join for now.
I was there and I think not the NetCode is the problem but other things...
Red (Botz ?) took BlueFlag and brought it to red base = NOTHING happened. I had to shoot that Pawn for being untouched from RedFlag and finally he came back and scored. I don't get why tick-rate should be 120 and what is causing these "Touch" issues but for me it looks like an under-resourced thing losing execution frames or engine internals are going crazy... else I don't understand why "Touch" was gone... or it was a previous "UnTouch" flaw keeping "touching-list" loaded... but the second time it worked, I had to shoot own carrier.
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

Re: XC_Engine megathread

Post by Higor »

FerBotz on that server hasn't been updated for a long time :loool:

Either way, betatest time.
Only apply over a v23 install.
Attachments
XCGE24_Beta1.7z
No changelog, check previous posts instead.
(493.27 KiB) Downloaded 33 times
User avatar
sektor2111
Godlike
Posts: 6403
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_Engine megathread

Post by sektor2111 »

The same: UT_Eightball is no longer auto-aiming ( it did not capture anything so far - DM here ). I go to setup configuration for removal of this fix.

Question:
You have

Code: Select all

class XC_Engine_Actor expands Actor;
...
native(3538) final function NavigationPoint MapRoutes_FPTW( Pawn Seeker, optional NavigationPoint StartAnchors[16], optional name RouteMapperEvent);
and

Code: Select all

class FV_PathsEnhancer expands XC_Engine_Actor;
...
native(3538) final function NavigationPoint MapRoutes_SA( Pawn Seeker, NavigationPoint StartAnchors, optional name RouteMapperEvent);
Both have the same op-code 3538. Is this OK ?

Edit: Next Question is: How do I compile those functions not declared nowhere ? I understood something about compiler hack. How does this work ? I need some instructions by example for class "XC_Engine_TournamentPlayer" I did not see that "Array_Length" just others with a suffix.
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

Re: XC_Engine megathread

Post by Higor »

These functions are hardcoded into the compiler, they'll produce direct opcode calls with no package dependancy.
The array functions also work with any array type.

Code: Select all

- NavigationPoint: *
describeSpec

- XC_Engine_Actor: *
AddToPackageMap, IsInPackageMap, PawnActors, DynamicActors, InventoryActors, CollidingActors,
NavigationActors, ConnectedDests, ReplaceFunction, RestoreFunction

- XC_EditorLoader: **
MakeColor, Locs, LoadPackageContents, StringToName, FindObject, GetParentClass, AllObjects, AppSeconds,
HasFunction, Or_ObjectObject, Clock, UnClock, AppCycles, FixName, HNormal, HSize, InvSqrt, MapRoutes,
BuildRouteCache, Array_Length, Array_Insert, Array_Remove

* These functions can only be called by actors.
** These functions can be called clientside if compiled via XC_CoreStatics.static.Func(), but that will generate package dependancy.
User avatar
sektor2111
Godlike
Posts: 6403
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_Engine megathread

Post by sektor2111 »

So... for compiling XC_Engine_UT99.U I do not need to list dependencies ? How are taken ? What do I need to edit ? XC_Engine.U doesn't compile without XC_Core. What compiler is that ? I'm using Umake with ucc, any hints ?
If is about that ucc2.exe from v23, I cannot do too much... but declaring functions inside classes for default ucc.exe, because ucc2 is like here:
[attachment=0]ucc2_response.PNG[/attachment]
Attachments
ucc2_response.PNG
ucc2_response.PNG (7.75 KiB) Viewed 773 times
Last edited by sektor2111 on Sat May 25, 2019 7:57 pm, edited 1 time in total.
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

Re: XC_Engine megathread

Post by Higor »

What the compiler does is consider functions from the mentioned classes, the compiler won't be able to use them if said classes aren't loaded at compile time.
Post Reply