Fixes for RocketX3

[Buggie]

Compatibility preserved so you can safely replace RocketX3.u on client or server (do not forget about .uz version in this case!).

Important note: files conformed, but tools like ACE which compare file byte-by-byte or calculate difference will be complain about files modification.

fix1. Fix flood in the log:

Code: Select all

ScriptWarning: StrangeShellVX MH-UM-DiscoClubV4.StrangeShellVX1 (Function RocketX3.StrangeShellVX.Destroyed:012E) Accessed None 'P'

RocketX3fix1.zip

fix2. Fix flood in the log:

Code: Select all

ScriptWarning: FuelpodVX MH-UM-SpeedCircuit1.FuelpodVX99 (Function RocketX3.FuelpodVX.validActor:005D) Accessed None 'PlayerReplicationInfo'

RocketX3fix2.zip

fix3. Fix flood in the log:

Code: Select all

JumpDetectorVX MH-DinoPlanet2011[THUNDERBOLT]FIX02.JumpDetectorVX3 (Function RocketX3.JumpDetectorVX.Tick:000C) Accessed None

RocketX3fix3.zip

[Barbie]

Although the name is the same there won't be mismatches?
PS: There is another jet that floods client's log with Acccess Nones because of "s".

[Buggie]

No. Package conformed.

Also I found next flood:

Code: Select all

ScriptWarning: XSFRed MH-(dU)RXStarWars.XSFRed0 (Function RocketX3.XSFRed.Update:0038) Accessed None 'Owner'
ScriptWarning: XSFRed MH-(dU)RXStarWars.XSFRed0 (Function RocketX3.XSFRed.Update:00F8) Accessed None 'Owner'
ScriptWarning: XSFRed MH-(dU)RXStarWars.XSFRed0 (Function RocketX3.XSFRed.Update:0123) Accessed None 'Owner'

When start drive Rocket.
Same code for XSFBlue (Subclasses? No not hear. Copy-paste is better!)

But IDK how properly fix it:

Code: Select all

simulated function Update()	// Update the trailer
{
  local vector Offset;
  local float Alpha, X, Y;

    if (Next != None)		 // Call Update() on next trail
   Next.Update();


  if (Pos == 0)		 // Move to where the previous part of the trail was (or player location for that matter)
  {

    Alpha = Owner.Rotation.Yaw / 10430.2192;		  // Convert Owner horizontal rotation into radians

   Alpha += (TrailOffset.Z / 180 * Pi);		  // Rotate it through TrailOffset.Z
    if (Alpha > 2 * Pi)
      Alpha -= 2 * Pi;

    X = TrailOffset.X * Cos(Alpha);		 // Calculate cylinder co'ordinates
    Y = TrailOffset.X * Sin(Alpha);
   Offset.X = X;
    Offset.Y = Y;
    Offset.Z = TrailOffset.Y;
    SetLocation(Owner.Location + Offset);
  } else {
  SetLocation(Owner.Location);
  }
  SetRotation(Owner.Rotation);
 
  if (Pos < MaxTrails && Next == None)		// Spawn additional trails as necessary
  {
   Next = Spawn(XSFRedClass, self,, Location, Rotation);
  //Next.Pos = Pos + 1;
  }

}

PS: There is another jet that floods client's log with Acccess Nones because of "s".

If you know - post it. I look on it.

--- EDIT ---

Fix2 added.

[Barbie]

Although the name is the same there won't be mismatches?

No. Package conformed.

Thanks for the answer and sorry for insisting: what does "conformed" technically mean? Did you set the package's UUID to the value of the old one?
And will the modified package be transferred to clients? If so and they do cache ripping, we have one more of the "same name, different content"-problem.

[Buggie]

"Conformed" mean package passed "ucc conform" command.
This command (as I know) set sane UUID, set same GEN version (move real GEN to REALGEN), and ensure field order is same as is in original package.

This is mean - this package network compatible with original and server or client can use any of package (conformed or original) and all still work together.

Of course not all changes can be conformed. So if I make changes I make only allowable changes.

--- EDIT ---

In practical terms this means next:
for clients: you can copy that file to your client and all work, even if server use original version.
for servers: you can copy that file to server and all clients still work. Even if they use original version.
If you update .uz version, then clients without this file get fixed version.

--- EDIT ---

Exists one pitfall here: If you update on server then client do not redownlaod package if already have it. So it win and fail in same time.
Win if changes only server side and allow clients not notice change file. Fail - because if player have bad version - he still use it.

Added fix3.

[SC]-[WARTZ_{HoF}]

Ask sektor2111 about fixes. He helped me with RX9 nulls.

[sektor2111]

Code is not completed and I think it never was, just copied moved, spam classes added.

Here it's about whatever update at this rocket without taking in account when owner is missing and saving whatever old rotation stuff for future use in case that Owner is vanished or in invalid format for some reason. There it would be needed an extra variable (or more variables), but adding new data will break compatibility with old versions without this data so a conformed fix it's not an answer here - here will a mismatch a la BPak whatever thanks to the "great" codes written and copy-pasted over time. To not forget how many actors are stacking these hilarious "planes". My old MonsterHunt server went 10 X more stable when I removed maps containing string KongLauncher - and files deleted for not being summoned by anybody, it's all I have to say.
We were talking about whatever older version and what it does at each launch. It creates actors never deleted and... using replication... I did not see something more evil and more damaging than this flying garbage. If you play for a while previous versions with a bit of Air Support you can launch "ShowAll" command and see what these are doing... To not forget that decal without texture - thanks to Epic for wrapping function or else it would be a critical crash... Mainly these junks have been "mapped" and package must have identical name either way map must be fixed for a future "rocket" version. Here perhaps it's time for improving A.I. and rewriting these fascinating myths.
As a matter of fact I wrote a bit of Bot Support for these (concerning CTFGame) demonstrating that "BrainSharing" solution is somehow better than what these codes were using (that mainly useless spam SkyNet). Definitely class SLBotBrain can be written in a more PRO format. There you'll figure what changes were done in DevPath from XCGE - not very helpful here... UE1 needs sanity checks and left alone, changes aren't that good as expected...

@Barbie
A conformed version of a package usually won't mismatch anything. If it comes to conforming a package this must have something similar with original structure.
By example I conformed a few major stock files and from now on I got: Titans killed by ShockBalls, Monster won't melee damage NONE, Flies won't have a tactical move against nobody, Berserker is less berserk with server, all these are doable at server level without causing issues for generic player. Not everything can be fixed this way, new functions and new variables are not welcomed in stage but sanity checks and sleep codes or whatever fine tuning using current package data will prevent lousy things.

[Barbie]

I really appreciate your work for UT, but I dislike these procedure with "confirmed" packages when there is a possibility that they are transferred to clients, and I will not install such on my server. Because there will be players who extract such a modified package from cache, use it in their own maps, distribute that collection and, voilà, a new file mismatch is born. Mismatch in the sense that the name is equal but content is different.

Again and again I got archives that contain packages that differ from them I have already installed; "spinner.u" for example. Then I have to decide what package is the "correct" one to have it installed, what is often impossible, also because documentation is nearly always missing.

[Buggie]

Because there will be players who extract such a modified package from cache, use it in their own maps, distribute that collection and, voilà, a new file mismatch is born. Mismatch in the sense that the name is equal but content is different.

I'm not sure if you get the point.
Conformed packages are identical for networking.
The content is the same there.
It's just that the original produces errors, but the corrected version does not.
There can be no "Package mismatch" errors.
The only possible problem is with anti-cheats, which check files by their hash and they need to match bytes to bytes.

In other cases, it does not matter which package will be used on the client or server - they are compatible with each other.

As for the server, your server does not serve files directly.
You can update these files on the server, but leave the original .uz files. Then there will be no flooding in the logs, and clients will not be able to download anything different from the original if direct file serving is disabled.

For example, I am using conformed packages to play on your server. They are on the client and do not spam me into the log. Everything is working.

I don't see any problem here, at least not yet anti-cheat is involved. In the case of anti-cheat, you need it to allow the use of these modifications. I do not know on what principle whitelist work there. You'd better find out from the creator of the anti-cheat.
If you can whitelist these packages on your server, that solves the problem.

[sektor2111]

Mismatch versions are versions non-conformed.
Then... stock has this feature since forever 436/440 player is playing in v451 without issues... But... it's not the same for 451 player to 440/436 server... due to awesome changes done at 451 - exactly this is what I'm talking about for any new patch: Do not change structures.
Either way fixing rocket X Y Z won't be easy without reconfiguring functions. A new mismatch is Player's fault - this is not stock and so not a need for being un-cached. If they have nothing else better to do, it's their problem. I'm heading for server's stability as first priority, players are going to be stable too if they are nice, if not, they punish themselves based on their own actions. Let's see... common and nice UT player can actually play having files without any mismatch. How ? Take a look at this:

Code: Select all

078AA6164EEABBB22A38F1A981372317=UTDMskaarjberserker.u
9B5CF35D438FB5E7EAC770B027FDD4A9=UTDM.u
DB4C94064AFAD658E54EBEBFADCB98D6=UTDMskaarjberserker.u
FADA4EEC44B2DC6CC33C329637F64198=UTDMskaarjberserker.u

Did you see ? It's all in cache and no issues are happening... UT allows user to mitigate n00b evil codes by accepting cache content helping both admin and player. Jesters can go mooing elsewhere... From time to time I'm cleaning these as long as they are testing results and I don't need all versions cached.

Next oldskool solution - replace all crap or just remove it. You can easily add in maps other stable types renamed and improved... the price is memory resources but... might be acceptable. Example: in map MH-URealv3 my patching plugins are destroying all those jets including their navigation relations and are added extra needs: Ammo, health, lights, occluding trap holes, more power for Tentacles and full run-time Bot Support. Flight in that map doesn't make any sense, I prefer ground assault with my "boys" and "girls".

[RocketJedi]

Curious as to why this old rocket-X version is even being looked at. Don't get me wrong this is probably my favorite Rocket-x ever.

[Barbie]

I'm not sure if you get the point.

Lets have an example then. Imagine I create a map and use the package spinner.u. I have at least two versions here, CRC32 of the one is 8EE582E2, of the other A396B450. As a mapper I don't see any difference between both. Which one should I use for distributation? Ok, let's take that one, who cares.

Some time later a server maintainer downloads that distributation: "oh no, again another version of spinner.u". Which one should he install on server?
So I'm not really a friend of files with same names but different content.

[Buggie]

If this spinner.u conformed to each then no any side effects (of course they need be also network compatible).

You can put any in distribution then.

And server admin can install any version to server. No difference at all in terms of network play.
So I do not see any problem here.

Who do not care - they use any version.
Who want goes deep download from forum "proper" version. Which not flood in the log for example.

--- EDIT ---

Server admin need be smart and understand how things work under the hood. If he use CRC32 as rule "file is network compatible" then this is bad point of view.
CRC32 can be different content can be same.
Try change one letter via HEX editor in source code attached in package. In comment for example.
CRC32 not same. Content same and network compatible.

[sektor2111]

I don't recall well if was about spinner or another package but as far as I recall one has Player/Bot stuff - a sort of skinning spree, the other one has monsters. They are not compatible in any way and I don't know if they can be conformed just like that. They are different things.

To not forget another renamed copy of spinner.u - monster - which I can recall and causing lousy references in maps... They were good to ruin everything members of some UT community, "loving" UT... no wonder... and then I think spinner monster has two versions, two generations 1. A new package what GUID will use ? First or second ?

Which one is for mapping ? Sektor says: All right, Garbage Lord, let's "MyLevel" the dumb thing and there we can fix functions and what we want. When a file has such a generic name which even a baboon can use, in order to prevent pain based on linkers pointing nonsenses loaded from lousy packages, MyLevel is the friend, either way converting package not just renaming it.
Do we have maps already made ? Good ! Hack Patch them well in run-time.
All I have to say is that you'll see duplicates, renamed copies such as WarNukingGround and WarNukingGroundFix - yeah, veery fixed - the same file,

Fix_TheSame.PNG

and many more with errors. You can fix 100-200 packages if you want, perhaps it's good or... I don't know. Me one I keep my opinion - never using maps with such "packages". To not forget those textures locking down renders based on a "Byte Material" which UT doesn't have.

If player want such maps - EDITOR is the tool, no comments and no discussions - waste of time. If mappers were that good to do these things, I doubt to see one of them capable to fix the miserable assets spread in public. This package is not the only one demonstrating mental insanity - you have no business with these people.

[Barbie]

To keep long story short: if I get a file collection to install at server with a package that differs to the one that is already installed at server I don't want to spend hours to investigate which one is "better" and whether other maps work with that new file version.