[Script] Custom Factory Setup Library v1.4 (Updated 4/11/06)

The place to discuss scripting and game modifications for X³: Reunion.

Moderators: Moderators for English X Forum, Scripting / Modding Moderators

Armegeddon
Posts: 385
Joined: Fri, 26. Dec 03, 14:37

[Script] Custom Factory Setup Library v1.4 (Updated 4/11/06)

Post by Armegeddon » Thu, 2. Mar 06, 09:43

I came up with the idea for this script after using Ashleys.X3.Factories and Stevio Combat Fabs and getting tired of having to manually setup the factories every time I placed one.


Download Custom Factory Setup Library V1.4 Requires Cycrow installer

I have also finally finished a configuration file for use with Ashleys.X3.Factories .

Currently awaiting updated mod from Ashley. DO NOT DOWNLOAD if using 1.4 patch.
You can download it here: Custom Factory Library for Ashley's XL Fab Mod Requires Cycrow installer

Currently awaiting updated mod for DDRS and XL fabs. DO NOT DOWNLOAD if using 1.4 patch
Merged Ashley's XL mod with DDRS 2.1d. Please read this post for information on installing it.

Download link for Ashley's XL fab merged with DDRS 2.1d



The Readme pretty much explains what the script does and doesn't do.
Custom factory setup V1.4

These 3 scripts will allow non-standard factories to actually work correctly.
Utilization of the scripts requires no actions on the part of the end user, but does require some from
the creator of any mods/scripts that utilize factories other than the default ones that are included in
the game.

NOTE: If you end this task from the global task list, you will manually have to reset the global array.
This can be done simply with a script with a single line:

001 set global variable: name='Custom.Factory.Array' value=null

Failure to do so will prevent the Checker from starting up again.


Four files are included in this package:

lib.Custom.Factory.Checker
lib.Custom.Factory.List
lib.Custom.Factory.Stop
setup.Custom.Factory


setup.Custom.Factory
Starts the script.


lib.Custom.Factory.List
This is for creating the global list of factories that need to be modified in order to work correctly.
In order for this package to actually do anything besides take up a few CPU cycles from other parts of the
game, information about each custom factory needs to be sent to this script.

When called this script will ask for three(3) items of information:

1: New.Factory.Name , Var/Station Type , 'Factory Type'
This is the station type that you want to change.
NOTE: If you do not provide a Factory Type then the script will clear all entries from the global list.
Useful if you decide to alter your configuration script to have different products/resources and want to
start the list from scratch. Doing this will also clear the Custom.Factory.Setup local variable from all
existing player stations so they can be modified again.
NOTE2: There is currently no check as to whether a station has products or resources already on it when the
station is altered. Means that there is a good chance products and resources will be lost on the next update
of a changed list if the station was already producing something.

2: New.Product.Array , Value , 'Product Array'
This is an array of the products that you wish the factory to produce. If you want to have more than one
product, you must send an array of Var/Ware of the items. If you only want the station to produce a single
product, you can just use that Var/Ware for Product Array.
NOTE1: Make sure to 'array alloc: size=0' prior to appending items to that array, or 'array alloc: size=#'
before assigning them to individual spots. Failure to 'alloc' will result in an empty array, no matter how
many items you think you added to it.
NOTE2: If Product Array is empty, this will signal that you want to remove New.Factory.Name from the list. Will
also remove the Custom.Factory.Setup local variable from existing player station of New.Factory.Name so they can
be reconfigured.
NOTE3: If you decide to use the same variable for multiple factories, you CANNOT 'resize array <var> to <num>'.
This will prevent the variable from resetting correctly and will return incorrect/nonsensible data to the List
script. Use 'array alloc' instead.

3: New.Resource.Array , Value , 'Resource Array'
This is an array of resources that you want the factory to use. If you want the station to only use a single
resource, you can just use that Var/Ware for Resource Array.
NOTE1 applies here also.
NOTE2: If you provide a Product Array, but not a Resource Array, whatever resources are currently installed on
Factory Type will remain unchanged.
NOTE3 applies here also.

Code: Select all

Example of script:
001 $factory.type = Argon Heavy shield Production Complex
002 $products = array alloc: size=0
003 $resource = array alloc: size=0
004 append 1 GJ Shield to array $products
005 append 10 GJ Shield to array $products
006 append Meatsteak Cahoonas to array $resource
007 append Ore to array $resource
008 append Energy Cells to array $resource
009 @ = [THIS] -> call script 'lib.Custom.Factory.List' : Factory Type=$factory.type Product Array=$products 
      Resource Array=$resource
010 return null
lib.Custom.Factory.Checker
This is a looping script that will scan all of the players' factories and see if they need to be setup correctly.
If it finds a player owned factory that is in the global list, it will remove all existing products and resources
(if Resouce Array was provided) from that factory and add the products and resources that were provided to
lib.Custom.Factory.List
The script will also place a local variable on the factory to ensure it does not attempt to 'setup' the factory more
than once, as that would totally screw up the production cycle for the factory.
Unless Egosoft makes it possible to detect, whether by a signal or allowing a script to intercept the command, when a
station is placed, there is no other way to find new stations other than searching the entire universe every so often.
NOTE: Until Egosoft makes it possible to detect and select a station inside a complex, this script will have no affect
on factories that are part of a complex. It will only work on standalone factories.
NOTE2: A multi-product station placed into a complex with a Complex Construction Kit will only produce the first product
from that station. Even if that product is maxed out and there are maximum resources, while in the complex, that station
will only produce ONE of the product.

The current way the script works is; for each Factory Type in the global list, it will scan all of the players' stations
for factories that match that type. Since this script loops forever, until the task is killed (see below), there is a
10-50 ms wait after it looks at each player factory to prevent it from delaying other scripts. After finishing one sweep
through the global list the script will wait 30 seconds before doing the next sweep.
WARNING: Due to the way the script engine lists wares/stations/etc, any changes to 'types/factories.txt' will possibly
make your configuration script incorrect. This is because, although the game apparently identifies wares (stations are
considered a ware) by an ID tag, the script engine identifies wares by a reference number, which appears to be based off
of the ware position in the types file. Whether this is a shortcoming of the script engine, or XML I don't know, but
things would be much simpler if it referenced the ID tag instead of the number.

lib.Custom.Factory.Stop
In the event that it is necessary to interrupt lib.Custom.Factory.Checker for whatever reason, simply call this script
and it will kill setup.Custom.Factory.Check as soon as it finishes the current sweep through the the player station list,
or when it starts the next sweep, which is 30 seconds after finishing the last sweep. Don't see much need for this to be
used under normal circumstances unless you wish to modify the script.
You can restart lib.Custom.Factory.Checker by simply calling it from a script. Recommend using the START prefix so your
script can end, otherwise they'll both be locked together and yours wont end until lib.Custom.Factory.Stop is called from
somewhere else, or a version update is required.

version history

v1.0 Initial release
v1.1 * Removed some debug messages
* Split main code from setup to correct for author stupidity
* Fixed update code to actually work
V1.2 * Various bugfixes that I can't remember
V1.3 * Update routine now TRUELY works finally
* Optimized code somewhat
* Made all files Shared in Cycrows script manager
V1.4 * Fixed bug preventing XXL factories from being setup correctly
Last edited by Armegeddon on Tue, 11. Apr 06, 09:47, edited 11 times in total.
There is a thin line between genius & insanity i have erased this line

Armegeddon's X3 scripts and mods

Naffarin
Posts: 465
Joined: Sat, 3. Dec 05, 10:49

Post by Naffarin » Thu, 2. Mar 06, 10:04

You are using a busy waiting loop in your setup script and are therefore disabling all setup scripts that are run after yours.

Change that :)

Armegeddon
Posts: 385
Joined: Fri, 26. Dec 03, 14:37

Post by Armegeddon » Thu, 2. Mar 06, 10:09

I thought using a wait interrupted the current script and allowed other scripts in the stack to run then returned control once the time had expired?
There is a thin line between genius & insanity i have erased this line

Armegeddon's X3 scripts and mods

Naffarin
Posts: 465
Joined: Sat, 3. Dec 05, 10:49

Post by Naffarin » Thu, 2. Mar 06, 10:10

not in setup scripts

Armegeddon
Posts: 385
Joined: Fri, 26. Dec 03, 14:37

Post by Armegeddon » Thu, 2. Mar 06, 10:11

Doh. didn't know that. will change it right away before too many people try using it.
There is a thin line between genius & insanity i have erased this line

Armegeddon's X3 scripts and mods

Armegeddon
Posts: 385
Joined: Fri, 26. Dec 03, 14:37

Post by Armegeddon » Thu, 2. Mar 06, 10:24

I assume that if I rename the setup to a non-setup file, and just have the setup call that script, the wait wont have any affect on following setups?
There is a thin line between genius & insanity i have erased this line

Armegeddon's X3 scripts and mods

Naffarin
Posts: 465
Joined: Sat, 3. Dec 05, 10:49

Post by Naffarin » Thu, 2. Mar 06, 10:33

If you use a START prefix in the setup script then you are right. If you don't the called script will be executed synchronously so the setup script will just wait for the called script to return.

Armegeddon
Posts: 385
Joined: Fri, 26. Dec 03, 14:37

Post by Armegeddon » Thu, 2. Mar 06, 10:40

Just noticed that from quick look at other setup scripts. Uploading fix now. Thanks for the heads up.
There is a thin line between genius & insanity i have erased this line

Armegeddon's X3 scripts and mods

Armegeddon
Posts: 385
Joined: Fri, 26. Dec 03, 14:37

Post by Armegeddon » Thu, 2. Mar 06, 11:17

Uploaded V1.1

-- Split main code from setup script to correct for authors' stupidity (the waits would prevent any other setup scripts from running)
-- Removed a couple debug messages
-- Made version updater actually work.
There is a thin line between genius & insanity i have erased this line

Armegeddon's X3 scripts and mods

Cycrow
Moderator (Script&Mod)
Moderator (Script&Mod)
Posts: 20534
Joined: Mon, 15. Nov 04, 00:26

Post by Cycrow » Thu, 2. Mar 06, 15:29

yeah setup scripts act differently and are run sequencenly, interupts dont work as it waits till it gets to the end of the script b4 going to the next one

so its always best to make setup scripts run as quick as you can, if you need alot of processing done, just run another process to do it in

Armegeddon
Posts: 385
Joined: Fri, 26. Dec 03, 14:37

Post by Armegeddon » Sat, 4. Mar 06, 08:32

Updated to V1.2 to fix a couple bug I found while writing the library file for use with Ashley's XL fab mod.
For those who want to see an example of how to write a configuration library for use with the main library, take a look at it. What I did isn't the only way it can be done, but was just the way that seemed most comfortable for myself.
Please make sure you read the NOTEs and the warning in each section, otherwise your configuration library may not work the way you expect.
There is a thin line between genius & insanity i have erased this line

Armegeddon's X3 scripts and mods

Armegeddon
Posts: 385
Joined: Fri, 26. Dec 03, 14:37

Post by Armegeddon » Sun, 5. Mar 06, 01:44

Ashley's XL fabs merged with DDRS 2.1d
Uses Cycrows installer.

Please make sure to read the .txt file prior to starting a game.

You will have to make the DDRS mod into a false patch in order to use this. Find out the highest number .cat and .dat files in your main X3 directory. Rename the DDRS .cat/.dat from the mods folder to one higher. ie: If the highest .cat/.dat is 06.cat/06.dat (the 1.3.2Beta patch), rename the DDRS mod to 07.cat and 07.dat. Copy/Move the renamed DDRS mod from the mods folder to the main X3 folder. Install the merged mod using Cycrows installer. Select 'Ashleys XL facts for use with DDRS 2.1d' from the Select Mod Package in the X3 start window. Play.

The only changes I made to SaintAshley's files:
Update the .txt to reflect the new installation instructions, and provide some information about the changed mod.
Added a call to the mod setup script calling the configuration library.
Included my Custom Factory Setup Library so it doesn't need to installed seperately.

Please note that when a new patch is released by Egosoft, you will need to rename or delete the altered DDRS .cat/.dat files from the main X3 folder prior to applying the patch.
Please wait a couple of days after a patch is released for any changes that need to be implemented to any mods before using them.
There is a thin line between genius & insanity i have erased this line

Armegeddon's X3 scripts and mods

Cycrow
Moderator (Script&Mod)
Moderator (Script&Mod)
Posts: 20534
Joined: Mon, 15. Nov 04, 00:26

Post by Cycrow » Sun, 5. Mar 06, 03:10

if uhave the mod files in the script package, the installer can rename the files for you when a new patch is out ;)

Armegeddon
Posts: 385
Joined: Fri, 26. Dec 03, 14:37

Post by Armegeddon » Sun, 5. Mar 06, 03:33

Well, I don't have enough webspace to hold a full altered DDRS mod, and the only file changed is the tfactories.xml to make Ashley's mod work with it. I just repackaged Ashley's mod and suggested making DDRS a false patch since that seems the easiest way to do it.
There is a thin line between genius & insanity i have erased this line

Armegeddon's X3 scripts and mods

Armegeddon
Posts: 385
Joined: Fri, 26. Dec 03, 14:37

Post by Armegeddon » Wed, 15. Mar 06, 15:07

Updated to version 1.3.

changelog:

V1.3 * Update routine now TRUELY works finally
* Optimized code somewhat
* Made all files Shared in Cycrows script manager
There is a thin line between genius & insanity i have erased this line

Armegeddon's X3 scripts and mods

Post Reply

Return to “X³: Reunion - Scripts and Modding”