EnglishGermanFrenchRussianItalianSpanish
Log inRegister
 
[TOOL] X3 Customizer 3.12.1
Post new topic Reply to topic Goto page Previous  1, 2, 3, 4, 5  Next
View previous topic :: View next topic
Author Message
SirNukes





Joined: 31 Mar 2007
Posts: 182 on topic

Thank you for registering your game
PostPosted: Mon, 11. Jun 18, 23:25    Post subject: Reply with quote Print

Interesting. The path thing is as you say, taking either the x3 or addon folder, though I can touch up the error message a little bit. The gzip thing I will have to read up on. The x3 .pck files are gzipped versions of text files; when searching for the file to modify, if the tool finds a pck file then it uses the python gzip package to unpack it for reading/editing. I have never had trouble with it on my end, so I need to learn more about what gzip is doing to get an idea of what is going wrong for you. Since the file loader is outside my normal transform exception handler, the problem stops the entire tool run; that I could touch up as well.

Back to top
View user's profile Send private message
GageDragon





Joined: 26 Apr 2016



PostPosted: Mon, 11. Jun 18, 23:42    Post subject: Reply with quote Print

A couple things so you dont waste time looking into anything if its all my fault..
I notice when I run the authors_transform it is looking at python in programdata, which I do not have, it's after that the gzip error hits. I also do not have a source folder since I am lazy and have not opened xeditor yet and tried to figure out how to do that lol. If either of those are relevant.

Still it is odd that it partially runs at G:\X3xrm but not at all at G:\X3xrm\addon

Back to top
View user's profile Send private message
SirNukes





Joined: 31 Mar 2007
Posts: 182 on topic

Thank you for registering your game
PostPosted: Tue, 12. Jun 18, 01:27    Post subject: Reply with quote Print

3.4.1 has been pushed with some tweaks including nicer gzip error catching.


Just as a warning, the Authors_Transforms includes some options that are hard to roll back once added to the game if the game is saved, such as the factory and ship variants (which get added to shipyards). I mostly make that file available for extended examples of calling transforms.

For the game path, these should hopefully be functionally equivalent:
path_to_x3_folder = r'G:\X3xrm'
path_to_addon_folder = r'G:\X3xrm\addon'

For the ProgramData/Python thing, it might just be a relic of how the executable is packaged up using PyInstaller. At least, if I rename my python distribution folder, the packaged customizer still runs okay.

For the gzip issue, I tracked it down to the X3 Plugin Manager, which will generate a TWareT.pck file but compresses it with something other than gzip. My current best guess from digging around and looking at some source code is that older X games and tools used to use deflate through zlib, so my current theory is that the plugin manager is using deflate still. I am poking around looking for a working solution now.

Back to top
View user's profile Send private message
SirNukes





Joined: 31 Mar 2007
Posts: 182 on topic

Thank you for registering your game
PostPosted: Tue, 12. Jun 18, 03:15    Post subject: Reply with quote Print

3.4.2 is now up, and should support the X3 Plugin Manager generated pck file.

After spending some time going through x3 editor source code looking for how it handles decompression, and then the x2fd.dll source code (thanks doubleshadow for making source available), I found that the plugin manager appears to use an x2 pck format. (My theory about deflate instead of gzip was wrong.) Anyway, the customizer now tries x2 style decompression as a fallback when direct gzip fails.

Back to top
View user's profile Send private message
GageDragon





Joined: 26 Apr 2016



PostPosted: Tue, 12. Jun 18, 03:36    Post subject: Reply with quote Print

Aha will try 3.4.2 then. Thanks for this.

Was just coming on to say I kinda found a work around for the gzip thing in 3.4.1 by deleting the file created by plugin manager then running customizer and then rerunning plugin manager so it recreates that file. No error then. It might even be better off this way if customizer makes any ware size changes then plugin manager would need to recreate the file anyhow I believe.

Also not sure if I did it right but I grabbed the source and input_script files from the master and just put those into my folder. If that was correct then it is still erroring when I try g:\x3xrm\addon. I do see an x3_customizer_logs folder in addon so I guess it is working correctly regardless.

As far as changes being permanent I dont mind. I plan on starting over once I get this working anyway Very Happy

I noticed in my rummaging through authors_transforms some settings for restoring ammo based weapons. I look forward to breaking my game more trying to figure that out next because I miss ammo weapons lol...

edit: well it still errors with the plugin file in folder as well as the path error, that is of course if I am doing things correctly by grabbing from the master on git and adding the changed files into my folder. Docu and readme both have 3.4.2 in them

edit2: grabbed the compiled version and it runs with no gzip error now but g:\x3xrm\addon now gives error Exception: Path to the AP/addon folder appears invalid(path: G:\X3xrm\addon\addon).. kinda funny but no not really lol

edit3: it is renaming the file to TWareT.pck.x3c.bak, maybe it really should be left alone and just rerun plugin manager after customizer?

Back to top
View user's profile Send private message
SirNukes





Joined: 31 Mar 2007
Posts: 182 on topic

Thank you for registering your game
PostPosted: Tue, 12. Jun 18, 05:14    Post subject: Reply with quote Print

If you want to run the python code directly, I won't worry too much about putting out new releases for minor changes.

3.4.3 source code is uploaded, and changes handling of path problems a little bit: it will now raise a hard exception if the x3/addon path looks wrong instead of attempting to still run (with a command line option to override this behavior, if desired). The error messages should show what paths are being used for the base x3 and addon folders, so hopefully that teases out whatever problem you are having.

Are you sure you aren't using something like:
path_to_x3_folder = r'G:\X3xrm\addon' ?
Because that will make the tool think the path is to the base x3 folder, and 'addon' will get appended again. (Perhaps I will add a check for addon\addon to catch this.)

For the plugin manage integration, the plugin manager should run first, though it may work in either order. The customizer will see the twaret.pck file and use it as the base for any edits, then will rename the pck file when outputting twaret.txt to avoid conflicts (x3 prioritizes pck files over unpacked txt or xml files). The plugin manager might do the same thing in reverse, loading the customizer txt file for editing, but I haven't tested that yet.


Edit:
The plugin manager does not capture changes in the twaret.txt file when generating its own, so it will need to be run first, with the customizer being run after the plugin manager is closed. It appears user edits to twaret.txt in general are ignored by the plugin manager.

Back to top
View user's profile Send private message
GageDragon





Joined: 26 Apr 2016



PostPosted: Tue, 12. Jun 18, 18:32    Post subject: Reply with quote Print

Yes path_to_x3_folder = r'G:\X3xrm\addon' was exactly what I was trying to use with authors_transform because that worked with example. That explains the problem at least Very Happy


Good to know about plugin manager then thanks for the fixes.

I would prefer compiled but there is no need to release the smaller fixes imo.

Back to top
View user's profile Send private message
SirNukes





Joined: 31 Mar 2007
Posts: 182 on topic

Thank you for registering your game
PostPosted: Sat, 23. Jun 18, 09:54    Post subject: Reply with quote Print

Updated to 3.5.2.

The big addition deals with excess spaceflies generated accidentally by some mods, which accumulate over time and slow down the game. Eg. 85% slowdown of Seta after 10 game days in my own case. Mods affected include Improved Races 2.0 v1.08, Salvage Command Software v4.11, possibly Gazz' Missile Defense Mk2, and likely others.

Kill_Spaceflies will clean out the accumulation by editing the KC to swap the "is disabled" script command (only ever used on spaceflies) to instead kill them after a 10 second delay. (Without this delay, some other X3 engine problems crop up when the mods try to access the dead spacefly.) This uses some hardcoded addresses and so it does not work on LU currently, but that support could be added easily if wanted.

Prevent_Accidental_Spacefly_Swarms will edit the KC such that the "create ship" command no longer performs an undocumented spawn of a spacefly swarm. This will cause it to behave the way the affected mods were expecting, putting a stop to spacefly accumulation. This one does work on LU, though I don't have enough experience with LU to know if spaceflies are a problem in any of those mods.

You can check for spacefly accumulation in the script editor, checking how many of the spacefly scripts (idle or follow) are active. It should generally be 0 up to a couple dozen or so (depending on sector asteroids); problematic mods build up hundreds or thousands.


Some non-spacefly changes are included as well.

Remove_Factory_Build_Cutscene will edit the time delays to 0 for the cutscene played when placing a factory. Future refinements may allow a user adjustable delay (eg. make it take 25% as long).

Keep_TLs_Hired_When_Empty will stop a hired TL from wondering off when you drop the last factory in its hold.

_Benchmark_Gate_Traversal_Time is a toy transform which removes the inter-sector warp loading delay in games with large complexes by cutting out a low level function call. Side effects are unexplored, so it is not part of the main documentation, and running it requires a full path: Transforms.T_Obj_Code._Benchmark_Gate_Traversal_Time().


Other than transforms, this update converts the python code fully into a multi-layer package, making it generally easier to work with and matching the style I use elsewhere in my larger programs. A by-product is that user input scripts need to swap from "from Transforms import *" to "from X3_Customizer import *".

The documentation generator now supports a BB code format, and the top post in this thread has been updated to be somewhat pleasant.


Edit:
I thought XRM had a spacefly problem, but was mistaken and the problem was in SCS.

Back to top
View user's profile Send private message
Aldebaran_Prime



MEDALMEDALMEDAL

Joined: 20 Feb 2010
Posts: 1039 on topic
Location: Düsseldorf, Altbiersektor
Thank you for registering your game
PostPosted: Sun, 24. Jun 18, 00:21    Post subject: Reply with quote Print

I just tried version 3.05.1 to get running and to try your new Kill_Spaceflies() module.
I never used Python - so it's my first try.

I extracted your archive X3_Customizer_v3.05.1.zip to "C:\Users\Harald\Desktop\Neuer Ordner"

Then, I created a new transform-configuration "Spacefly_transform" in folder "input scripts" with the following content:
Code:
# Import all transform functions.
from X3_Customizer import *

Set_Path(
    # Set the path to the X3 installation folder.
    path_to_x3_folder = r'C:\Users\Harald\Desktop\AP QA',
)

# Kill spaceflies spawned before Prevent_Accidental_Spacefly_Swarms
#  was added, lagging the game.
Kill_Spaceflies()


Then I opened a cmd window and changed the directory into the "...Neuer ordner" where I extracted your archive. There I tried to start the Transformation, but get a "Obj_Patch_Exception":
Quote:
C:\Users\Harald\Desktop\Neuer Ordner>Launch_X3_Customizer.bat input_scripts\Spac
efly_transform.py
Attempting to run input_scripts\Spacefly_transform.py
Skipped Kill_Spaceflies due to a Obj_Patch_Exception exception.

Do I need to extract any obj.files from a .cat/dat before I start your converter?


_________________
Back to top
View user's profile Send private message
SirNukes





Joined: 31 Mar 2007
Posts: 182 on topic

Thank you for registering your game
PostPosted: Sun, 24. Jun 18, 01:29    Post subject: Reply with quote Print

Hm, do you know if you are running any mods which change x3story.obj, or perhaps have an obj file from before AP 3.3?

That exception is thrown when a search is made on the obj file for a reference code section (basically a series of bytes); if that section is not found, or an unexpected number of such sections is found, the tool throws an error and skips the transform.

Different versions of the obj file will change around internal addresses for function calls. Since I swap out some function calls for the spacefly killing, the transform will only work on the version of x3story.obj I made it for (vanilla AP 3.3). Creating versions for other obj files wouldn't be hard, as long as I can get a copy the file to pick out the different addresses.

Back to top
View user's profile Send private message
Aldebaran_Prime



MEDALMEDALMEDAL

Joined: 20 Feb 2010
Posts: 1039 on topic
Location: Düsseldorf, Altbiersektor
Thank you for registering your game
PostPosted: Sun, 24. Jun 18, 14:31    Post subject: Reply with quote Print

yes, this was it - I stiil used a 04.cat/dat from X3AP 3.2, not from 3.3. Now I got "Successfully ran Kill_Spaceflies" and in the game-folder the directory "L" was created with a x3story.obj in it.

When I load my savegame, open the script-editor and the script-task statistics - it's great to see how the number of running spacefly scripts goes down from 5000 to 0 in some seconds!

X³: Reunion
THANK YOU VERY MUCH!!!

I think it is worth to mention, that, after this clean-up a new save needs to be done, then close X3AP and delete the just generated x3story.obj from L, but otherwise you never will find any spacefly in game any more, because they destroy themselves immediately as long your modified x3story.obj is used.

So after this cleanup the player either needs to generate a new modified version of the game with your modified create_ship command or with the bugfix for the installed mod-scrips like IR2.0

As you reported in the other thread, the increase of FPS in normal play ist not so big - I just got 2-3 FPS after deletion and reload. This is much less, when I deleted 5000 Spaceflys which are not in sector NULL, but in "normal sectors"
But the gameplay in sinza and during battles should have a benifit of this deletion.


_________________
Back to top
View user's profile Send private message
SirNukes





Joined: 31 Mar 2007
Posts: 182 on topic

Thank you for registering your game
PostPosted: Sun, 24. Jun 18, 23:01    Post subject: Reply with quote Print

Good to hear it worked out.

You can also remove the changed file by rerunning the tool with Kill_Spaceflies removed (or commented out), or run the tool with the -clean flag. Each run creates a log of which files were created (with hashes) or renamed, so that a following run can clean out prior changes.

Back to top
View user's profile Send private message
|K.O.S.H.





Joined: 19 Dec 2003
Posts: 3103 on topic

Thank you for registering your game
PostPosted: Mon, 2. Jul 18, 13:42    Post subject: Reply with quote Print

Can you please explain, how exactly you kill the spaceflies?
i tried for weeks...

Does this tool work with terran conflict (i really need to remove my spaceflies)?

Edit2: I saw: you edit the isdisabled-command.

i also saw, this only works for ap, right?
can you provide an obj file for TC?


_________________
Wing Commander Mod - German Topic
06.07.11 - v1.1 RELEASED!
Back to top
View user's profile Send private message
|K.O.S.H.





Joined: 19 Dec 2003
Posts: 3103 on topic

Thank you for registering your game
PostPosted: Mon, 2. Jul 18, 21:35    Post subject: Reply with quote Print

I managed to run aldebarans script in Terran Conflict (created a folder "addon" and put cat01 there), but of course i got an Obj_Patch_Exception.

:/


_________________
Wing Commander Mod - German Topic
06.07.11 - v1.1 RELEASED!
Back to top
View user's profile Send private message
SirNukes





Joined: 31 Mar 2007
Posts: 182 on topic

Thank you for registering your game
PostPosted: Tue, 3. Jul 18, 03:08    Post subject: Reply with quote Print

Updated to 3.6, now with some support for TC. For the most part I just needed to tweak paths in two spots and the rest worked itself out (feels good when that happens), though I took some time to do light testing and update a couple transforms that weren't working.

In the Set_Path function, add "enable_TC_mode = True" as a parameter. Kill_Spaceflies should work for TC 3.4.

Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic Reply to topic Goto page Previous  1, 2, 3, 4, 5  Next
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum
Control Panel
Login Data
The time now is Sat, 18. Aug 18, 11:56

All times are GMT + 2 Hours

[ Disclaimer / Impressum ] | [ Privacy Policy / Datenschutz ]

Board Security

Copyright © EGOSOFT 1989-2018
Powered by phpBB © 2001, 2005 phpBB Group
Template created by Avatar & BurnIt!
Debug: page generation = 0.17056 seconds, sql queries = 29