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

[Higor]

Lots of SSE code added, recoded Line/Triangle, Galleon tech-test fixed and added two more decorations, changed collision brute forcer to do 32 moves instead of 64 moves per-frame (was lagging a lot) .
No extent traces yet, but meshes are reliably walkable.

[sektor2111]

For small actors and pawns looks cute, for terrain/ground is a No Go, I'm guessing you know why:
- at a moment terrain get vanished and projectiles looks like collides a BSP bug because is nothing on sight and effect is like in a Level screwed up;
- and then how is A.I. navigation there ? Tricks which I don't know ? Then let me know.

[Higor]

Exactly, the default render has this nasty limitation where it rejects the model even when you're within the render bounding box.
Secondly, this is dynamic mesh collision so the goal is small sized actors.
Static mesh collision would be the real deal for terrains... as it would be much faster given the usage of the FCollisionCacus to test-hit them (true static collision).

EDIT:
Maybe I could try a RenderIterator, whatever...

[sektor2111]

Did I messed up something ?
console - > summon XC_Core.XC_Coretest
On Screen result:

[attachment=0]LOL_Clock.PNG[/attachment]

But I have declared natives inside clocking class
Resulting following:
- Foreach AllActors for Pawn P without Tag was aprox. 0.000037 - 0.000040 Seconds;
- Foreach AllActors for Pawn P having a Tag was aprox. 0.000022 - 0.000026 Seconds.

Gotta see how works declaring <final>

[Higor]

Lower case "clock"... another symbol i'll have to add.
Goddamn coders not using correct naming conventions in their mods.

[sektor2111]

I don't know what needs fixed but I have changed UScript side of XC_Core.u later by keeping Native's number declaration and now it started to work normally

Code: Select all

ScriptLog: Fabricate XC_Core.XC_CoreTest
ScriptLog: Time measured: 0.000001
ScriptLog: Actor destruction time equals: 0.000018
ScriptLog: Actor spawned at 14291.237305
ScriptLog: Fabricate XC_Core.XC_CoreTest
ScriptLog: Time measured: 0.000001
ScriptLog: Actor destruction time equals: 0.000018
ScriptLog: Actor spawned at 14295.001953
ScriptLog: Fabricate XC_Core.XC_CoreTest
ScriptLog: Time measured: 0.000001
ScriptLog: Actor destruction time equals: 0.000026
ScriptLog: Actor spawned at 14295.851563

[sektor2111]

A couple of checks for XC_IpDrv
When this thing exist in Server and Client + redirect set (IP based or Host-Name based)

Case 0:
Redirect service encounter 400 error (any application used) and won't help client - client says: "File not found in redirect" attempt next. attempt next, next... until everything gets downloaded from game-server, as result redirect can be removed because it's useless.
Aside I have copied some requested line from logs and I placed that in Mozilla - IT Was working (not sure if was a space or something bad sent by Unreal because Web browser worked)

Case1:
Client without XC_IpDrv - will download UZ files even if has XC_Core added + XC_Engine16 - simply without XC_Ipdrv client won't even smell any LZMA.

XC_IpDrv trigger bad requests from client I think even tries a combination with filename-hostname or some bullshit which is rejected by redirect application sustaining Web file-service. At a moment I set redirect as IP not Host to see what's happening and still 400 did not help. Client without XC_IpDrv doesn't seems to have a problem - simply cannot operate bad requests.

Case2:
No redirect and all XC loaded. All downloads goes to LZMA directly from server.

Case3: No XC stuff nowhere - redirect set normally - files were downloaded normally in UZ format with 0 failures.

As a conclusion Client with XC_Ipdrv seems to not very catch the redirect due to 400 errors which is able to trigger, at least this is what I found when I though that things are working properly.

For declaration of download managers I did not see a section for XC_Core - Surely is supposed to work from redirect?
Virtually:

Code: Select all

....
DownloadManagers=IpDrv.HTTPDownload
DownloadManagers=XC_Core.XC_ChannelDownload
DownloadManagers=Engine.ChannelDownload

[XC_Core.XC_ChannelDownload]
RedirectToURL=something goes here
ProxyServerHost=
ProxyServerPort=3128
UseCompression=True

[IpDrv.HTTPDownload]
RedirectToURL=something goes here
ProxyServerHost=
ProxyServerPort=3128
UseCompression=True
.....

I think this is how XC_Core has to be declared else I did not see redirect attempts from client side since it doesn't use any URL in server. Even if is declared like above - pointing client is missing.

Edit: Lines Copied from Client

Code: Select all

DevNet: PendingLevel received: DLMGR CLASS=IpDrv.HTTPDownload PARAMS=http://xx.xx.xx.xx:9000/Redirul/ COMPRESSION=1 //Properly announced
DevNet: PendingLevel received: DLMGR CLASS=XC_Core.XC_ChannelDownload PARAMS=Enabled COMPRESSION=1 //I don't see any address here
DevNet: PendingLevel received: DLMGR CLASS=XC_IpDrv.XC_HTTPDownload PARAMS=http://xx.xx.xx.xx:9000/Redirul/ COMPRESSION=1 //Another announcements which is causing NONE download
DevNet: PendingLevel received: DLMGR CLASS=Engine.ChannelDownload PARAMS=Enabled COMPRESSION=0 //default method doesn't need anything.

So game-server is a redirect now as long as redirect won't be serving bad requests.

You should try these with HFS, NetworkActivWebServer, Abyyss free version, etc. See if helps - I guess not or I do missing something.

Edit:
Default server + redirect Address without "/" at suffix is not very functional.
XC Server + redirect without "/" might want to be functional but default client will fail - I guess 400 comes from bad request suffix based "web-address//file-requested". Or do I wrong ?

[Higor]

Can you redirect to your own machine and examine the data received by both download managers?
XC_IpDrv works fine on my end (with chamberly's server).

Alternatively give me the ip of the server you've tested against and I'll try downloading some files from it's redirect.
Bear in mind that most redirects don't even have LZMA files lol.

[sektor2111]

Bear in mind that most redirects don't even have LZMA files lol.

Even if I have them client said NONE (no such file in redirect)...
But redirect log said 400 - bad request.
I have removed XC_IpDrv from client because is doing dumb things.
Edit: Keep in mind that sometimes I copy lines from client log dropping them in Mozilla to test if files are there and this way always worked. Unreal has a request problem if operates with XC_IpDrv.

Edit
Described in HFS logs (which I set in file in order to check them well - it's able to do only ON-Screen logs)
If defaut says: "/Folder/file.u.uz" - it works
For XC_IpDrv says "http://address:port/Folder/file.u.lzma" - This is wrong called, else normal "file.u.lzma" is there for weeks.

Edit2:
NetworkActiveWebServer does the same 400 error logs from user-agent "Unreal" - I did not saved them since I have figured what's wrong right in HFS.

[Higor]

I see, no wonder I wasn't noticing that...
Chamberly's and UnrealKillers redirects do process that request fine.

Will make experiments by only passing the /path/filename instead of the full URL.

EDIT: I'll probably add an extra setting to customize the user agent lmao, so XC_IpDrv can identify itself differently.

[sektor2111]

XC_IpDrv.dll from 07/13/ 2015
MD5: 45bf74f65fb2592187a112eeeea82da7
doesn't have troubles at LZMA servicing. All LZMA are downloaded correctly from redirect - As I saw a couple of minutes ago.

[Higor]

Try this one, XC_IpDrv was sending the full URL in all cases, where it was only supposed to happen with Proxy server setups.

EDIT: Forgot to mention, this XC_IpDrv already takes care of the 6000 ping exploit on servers.

[sektor2111]

Additional feature. Player adding these XC files inside game doesn't need to edit anything for getting new LZMA compression. LZMA is self triggered by file proximity due to "DownloadManagers" sent by server to client. If client has file will debate problem, else is NONE problem.

Thank you, Higor for update.

Edit: Server is fully functional, but client did not even touch redirect. All download has been operated from game-server.

Edit2: I forgot to mention yesterday, if XC_IpDrv doesn't exist in client but the rest of XC are there client won't even smell LZMA stuff. Or something went wrong, or only XC_IpDrv can manage LZMA download ignition.

[sektor2111]

Events which occurs in this version that needs revised, shortly:
a) Client try to solve redirect's host address;
b) But download has already started - from game-server;
c) 2-3 files have been downloaded;
d) At a random moment address has been solved;
e) But download keeps going from server being uninterrupted by host's IP suddenly solved between downloads.
Log from redirect service is empty - no download call has been registered.

[Higor]

Downloads are requested by the client, and channel downloads only start IF the client's HTTP downloader's resolve thread fails to resolve.