EnglishGermanFrenchRussianItalianSpanish
Log inRegister
 
[Script] Custom Factory Setup Library v1.4 (Updated 4/11/06)
Post new topic Reply to topic Goto page 1, 2, 3  Next
View previous topic :: View next topic
Author Message
Armegeddon





Joined: 26 Dec 2003
Posts: 385 on topic

Thank you for registering your game
modified
PostPosted: Thu, 2. Mar 06, 09:43    Post subject: [Script] Custom Factory Setup Library v1.4 (Updated 4/11/06) Reply with quote Print

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.

Quote:

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:

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




_________________
There is a thin line between genius & insanity i have erased this line

Armegeddon's X3 scripts and mods


Last edited by Armegeddon on Tue, 11. Apr 06, 09:47; edited 11 times in total
Back to top
View user's profile Send private message
Naffarin





Joined: 03 Dec 2005
Posts: 465 on topic

Thank you for registering your game
PostPosted: Thu, 2. Mar 06, 10:04    Post subject: Reply with quote Print

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 Smile

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





Joined: 26 Dec 2003
Posts: 385 on topic

Thank you for registering your game
PostPosted: Thu, 2. Mar 06, 10:09    Post subject: Reply with quote Print

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
Back to top
View user's profile Send private message
Naffarin





Joined: 03 Dec 2005
Posts: 465 on topic

Thank you for registering your game
PostPosted: Thu, 2. Mar 06, 10:10    Post subject: Reply with quote Print

not in setup scripts

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





Joined: 26 Dec 2003
Posts: 385 on topic

Thank you for registering your game
PostPosted: Thu, 2. Mar 06, 10:11    Post subject: Reply with quote Print

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
Back to top
View user's profile Send private message
Armegeddon





Joined: 26 Dec 2003
Posts: 385 on topic

Thank you for registering your game
PostPosted: Thu, 2. Mar 06, 10:24    Post subject: Reply with quote Print

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
Back to top
View user's profile Send private message
Naffarin





Joined: 03 Dec 2005
Posts: 465 on topic

Thank you for registering your game
PostPosted: Thu, 2. Mar 06, 10:33    Post subject: Reply with quote Print

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.

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





Joined: 26 Dec 2003
Posts: 385 on topic

Thank you for registering your game
PostPosted: Thu, 2. Mar 06, 10:40    Post subject: Reply with quote Print

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
Back to top
View user's profile Send private message
Armegeddon





Joined: 26 Dec 2003
Posts: 385 on topic

Thank you for registering your game
PostPosted: Thu, 2. Mar 06, 11:17    Post subject: Reply with quote Print

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
Back to top
View user's profile Send private message
Cycrow
Moderator (Script&Mod)
Moderator (Script&Mod)



Joined: 15 Nov 2004
Posts: 20511 on topic
Location: London
Thank you for registering your game
PostPosted: Thu, 2. Mar 06, 15:29    Post subject: Reply with quote Print

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


_________________
My Scripts | MY X3TC Scripts | X3 Plugin Manager | Custom Gui
Back to top
View user's profile Send private message Visit poster's website MSN Messenger
Armegeddon





Joined: 26 Dec 2003
Posts: 385 on topic

Thank you for registering your game
PostPosted: Sat, 4. Mar 06, 08:32    Post subject: Reply with quote Print

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
Back to top
View user's profile Send private message
Armegeddon





Joined: 26 Dec 2003
Posts: 385 on topic

Thank you for registering your game
PostPosted: Sun, 5. Mar 06, 01:44    Post subject: Reply with quote Print

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
Back to top
View user's profile Send private message
Cycrow
Moderator (Script&Mod)
Moderator (Script&Mod)



Joined: 15 Nov 2004
Posts: 20511 on topic
Location: London
Thank you for registering your game
PostPosted: Sun, 5. Mar 06, 03:10    Post subject: Reply with quote Print

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


_________________
My Scripts | MY X3TC Scripts | X3 Plugin Manager | Custom Gui
Back to top
View user's profile Send private message Visit poster's website MSN Messenger
Armegeddon





Joined: 26 Dec 2003
Posts: 385 on topic

Thank you for registering your game
PostPosted: Sun, 5. Mar 06, 03:33    Post subject: Reply with quote Print

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
Back to top
View user's profile Send private message
Armegeddon





Joined: 26 Dec 2003
Posts: 385 on topic

Thank you for registering your game
PostPosted: Wed, 15. Mar 06, 15:07    Post subject: Reply with quote Print

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
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic Reply to topic Goto page 1, 2, 3  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 Mon, 25. Jun 18, 04:24

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.11367 seconds, sql queries = 29