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.
lib.Custom.Factory.CheckerCode: 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
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