Renaming a .u package
Renaming a .u package
I took the UT4BarretRiflev1 and changed the amount of ammo in the clip from 10 to 25. My issue is that it now needs to be renamed. I've decompiled it into classes, (12 different files), but after changing and attempting to recompile there are numerous errors where it can't find files, sounds, textures, meshes, etc... I assume that the .u specifies a certain path that they came from and when decompiled those paths no longer exist.
All I need to do is to rename the .u and .int so there are no mismatches. Any ideas?
All I need to do is to rename the .u and .int so there are no mismatches. Any ideas?
- sektor2111
- Godlike
- Posts: 6410
- Joined: Sun May 09, 2010 6:15 pm
- Location: On the roof.
Re: Renaming a .u package
New file conformed to old file won't return any mismatch or another problem if it has original integrity - no new functions or new data.
Either way package can be morphed in Editor using "Obj Load" "Obj SavePackage" directives - check out some tutorials.
By example:
This command:
used even twice if it's needed, with Editor loaded empty, no map or anything else, will cause existence (after toggling dock status) of a new Package called "AnotherMyL.u". All it needs it's selecting and saving it in next moments.
Then... try summon something from new package and see what it does... Perhaps it is advisable to change values and and adjust whatever needs only in newer generated package leaving original alone...
Definitely when you are recreating a package which has textures and sounds, you will need these resources too because they are not generated from nowhere during compiling process, unless you work on it in Editor and all assets are there - at least this is how I changed some stock packages for preventing original poorly written functions to make a mess in my private fun server.
If you can't get this "How To" I'll try to do an animated GIF will all required steps. Aiming Editor 436/440...
EDIT:
When you have new package loaded in a fresh session I think you can adjust various properties of this package and then saving it. Original package can sit untouched.
Either way package can be morphed in Editor using "Obj Load" "Obj SavePackage" directives - check out some tutorials.
By example:
This command:
Code: Select all
obj load file=ReplacedMyL.u package=AnotherMyL
Then... try summon something from new package and see what it does... Perhaps it is advisable to change values and and adjust whatever needs only in newer generated package leaving original alone...
Definitely when you are recreating a package which has textures and sounds, you will need these resources too because they are not generated from nowhere during compiling process, unless you work on it in Editor and all assets are there - at least this is how I changed some stock packages for preventing original poorly written functions to make a mess in my private fun server.
If you can't get this "How To" I'll try to do an animated GIF will all required steps. Aiming Editor 436/440...
EDIT:
Click on it if animation is not running normally.
When you have new package loaded in a fresh session I think you can adjust various properties of this package and then saving it. Original package can sit untouched.
- Feralidragon
- Godlike
- Posts: 5493
- Joined: Wed Feb 27, 2008 6:24 pm
- Personal rank: Work In Progress
- Location: Liandri
Re: Renaming a .u package
If the package compiles just fine with the original name, then you just need to change all the original package name references in the code.
You can do it easily by using any tool that makes it possible to search for a string in a directory, such as Notepad++ for example, or VS Code, or generally any tool that is built around developing code or text.
But don't blindly replace every reference: be sure to look at the context where the name is used, because it could match the package name but not being related with the package name itself.
Having that said, mismatching packages are no longer an issue starting with 469 clients.
Meaning that any player nowadays entering a server using 469 will never again have a mismatching package problem anymore.
However, the reality is that is likely that the vast majority of players haven't yet started to use 469, so mismatches are still a bit of problem for the time being, so for now are still something to be considered.
But... note that 436 does not have any mismatching issues either, as long as the package is not locally installed in the client.
That is to say that any 436 players that have downloaded the package automatically through the server won't have any mismatching issues either: they would need to convert the cached package into a locally installed package for a mismatch to eventually occur.
So package mismatches aren't actually all that terrible unless it's a package that a lot of players have locally installed.
Conformed packages may cause inconsistencies and other issues for clients with the original package.
Case in point, the OP has mentioned that all that he changed was the amount of ammo, which I assume was done through changing a default value.
If a default value is changed in the server to another default value, and if the property that was changed is set to be replicated to the client (meaning that it has relevance to the client), then the client won't ever see this change, and will remain with its own original default value.
This is because replication only happens when the value changes, and from the server point of view the value didn't change, it already started with that value, so the new value is not replicated to the client, which can cause all sorts of inconsistencies and other bugs.
So be very careful with that, "conformed" packages aren't that simple and straightforward, and can cause all sorts of issues if you don't fully understand their real impact.
You can do it easily by using any tool that makes it possible to search for a string in a directory, such as Notepad++ for example, or VS Code, or generally any tool that is built around developing code or text.
But don't blindly replace every reference: be sure to look at the context where the name is used, because it could match the package name but not being related with the package name itself.
Having that said, mismatching packages are no longer an issue starting with 469 clients.
Meaning that any player nowadays entering a server using 469 will never again have a mismatching package problem anymore.
However, the reality is that is likely that the vast majority of players haven't yet started to use 469, so mismatches are still a bit of problem for the time being, so for now are still something to be considered.
But... note that 436 does not have any mismatching issues either, as long as the package is not locally installed in the client.
That is to say that any 436 players that have downloaded the package automatically through the server won't have any mismatching issues either: they would need to convert the cached package into a locally installed package for a mismatch to eventually occur.
So package mismatches aren't actually all that terrible unless it's a package that a lot of players have locally installed.
Not quite.sektor2111 wrote: ↑Fri Mar 19, 2021 9:31 pm New file conformed to old file won't return any mismatch or another problem if it has original integrity - no new functions or new data.
Conformed packages may cause inconsistencies and other issues for clients with the original package.
Case in point, the OP has mentioned that all that he changed was the amount of ammo, which I assume was done through changing a default value.
If a default value is changed in the server to another default value, and if the property that was changed is set to be replicated to the client (meaning that it has relevance to the client), then the client won't ever see this change, and will remain with its own original default value.
This is because replication only happens when the value changes, and from the server point of view the value didn't change, it already started with that value, so the new value is not replicated to the client, which can cause all sorts of inconsistencies and other bugs.
So be very careful with that, "conformed" packages aren't that simple and straightforward, and can cause all sorts of issues if you don't fully understand their real impact.
Re: Renaming a .u package
The original .u file contains all of the resources that it's referencing, but as far as I know you can't extract them using "ucc.exe batchexport" (I may be wrong about this). So I use WOTgreal Exporter for such purposes (I've seen it available for download here before, so a forum search should turn up a link).
When you run it, it'll list all of the packages in your UT system file. So, if the original copy of UT4BarretRiflev1.u is in there it should show up in the list. Then you select it, and look at the menu bar for "Meshes", "Images" and "Sounds" - click each of these to see what it contains for each category. Export everything.
It'll place these resources into a folder called (for example): "C:\Games\Unreal Tournament\PackageName\Images" - for image files (or "Sounds" for sound files, etc.)
If your updated package is called (say) UT4BarretRiflev2, you want to then copy all of these subdirectories from:
C:\Games\Unreal Tournament\UT4BarretRiflev1\Images
...
To
C:\Games\Unreal Tournament\UT4BarretRiflev2\Images
...
Now when you recompile, it should be able to locate the resources that it was complaining about. You might need to rename some of the subfolder names - check that they match what the compiler is looking for it it still complains.
When you run it, it'll list all of the packages in your UT system file. So, if the original copy of UT4BarretRiflev1.u is in there it should show up in the list. Then you select it, and look at the menu bar for "Meshes", "Images" and "Sounds" - click each of these to see what it contains for each category. Export everything.
It'll place these resources into a folder called (for example): "C:\Games\Unreal Tournament\PackageName\Images" - for image files (or "Sounds" for sound files, etc.)
If your updated package is called (say) UT4BarretRiflev2, you want to then copy all of these subdirectories from:
C:\Games\Unreal Tournament\UT4BarretRiflev1\Images
...
To
C:\Games\Unreal Tournament\UT4BarretRiflev2\Images
...
Now when you recompile, it should be able to locate the resources that it was complaining about. You might need to rename some of the subfolder names - check that they match what the compiler is looking for it it still complains.
Tater wrote: ↑Fri Mar 19, 2021 9:01 pm I took the UT4BarretRiflev1 and changed the amount of ammo in the clip from 10 to 25. My issue is that it now needs to be renamed. I've decompiled it into classes, (12 different files), but after changing and attempting to recompile there are numerous errors where it can't find files, sounds, textures, meshes, etc... I assume that the .u specifies a certain path that they came from and when decompiled those paths no longer exist.
All I need to do is to rename the .u and .int so there are no mismatches. Any ideas?
- sektor2111
- Godlike
- Posts: 6410
- Joined: Sun May 09, 2010 6:15 pm
- Location: On the roof.
Re: Renaming a .u package
If you are morphing package like I said into another one, that second package can be edited later without exporting anything. Ammo amount can be adjusted there directly from Editor and it won't affect old package. If package has hard-coded values, it has to be modified and recompiled but it can still support doing this from Editor. I worked not a single time at packages without having meshes and textures as resources operating directly in Editor.
Edit:Demonstration time ON
Testing
NO SOURCE CODE is even needed, it is about adjusting a property which is replicated anyway, code is untouched.
Demonstration time OFF. Yes, boys, simple as that. To not forget that new package with value 25 can be morphed into another one and so on...
If an INT file is needed for some reason, we can talk about it... but first I need to examine properties how are defined...
Edit2:
All classes calling old package must be edited - doable from Editor. Perhaps it would be easier conforming method...
Monster Gaming Server uses conformed stock files and it doesn't need a guardian for sitting alive, it depends on what are you modifying in packages because replication can be helpful if a code demands a property changed for a replicated value... There is a net issue at map switching for plain client, not for an XC client, but that can be my fault because UnrealShare from there has something new... either way client can play there out of big troubles.Feralidragon wrote: ↑Sat Mar 20, 2021 12:33 am Conformed packages may cause inconsistencies and other issues for clients with the original package.
Edit:Demonstration time ON
Obsolete Package removed - it does calls at original package due to hard-coded data...
Testing
Code: Select all
summon UT4BarretRifleV1_1.FUNBarret
summon UT4BarretRifleV1_1.FUNAmmo
Demonstration time OFF. Yes, boys, simple as that. To not forget that new package with value 25 can be morphed into another one and so on...
If an INT file is needed for some reason, we can talk about it... but first I need to examine properties how are defined...
Edit2:
All classes calling old package must be edited - doable from Editor. Perhaps it would be easier conforming method...
Last edited by sektor2111 on Sun Mar 21, 2021 8:30 am, edited 2 times in total.
- Feralidragon
- Godlike
- Posts: 5493
- Joined: Wed Feb 27, 2008 6:24 pm
- Personal rank: Work In Progress
- Location: Liandri
Re: Renaming a .u package
I didn't mean that it wouldn't work in this case necessarily, I just wanted to highlight that your original statement concerning conformed packages was too simplistic and there's more to it than you have initially implied.
Because tomorrow the OP may decide to change something else, and do it in the way you described it, and not working and wondering why.
Since it depends on which properties you change and their implication to the client.
Because tomorrow the OP may decide to change something else, and do it in the way you described it, and not working and wondering why.
Since it depends on which properties you change and their implication to the client.
Re: Renaming a .u package
Yes Ferali, that's all I did. I loaded the package into the actor classes, right clicked and changed the "clipcount" in the default properties. I'm not looking to rewrite someone else's hard work, just make 1 little alteration and change the name to UT4BarretRifleV2
- sektor2111
- Godlike
- Posts: 6410
- Joined: Sun May 09, 2010 6:15 pm
- Location: On the roof.
Re: Renaming a .u package
Then file which I posted can be morphed into whatever V2 with a simple command... exactly as I did at "v1_1" which has exactly that 25 and it has another name... the rest of codes are unchanged - I did not even look at all of them, but around headers...
- About replication chapter between generations -
As far as I know default properties can be different between generations. It's why Gen2 or whatever X, must do some change triggering replication, if such code has no place due to whatever structure, conforming file will fail and it has to be renamed against mismatching. A sanity check is compatible, simulated functions can do whatever variable changes, and then it allows whatever replicated stuff to be changed in client and client will follow what server has. Of course, for real junkish packages, conforming them it's not an answer...
Usually I like packages written and preserving functions/variables for future needs - if are needed, allocating a bit of reserved space doesn't hurt anybody... especially if these are aiming Execution Authority and not that much the client. Somewhere here code can switch that clipcount and replicating it but it's more simple to import original package as another one, changing variables and saving newer renamed package - without compiling anything.
Solution 3 "AlternatePath"
Configure a package where a weapon is a subclass of said original weapon using as ammo another subclass of original ammo for this rifle. Being child classes they won't need sounds and anything because here are changed ammo charges/clipcount and nothing else at weapon itself - so original assets are being used. I'll bet that expanded package will have less than 5kb.
- About replication chapter between generations -
As far as I know default properties can be different between generations. It's why Gen2 or whatever X, must do some change triggering replication, if such code has no place due to whatever structure, conforming file will fail and it has to be renamed against mismatching. A sanity check is compatible, simulated functions can do whatever variable changes, and then it allows whatever replicated stuff to be changed in client and client will follow what server has. Of course, for real junkish packages, conforming them it's not an answer...
Usually I like packages written and preserving functions/variables for future needs - if are needed, allocating a bit of reserved space doesn't hurt anybody... especially if these are aiming Execution Authority and not that much the client. Somewhere here code can switch that clipcount and replicating it but it's more simple to import original package as another one, changing variables and saving newer renamed package - without compiling anything.
Solution 3 "AlternatePath"
Configure a package where a weapon is a subclass of said original weapon using as ammo another subclass of original ammo for this rifle. Being child classes they won't need sounds and anything because here are changed ammo charges/clipcount and nothing else at weapon itself - so original assets are being used. I'll bet that expanded package will have less than 5kb.
Re: Renaming a .u package
I used one of the above methods and it's, for the most part. I used Wotgrael exporter and exported all sounds, textures, and meshes. It wants to compile now with none of the previous errors but I'm getting this "ucc error Expands' not allowed here".
- sektor2111
- Godlike
- Posts: 6410
- Joined: Sun May 09, 2010 6:15 pm
- Location: On the roof.
Re: Renaming a .u package
There is a code-syntax problem.
Post here the name of package exactly as you want it and give me a few minutes. Is it okay UT4BarretRifleV2 ?
Post here the name of package exactly as you want it and give me a few minutes. Is it okay UT4BarretRifleV2 ?
Re: Renaming a .u package
I've taken care of those errors, I believe. It would say "ucc error Expands' not allowed here noise extends noise". I removed the "extends noise". There were a few places that came across like that. Right now I get "Error, Unexpected end of file at end of Class". I did come across 2 open brackets that don't highlight when clicking by them. (notepad++). I've turned the second 1 around so now they paired but the error is dtill there.
Re: Renaming a .u package
It's much easier to morph the package sektor posted into another package - I did that in a couple of minutes (UT4BarretRifleV2.u) which I can post should you wish.Tater wrote: ↑Sat Mar 20, 2021 11:43 pm I've taken care of those errors, I believe. It would say "ucc error Expands' not allowed here noise extends noise". I removed the "extends noise". There were a few places that came across like that. Right now I get "Error, Unexpected end of file at end of Class". I did come across 2 open brackets that don't highlight when clicking by them. (notepad++). I've turned the second 1 around so now they paired but the error is dtill there.
Re: Renaming a .u package
Very much so, at this point I'd welcome anythingOjitroC wrote: ↑Sat Mar 20, 2021 11:57 pmIt's much easier to morph the package sektor posted into another package - I did that in a couple of minutes (UT4BarretRifleV2.u) which I can post should you wish.Tater wrote: ↑Sat Mar 20, 2021 11:43 pm I've taken care of those errors, I believe. It would say "ucc error Expands' not allowed here noise extends noise". I removed the "extends noise". There were a few places that came across like that. Right now I get "Error, Unexpected end of file at end of Class". I did come across 2 open brackets that don't highlight when clicking by them. (notepad++). I've turned the second 1 around so now they paired but the error is dtill there.