PD: Found another set of problems in CollisionGrid and already fixing some.
Found a bug in extent traces that was making players not properly stand in elevators and that the GCC compiler wasn't properly vectorizing (have to update to GCC 7)
Done, this should fix all (if not most) of CollisionGrid problems.
Small reminder that this requires SSE2 instruction set.
- May be applied on previous XCGE as well
- (33.35 KiB) Downloaded 13 times
does the same "invisible-for-user" error if "bEventChainAddon=True", other maps are working.
Note: This map loads patch files for remapping navigation and it was... a heavy deal. Strategy in moving movers away from Scout did not worked in that time for this map while in others was the default strategy. I had to open them, mapping paths, and closing them back. Else... here I have some actors triggered at once with doors which are dropping in the right moment InventorySpots because originals from behind doors were removed and other paths were mapped for making Bots to get items only after opening those doors.
After disabling EventChain map was operational at once with all patching:
Testing in progress...
Code: Select all
ScriptLog: UdpServerQuery(crt): Port 7778 successfully bound. ScriptLog: Game Core found CaptureActor. Critical: UXC_Level::SpawnActor Critical: (Scout) Critical: FPathBuilder::getScout Critical: ScriptDebugV Critical: EL_Trigger0.CreateAIMarker Critical: ScriptDebugV Critical: EL_Trigger0.Update Critical: UObject::execClassContext Critical: (XC_Engine_Actor DM-Velocity_R15.XC_Engine_Actor6 @ Function XC_Engine.XC_Engine_Actor.SetInitialState : 0051) Critical: UObject::ProcessEvent Critical: (XC_Engine_Actor DM-Velocity_R15.XC_Engine_Actor6, Function XC_Engine.XC_Engine_Actor.SetInitialState) Critical: BeginPlay Critical: UXC_GameEngine::LoadMap Critical: LocalMapURL Critical: UGameEngine::Browse Critical: ServerTravel Critical: UGameEngine::Tick Critical: UXC_GameEngine::Tick Critical: UpdateWorld Critical: UXC_ServerCommandlet::Main Exit: Executing UObject::StaticShutdownAfterError Exit: Exiting. Uninitialized: Name subsystem shut down Uninitialized: Log file closed, 07/21/19 01:12:19
I think here getScout call is doing critical damage because we don't need that Editor Scout, we need a "run-time" type Scout...
https://github.com/CacoFFF/XC-UT99/comm ... 3132319b1b
Notable: "Improved actor attachment movement, actors are much less likely to overlap/encroach/telefrag each other when standing on a base that moves horizontally."
- (599 KiB) Downloaded 18 times
Config done... everything is looking stable (I'll see other testing next hours) but I removed once again that XC_UPakPredator because I'm not sure if I do need it. Editor is crashing if I'm opening that thing. I don't get why I should use it.
Note: I've disabled RocketTick if game is being ended - auto-aiming in that stage it's useless...
Edit: The Good and The bad
Probing NfoServer with XC_MonsterHunt map called MH-CrystalMine3 (original by Teraniux not some stupid mismatch copy) using patch plugins for completing paths up to the MonsterEnd.
Evil things - Bots were trying a shortcut to WayPoint3 and I could not see more interest for WayPoint4 but let's say that I could manage these while they attacked forward...
Good news - Bots were going closer to end - opening gates (did not happen so far in prior versions) and even they could finish map - previous DevPath has stopped at first grate and... done with bot's race. In this update I see a real improvement to DevPath but I would like to find what was wrong at Position3 and 4 because they have been operational before.
Now I think I will want to retry my best pathing task for MH-LostInTimeV3... as long as I can do some reachSpecs nullified for making things easier for Engine.
Using XC_MonsterHunt and MBots map MH-LostInTimeV3 a version with all paths redone. Pretty closer to applause newer DevPath... but:
- WayPoint4 moved more reachable returned a route in Editor (which is more nasty with Scout not like in run-time) using a closer node on that ledge nearby stone - Bots were roaming properly because of... new technology from XC_MonsterHunt. Me, player I could not see any route here.
- Waypoint5 The same results.
- Waypoint6 entirely reachable by ALL pawns - human as well - using a similar placement.
- Waypoint7 failure - Only bots roamed properly.
- Waypoint8 good response.
Personal conclusions - suspects - I see network working perfectly, the problem can be that last Node supposed reachable around target which won't return anything if it's colliding with mover and here comes once again collision issues vs Movers or map has problems causing error in computing BSP traces - in hoping to wrong.
EventChain had a sudden funky reaction ? I touched all Waypoints and MHBotyman4 was showing MonsterEnd reachable (I was closer) but turning me into another direction - a trigger - where I could see a green apple around last WayPoint instead of MonsterEnd and... DevPath discarded first search even if I was in the castle in the same area. Something is not working properly with that Green thing it has turned me almost 180 degrees to a trigger which was already touched opening the way to ending portal. It was like being a step behind me. During this time Bots were looping in another area of map without to leave that spot...
Edit: I think job it's done in LostintimeV3. If some waypoints are unseen by player is probably a BSP problem because Bots are hunting well in XC_MonsterHunt (there strategy is changed). I gotta do some checks in last room, but... mission it's almost done so this is not a problem in end.
All I might need are small actors for default Bot, removal of some directions, maybe some ammo and healing spots and... it's good to go for a XC Server... Impressive DevPath - applause.
By disabling all that EventChain stuff and playing MH-Crystalmine3 with patch plugins (run-time depleted paths) I could see Bots heading the game up to the end. Definitely some events from XC_Engine added there combined with new paths aren't doing to many good things. All WayPoints injected in run-time have been completed properly without any other add-on.
As a self reminder, another long map with problems at DevPath was MH-PurpleChristmas or such. It worked in the past when I had a half of map with paths and stopped working when was full filled. I dropped it away... but now I'm curious how will react with new dev...
This can be really useful for movers blocking paths that don't have a BlockedPath marker or any other way of signaling the path isn't available.
This MAY help bots enable long distance elevators/bridges where the trigger isn't visible or reachable.
In the following example you'll see the bot not touching the secret door before going towards the light.
Back to pathing tests:
MH-PurpleChristmas has middle area responsive at DevPath and Bots are heading for a few items there, as for the rest of areas... not many chances...
As conclusion we have a powerful DevPath but in bad oversized maps it's not very active. Good work so far.
Take a look at Bot and Pawn classes.
Bot has a definition of BaseChange, then calls Super.BaseChange within it...
The problem is that both functions have been tagged as singular functions.
So this means that Super.BaseChange will ALWAYS fail to run.
What's the effect of that?
Well, bots don't deal damage to players and decorations when they land on them.
Meanwhile, major milestone on the Event Chain System and Bot AI, does this clear any doubts about dispatchers and other complex mechanisms not being properly handled?
(The Singular function bug was been sort of worked around, it's possible to call Global/Super versions of a singular function now)
XC_Engine 25 and onwards will only run on UT v469, this means I'm deprecating UT v451 and under for next release.
Most of the changes in XC_Engine 25 will actually consist on removing stuff that won't be needed due to them having been implemented in the new UT patch.
Aside from a few bugfixes, a few new features might make it in.
A major one I'm thinking about is adding the possibility of making specific actors travel from one level to the other in Coop games, without requiring any relation to a player or it's inventory.
This would make the task of having hub levels, recurrent levels, and other general stat holders a lot simpler.