Page 70 of 72

Re: XC_Engine [20] - XC_Core [7b] - XC_IpDrv

Posted: Sat Jan 06, 2018 1:50 am
by Chamberly
I do need to update that tutorial for the new stuff and other that I have not included.

Feel free to let me know what I should include making it easier. A simple PM will do and once I have it updated I'll post some update on this reply.

Re: XC_Engine [20] - XC_Core [7b] - XC_IpDrv

Posted: Mon Jan 15, 2018 11:34 pm
by Higor
After some tests I'm gonna have to move the converter code into a yet another package, starting from release build.
XC_Core should be loadable in all possible UT instances, and some Linux servers don't have Editor.u in them.
I have to be very careful of what dependencies each XC_Core has, by keeping it dependant on only Core and Engine it'll take far less time to load and stay compatible with TacticalOps.

The good thing is that nothing will be broken if the converter is moved into a separate package, instead you'll just have to add anothe EditPackage to the editor engine.
And that package could be extended with more native/special builders.

And before moving on from the converter, has anyone managed to succesfully build something of use with it?
Got any maps with these new decorations?

Re: XC_Engine [20] - XC_Core [7b] - XC_IpDrv

Posted: Wed Jan 17, 2018 4:06 am
by Higor
If I'm gonna move the builders outside of XC_Core.u, I might as well make this new package contain a lot more useful tools.
In this case, added a shortcut to the XC_PathBuilder which is easier to setup.

I may add an extra button something that will fill a line between two distant NavigationPoints with PathNodes at the maximum possible distance, good for pathnoding maps with long tunnels in just minutes.
I also have something in mind that would allow the mapper to build brushes with ANY shape...
PathShortcut.PNG

=============
This is possible thanks to XC_Core's natives!
//====================================================
// XC_Engine path rebuilder shortcut
//====================================================
class PathRebuilder expands BrushBuilder;

var() class<InventorySpot> InventorySpotClass;
var() float MaxScanRange;

event bool Build()
{
local LevelInfo LI;
local class<Actor> AC;

ForEach class'XC_CoreStatics'.static.AllObjects( class'LevelInfo', LI)
if ( !LI.bDeleteMe )
break;

AC = class<Actor>( DynamicLoadObject("XC_Engine.XC_PathBuilder",class'Class') );
if ( AC == None )
return BadParameters("Unable to load XC_Engine.XC_PathBuilder");

if ( InventorySpotClass == None )
InventorySpotClass = class'Engine.InventorySpot';

LI.ConsoleCommand("set xc_pathbuilder inventoryspotclass "$InventorySpotClass.Name);
LI.ConsoleCommand("set xc_pathbuilder maxscanrange "$MaxScanRange);
LI.Spawn( AC);

return BadParameters("Paths rebuilt [Dist="$int(MaxScanRange)$"]");
}

Re: XC_Engine [20] - XC_Core [7b] - XC_IpDrv

Posted: Wed Jan 17, 2018 7:29 am
by sektor2111
Higor wrote:Got any maps with these new decorations?
Nope, I was trying to do a box which resulted in a box with texture scale in default size screwing box. Another time I was trying to do a lamp from a brush using a MyLevel texture and some funky stuff was showing up, another time worked with some decoration pillar part using stock textures... I got used with MeshMaker for doing run-time "mapping". I need time to figure what's the whole deal.

XC_PathBuilder
Oh, well, this is a default like stuff for latest maps fixes/adds which I did, and this is what I used in MH-Sk_BattlingLottery.

I had some questions about run-time paths where I did not see more answers, so I went to other research for figuring what's the deal with that stuff by myself because I did not see other participants at debates. What I could figure so far:
- New nodes have to be registered with that native into Network and they have to be spawned - never bStatic;
- New nodes need a trace check and reaching capabilities test using some "cute scout" else small spots are not linked;
- New nodes needs special child classes because doors will not allow links in Run-Time - only in Editor where mover is like None - these nodes will need a short link range for preventing dumb things because are brute forced with no reach testing;
- New Nodes can get links even "very late" - I don't need prebegin postbegin here to load iterators;
- New Nodes I think can get links even triggered in a later game moment (for preventing dumb roaming) - I have to try/do this when situation recommends this - did not do yet;
- I had to build some small tool-mutator that I use at random in game in order to spy heavy loaded InvSpots which I might fail to see in Editor due to the stupid initial load and to attack new paths with toggling tools needed later in game and figuring their location/name for blocking/unblocking them - I did not do any default PathSwitcher - doesn't look like it's necessary - even a default PathNode can be locked/unlocked based on a map event being tracked by whatever keypoint;
- Evil Nodes from map which have to be discarded will need some testing around as long as the spot unlocked from Network is not always the best ever deal, it looks like such a node will have problems if we want it connected different a bit later discarding old connections or I've failed to figure the deal in changing paths with it;
- if map it's really BAD not even the father and the God of run-time paths will not help here - sample can be one of those 24h build time taken maps creating useless Levels for A.I. and even for human player as long as I did not see them that popular because they are beyond engine boundaries.

Re: XC_Engine [20] - XC_Core [7b] - XC_IpDrv

Posted: Wed Jan 17, 2018 8:57 pm
by Higor
XC_Engine will be able to better manipulate HTTP downloaders.
It will do so by either removing the unnecessary IpDrv downloader, or by upgrading it to XC_IpDrv.
I noticed that XC_Engine clients will be able to access TWO redirect servers if the addresses for IpDrv and XC_IpDrv are not the same.
Spoiler
DevNet: PendingLevel received: DLMGR CLASS=XC_IpDrv.XC_HTTPDownload PARAMS=http://***/ COMPRESSION=1
DevNet: PendingLevel received: DLMGR CLASS=IpDrv.HTTPDownload PARAMS=http://***/ COMPRESSION=1
DevNet: PendingLevel received: DLMGR CLASS=XC_Core.XC_ChannelDownload PARAMS=Enabled COMPRESSION=1
DevNet: PendingLevel received: DLMGR CLASS=Engine.ChannelDownload PARAMS=Enabled COMPRESSION=0
DevNet: PendingLevel received: XC_ENGINE VERSION=20
DevNet: Welcomed by server: WELCOME LEVEL=CTF-BT-(B)Distanc3_nb2 LONE=0
DevNet: Removing DownloadInfo(1) due to redundancy with XC version
Log: [XC] Resolving ***...
DevNet: Receiving package 'CTF-BT-(B)Distanc3_nb2'
Log: [XC] Resolved *** (***)
DevNet: [XC] Requesting: http://***/CTF-BT-&#40;B&#41;Distanc3_nb2.unr.lzma
DevNet: Compressed filesize: 916810
Log: [XC] Resolving ***...
DevNet: Receiving package 'ACEv10e_Cdll'
Log: [XC] Resolved *** (***)
DevNet: [XC] Requesting: http://***/ACEv10e_Cdll.u.lzma
DevNet: [XC] Requesting: http://***/ACEv10e_Cdll.u.uz
DevNet: [XC] Requesting: http://***/ACEv10e_Cdll.u
DevNet: Package not in redirect, switching to next download method
The log prints less crap and actually informs of what's going on, the redirect timeout can be changed (defaults to 4 seconds) and the INI entries are autogenerated if you download at least one file.
I was thinking with writing a GUID validator to run post-download, and to not mark the package as 'downloaded' if it fails.
sektor2111 wrote:Nope, I was trying to do a box which resulted in a box with texture scale in default size screwing box. Another time I was trying to do a lamp from a brush using a MyLevel texture and some funky stuff was showing up, another time worked with some decoration pillar part using stock textures... I got used with MeshMaker for doing run-time "mapping". I need time to figure what's the whole deal.
Try enabling the texture tiling, it'll subdivide the faces into squares.
It's not perfect but it'll work wonders with terrains and other meshes that use small textures.
You should always use the final textures on the mesh, not placeholders.
sektor2111 wrote:- New nodes have to be registered with that native into Network and they have to be spawned - never bStatic;
Nodes ALWAYS have to be on the NavigationPointList chain, no exceptions.
That's why XC_Engine_Actor.LockToNavigationChain() is there.
sektor2111 wrote:- New nodes need a trace check and reaching capabilities test using some "cute scout" else small spots are not linked;
Linking is 100% arbitrary, you can link two nodes even if they're not visible and their distance is 60000.
sektor2111 wrote:- New nodes needs special child classes because doors will not allow links in Run-Time - only in Editor where mover is like None - these nodes will need a short link range for preventing dumb things because are brute forced with no reach testing;
The brush tracker will turn doors into BSP, your traces will only go through doors during level initialization, before the first tick. See: FerBotz.

Re: XC_Engine [20] - XC_Core [7b] - XC_IpDrv

Posted: Fri Jan 19, 2018 8:21 pm
by sektor2111
Higor wrote:added a shortcut to the XC_PathBuilder which is easier to setup.
I've used that code into one of my pathing toys and after adjusting a few "defaultproperties" I could see it perfectly operational. Good job... no more touching surfaces for placing XC_PathBuilder, just hit the right button. I like the deal with iterator and variable setup, makes sense...

Re: XC_Engine [20] - XC_Core [7b] - XC_IpDrv

Posted: Mon Jan 22, 2018 5:42 am
by Higor
For those with the XC_Engine beta.
This should be the last test build with debug sanity checks (that force a crash), after getting rid of an anomaly on the mini-octrees in the grid it appears to not crash anymore.
Other changes include not doing queries using invalid vectors (#NAN, etc).
CollisionGrid_04.7z
https://github.com/CacoFFF/XC-UT99/tree/master/CollisionGrid/CollisionGrid
(13.46 KiB) Downloaded 70 times
The release build won't have all the UE_DEV_THROW sanity checks on them, which should speed it up significantly.
And as usual, the build compiled by me will not require any Microsoft C Runtime packages.

==================
A little announcement.
Considering the amount of changes EVERY single package in the XC collection is going to get, plus how the interoperability changes make it impossible for any backward compatibility with other versions, there will be a full update on the same day once everything is set.
That includes launchers, UCC2 and editor addons.

Re: XC_Engine [20] - XC_Core [7b] - XC_IpDrv

Posted: Sun Jan 28, 2018 12:16 am
by sektor2111
I'm not going to ask technical details about C++ and new collision algorithms. As a matter of fact I still can figure random boosting ( like an invisible rope is pulling me at once with projectile fired ) and it looks like it happens in nasty combat situations making me to fly away and then even falling in hazard zones. It do happens more rare than before, but it's still happening. Perhaps I'm going to disable collision hook for the moment, playing normally. If client is crashing is not the end of world, server looks pretty good and it's running enough nice comparing it with functionality from years 2008-2012.

Re: XC_Engine [20] - XC_Core [7b] - XC_IpDrv

Posted: Thu Feb 01, 2018 7:26 pm
by sektor2111
And now I think these Lzma XC things did not really pass beta stage. I can figure troubles due to some equipment which I've acquired helping me with some testing.
I was using a client connected on a 3G mobile device though a tethering system.
Client has started to download map file, but download did not complete just going to server and being server with a NON lzma uncompressed file but server claiming like sending lzma (I think I'm going to delete lzma from there after all). More than that, some funky messages are shown. Let me try to share some image (I don't care about IP used for testing because it's dynamic).
[attachment=0]doubting.PNG[/attachment]

So to speak I don't see the log for file completion, but client is switching to direct server download. It's about around 70 MB content to download and I think we don't want to annoy clients with double downloads at this point. Also I'm going to try some other type of connection through a wireless card which I was using, I'll report these later if other future issues will show up.
To summarize Here I think we are missing a "lag protection" thingy. I think if during download we have let's say 50-70 ms lag (net spike) simply XC_Ipdrv will switch without to wait even a blink which is not an answer since in a network lags are not an anomaly, we should debate these as well as long as we don't have seconds, everything might be skating under 1 second and XC_IpDrv is quitting too fast, and probably doesn't "retrying" to gain latest frame or such. I don't know a lot about net buffering and "time wait" stuff, but here I think those things are pretty much missing or are too short/small or whatever.

Re: XC_Engine [20] - XC_Core [7b] - XC_IpDrv

Posted: Thu Feb 01, 2018 7:54 pm
by Higor
I noticed a lot of unexpected stuff in the downloaders.
Believe me, the new XC_IpDrv will fix those right away, cannot put a beta build because of the full rewrite that breaks all backward compatibility.

This is going to be the changelog for next release
XC_IpDrv:
- HTTP downloader reworked for XC_Core v8 compatibility.
- Reduced message spam during download.
- More reliable download process.
- Downloader connection timeout can be modified (default 5)
-- XC_IpDrv.DownloadTimeout
- Autogenerates config entry in your game INI after downloading a file.

For some reason Windows systems fail to properly write to file in some cases, so the file has to be reopened in the middle of download process.
XC_Core's generic downloader (which affects XC_IpDrv) has code that will reopen the file and continue writing (append mode) if this happens.

Yes, next release will be massive.
I just need to fix CollisionGrid!!

Re: XC_Engine [20] - XC_Core [7b] - XC_IpDrv

Posted: Fri Feb 02, 2018 9:42 pm
by sektor2111
Higor wrote:For some reason Windows systems fail to properly write to file in some cases
I'm going try to not talk crap but Windows might badly fail a file at a power failure. Writing files in majority of cases is based on "write-cache" which means small files are written when machine is idling else files stay open but not completed unless a massive bunch of bytes have to be written and then machine is forced to write as much as possible. By disabling write-cache performance is decreased machine simply waiting each disk write access which is not the best deal... If UT comes with other bugs that's a different story... and I see that we have a swarm of bugs in here...

EDIT:
All right, I did another tests using 2G 3G and tethering VIA wi-fi client. I went to tweak Nagle's algorithm (disabling it). Download was completed at 3G connection, I did not test 2G because a long download takes until next summer... During this time phone responsible with connection was sustained by a power-bank with double power capacity than phone having a battery marked 1000 mA and fully charged.
To summarize, like Dr. Flay said, disabling Nagle's Algorithm seems helpful but of course the download is slower, and this can be figured at a 2G connection but game-play do seems to have less lags than before tweaking. At a moment it was increasing lags time up to dropping client for some reason. After disabling Nagles's Algorithm game was running between aprox. 228-350 ms ping with very few flaws.

These tests have been done in MH maps with a normal load (not 1000 monsters) and both machines client and server were using Windows XP, phone engaged in 2G/3G connections has Android 4.2.2 Jelly Bean, client and server being on different ISP services.

Re: XC_Engine [20] - XC_Core [7b] - XC_IpDrv

Posted: Sat Feb 03, 2018 3:25 am
by Higor
You just reminded me, the downloader SHOULD flush the file writer every time data arrives, otherwise there may be a data gap if the downloader reopens the file!!!!
Also, the file problems started to occur on XC_IpDrv when I raised tickrate to 120... apparently ticking too fast caused data to not be received inbetween frames, triggering a timeout?
Networking is indeed weird.

One another issue, I managed to make the linux servers output the function history (guard/unguard macros) when crashing, the downside is that a certain v436 build will not be supported due to not having the macros enabled.
This means that Linux v436 servers that use an outdated Core.so/Engine.so need to update those two binaries in order to run XC_Engine.
The disadvantage is that in order to see this you can't use ServerCrashFix.

Re: XC_Engine [20] - XC_Core [7b] - XC_IpDrv

Posted: Sat Feb 03, 2018 8:55 am
by sektor2111
Higor wrote:This means that Linux v436 servers that use an outdated Core.so/
... can happily crash when a pupae is trying to enter in such server - go figure... Loki :loool: ... eh... gulp...
So rental corporations which have original files and doesn't allow managing system files can wipe their ass with their "servers"... this is utterly the most hilarious and stupid bug ever BROUGHT to UT because a default Win server 436 doesn't have it...

Re: XC_Engine [20] - XC_Core [7b] - XC_IpDrv

Posted: Tue Feb 06, 2018 3:08 am
by [rev]rato.skt
I am having a problem that two people enter the server and get stuck and frozen, so they are disconnected, I do not use Ace on the server ...

I had to disable it and everyone entered the server normally... :(

Re: XC_Engine [20] - XC_Core [7b] - XC_IpDrv

Posted: Sun Feb 11, 2018 2:45 am
by Higor
Testing an installer commandlet, with batch scripts one can setup XC_Engine related stuff with a single command.
The commandlet is written in UnrealScript, but uses a lot of XCGE natives in order to properly create an execution environment where config can be altered.
Config entries for XC_TcpNetDriver and XC_GameEngine are also autogenerated when they're enabled.
Spoiler
D:\Games\CleanUT\System>setuptest.bat

D:\Games\CleanUT\System>ucc help xc_setup
=======================================
ucc.exe: UnrealOS execution environment
Copyright 1999 Epic Games Inc
Modified by Higor (UCC2 version 3)
=======================================
Usage:
ucc ucc xc_setup +add -remove *status
Parameters:
engine Game Engine update
netdriver Net Driver update
editor Editor addons

D:\Games\CleanUT\System>ucc xc_setup -ini=TestUT.ini *engine *netdriver *editor

Executing Class XC_Setup.XC_SetupCommandlet
Bound to XC_Engine.dll
Bound to Window.dll
Bound to Fire.dll
Bound to IpDrv.dll
Environment succesfully loaded...

XC Engine status: ENABLED
XC TCP driver status: ENABLED
Bound to Editor.dll
Editor addon status: ENABLED

D:\Games\CleanUT\System>ucc xc_setup -ini=TestUT.ini -engine -netdriver -editor

Executing Class XC_Setup.XC_SetupCommandlet
Bound to XC_Engine.dll
Bound to Window.dll
Bound to Fire.dll
Bound to IpDrv.dll
Environment succesfully loaded...

XC Engine has been disabled
XC TCP driver has been disabled
Bound to Editor.dll
Editor addon has been disabled

D:\Games\CleanUT\System>ucc xc_setup -ini=TestUT.ini *engine *netdriver *editor

Executing Class XC_Setup.XC_SetupCommandlet
Bound to XC_Engine.dll
Bound to Window.dll
Bound to Fire.dll
Bound to IpDrv.dll
Environment succesfully loaded...

XC Engine status: DISABLED
XC TCP driver status: DISABLED
Bound to Editor.dll
Editor addon status: DISABLED

D:\Games\CleanUT\System>ucc xc_setup -ini=TestUT.ini +engine +netdriver +editor

Executing Class XC_Setup.XC_SetupCommandlet
Bound to XC_Engine.dll
Bound to Window.dll
Bound to Fire.dll
Bound to IpDrv.dll
Environment succesfully loaded...

XC Engine has been enabled, config saved
Bound to XC_IpDrv.dll
XC TCP driver has been enabled, config saved
Bound to Editor.dll
Editor addon has been enabled

D:\Games\CleanUT\System>ucc xc_setup -ini=TestUT.ini *engine *netdriver *editor

Executing Class XC_Setup.XC_SetupCommandlet
Bound to XC_Engine.dll
Bound to Window.dll
Bound to Fire.dll
Bound to IpDrv.dll
Environment succesfully loaded...

XC Engine status: ENABLED
XC TCP driver status: ENABLED
Bound to Editor.dll
Editor addon status: ENABLED

D:\Games\CleanUT\System>