BETA Release - Factory Loop Delivery Software - v0.12

[Carl Sumner]

I like it! FLDS sounds like a classic example of "Computers should work, people should think." If a script can reasonably figure out something for it's self, then it should.

I think it is good to ease some of the "busywork" for the "less patient players". It is true, though, that we should not make the game play it's self so well that it does not need the player.

[Nazgutek]

I couldn't get ASDS to do deliveries that didn't involve the homebase of the ship. But I'm willing to put that down to me failing to correctly read the minimal documentation.

As for the "playing itself" topic, I'm of the opinion that if you link some stations together, it's damn obvious which wares should be shipped to which stations. After all, Silicon Mines don't buy food

[TSM]

I like it! FLDS sounds like a classic example of "Computers should work, people should think." If a script can reasonably figure out something for it's self, then it should.

I think it is good to ease some of the "busywork" for the "less patient players". It is true, though, that we should not make the game play it's self so well that it does not need the player.

Hmm buit what if it did a better job

[Carl Sumner]

It is true, though, that we should not make the game play it's self so well that it does not need the player.

Hmm buit what if it did a better job

Well... If the player does not have anything to do then they might stop playing. On the other hand, it might give them time to do other things in the game. On the third hand, who needs to feel "outsourced".

(With apologies to Larry Niven. )

[TSM]

It is true, though, that we should not make the game play it's self so well that it does not need the player.

Hmm buit what if it did a better job

Well... If the player does not have anything to do then they might stop playing. On the other hand, it might give them time to do other things in the game. On the third hand, who needs to feel "outsourced".

(With apologies to Larry Niven. )

Being outsourced don't sound so bad

This script has made it profitable for me to have my own sheild factories as I really don't have to keep an eye on it at all got 2 FLDS doing the same loop and then 2 ships with just the sell ware for best price from both of my sheild factories as the FLDS does not require cash to transfer your own goods between stations it works very well

[Dunners]

I have one wuestion about this script.

I used it last night, and it kept coming up unknown command on the command screen.

Is this supposed to happen? Does it mean the script is still working ( Too early to tell in my game)?

Also should I see the list of linked stations anywhere?

Dunners

[TSM]

Duuners it does the Unknown command on mine all I do is watch the ship as soon as it sets off I look in the message log and there should be a list of stations that its going to supply I have no doubt when Nazgutek see's this post he will answer in greater detail

[AdmiralTigerclaw]

Sounds to me like a missing T file or incorrect T file call.

[Nazgutek]

The commands should display as "FLDS" under the trade commands of a TS class ship with Trade Software MK2, and a station should list a command called "FLDS Link Stations".

When you issue FLDS to a ship whose homebase has stations linked to it, you should get a message in your logbook from the ship detailing which stations it will supply wares between.

As for the 'readtext' issue, either you're missing the 449101.xml or 499101.xml file in your <X2>/t folder, or you have a different language version (44 is english, 49 is german, though the german file is in english because I don't know german at all). If you have a different language version, you can copy 449101.xml, change the 44 to your language code, and edit the xml file in notepad and change the language id inside to match.

[Nystalux]

I must have missed something. having trouble activating FLDS. As you suggest i've typed in "Thereshallbewings" from space but only get a short pause. There is no montion of FLDS in any station or ship command console

Is there a sure way to activate the script or am i simply looking in the wrong place?

I've read only positive reports of this script and i'm itching to put it to good use!!

Many thanks . . . . Nystalux (possibly being a bit slow - been up all night, again!)

[Burianek]

After you activate the script editor, you need to save and reload the game for the scripts to launch.
Cheers.

[Nystalux]

Of course! I did find out when i came to play again.


Many thanks.



Ny . . . . .

[Mattrog]

Just a quick one:

If i put 2 Power Plants in a FLDS managed system will it deliver power from one plant to another if one is running low?

[Mattrog]

Oh and just had another thought

I am thinking of seting up a few loops in the unknown sector east of wastelands ... If i linked them all on one fds system - could it cope with sorting out all of the routes without killing the rest of my game?

Looking at about 60 facts:

6 x Power
6 x Crystal Fabs
11 x Raster Refinerys
11 x Chelt Aquariums
7 x Silicon mines
8 x Ore mines
4 x GPPC Forges
1 x LazerTower Forge
ish ...

[Aye Capn]

Hey, I love FLDS, enough to reluctantly return to the forum, in fact, but there is one issue it seems to deal poorly with: multiple sources.

Say I have an array of silicon mines of varying yields which I want to bind into a seamless flow of silicon (like say I wanted to serve 6 factories with Silicon mines yielding 64, 30, 30, and 26).

If I assign all 4 mines to all 6 factories FLDS will only grab silicon from the first mine, so long as any factory is "critical". The delivery ship will waste all its time moving 6 wafers at a time from the first mine in its list while massive stocks of unused silicon build up in the remaining 3. Assigning additional ships doesn't really help, because the problem is in the route-priority algorithm.

Speaking of that, I looked at your code and found the problem: the need at the destination is the sole basis for the priority calculation. Supply is not included in the base priority calculation at all (small loads get a veto, but that only tangentially addresses the source inventory issue, and even that veto gets overruled if a destination goes critical.)

All other things being equal, a 100-unit delivery of a ware is preferable to a 6-unit delivery. The priority calculator should take this into account.

I'm actually wondering whether basing the priority ENTIRELY on load size (as a percentage of destination capacity) wouldn't be the best algorithm. It would certainly be simple.

Speaking of simple, I absolutely LOVE your interface! It is a model of extensibility: to add a station to a delivery route, add it to the hub. To add a ship (or replace a destroyed ship), assign a homebase and give one command. Awesome design!

If FLDS handled multiple source issues elegantly I wouldn't have to make every single silicon mine a hub, and that would make FLDS even better!

[sacq]

Any chance this script will ever be signed?

Cheers,

sacq

[Aye Capn]

I've been doing some more thinking (that's what that burning smell is, if you were wondering).

"Need" is indeed a top priority. It doesn't matter if I can move a full load of unneeded ecells when what I really need to move is half a load of wheat.

"Supply" is a necessary secondary priority -- a 100 silicon wafer transfer is preferable to 6.

What if ... your "Need" priority were calculated as "percentage empty" * 10^3 and your "Supply" priority were added in?

Let's say you had a factory that was out of silicon, and 3 silicon mines to choose from. None of the other fabs in the loop are out of silicon, so the only "100 * 10^3" priority is the empty factory:

100xxx <-- 100,000+ anything gets top priority

Your 3 silicon mines are at 2%, 25%, and 34% capacity. Their route ratings are thus:

100002
100025
100034

An SP in the loop has maxxed out, 100%, but the station that needs energy the most is only 60% empty:

60100 <-- 60,100 is less than 100,034

The smaller load of more-needed silicon is chosen over the larger load of less-critical energy cells.

So why not just break "source" into a separate step? Because integrating it into the priority calculation breaks a tie between different equally-needed goods. (It also makes the code more efficient.)

Take the case of a brand new crystal fab attached to the network:

100085 <-- rating for an ecell route
100080 <-- another ecell route
100030 <-- best rating for silicon
100002 <-- best rating for steak
100013 <-- another silicon route

In this case, 100085, the ecell route, is chosen, because it will fill a need AND move the most stock. It incidentally also picks ecells from the power plant that has the most, keeping it from filling up and shutting down.

The second trip will move the silicon.

By the third trip a few more steaks will be available, maybe double the original 2%, so the food run, by being delayed, becomes twice as efficient.

If the source is empty the route should be rejected: a 100000 priority route is, err, "overstated in value" to put it mildly. (This is already in your code.)

"Critical" might be best defined as 90% or more empty, so that a large shipment to an almost-empty factory is chosen over a tiny shipment to a truly empty one. In fact it may be best to "quantize" the entire demand domain in that way so that a large load in the 20-30% range is chosen over a tiny load at 22% versus a large one at 26%.

Hmm ... you could accomplish that by a smaller "weight factor" on the demand side. "Need * 12 + Supply" might be better than the adamantly inflexible "Need * 100 + Supply". That being the simplest solution I like it best.

[Aye Capn]

I just made my first script edit, to FLDS.Main, and it seems to have worked out. FLDS will now load-balance multiple sources.

The line of code I changed was this:

223 $Route.Priority = $Route.Needed.Amount * 10000 / $Route.Priority

to this:

223 $Route.Priority = ($Route.Needed.Amount * 12 + $Route.Pickup.Amount) * 769 / $Route.Priority

The result on my test loop (SP, QT loop, Crystal loop, silicon imported) was encouraging. The transport always picked the source with the largest inventory and usually chose the destination with greatest need, unless it could make a much larger haul somewhere else.

It also made more ecell runs, which is important: no number of marginal runs of small quantities of steak will ever alleviate the endemic shortage, as steak is produced at the same rate it is consumed. It will always be in shortage. The transport ought not spend all its time hanging around the bakery moving miniscule cargoes of steak.

Using "$Route.Pickup.Amount", the quantity of wares to be picked up, isn't exactly the same thing as using the quantity of wares available at the source. Take the case of an SPP with 3000 ecells versus another with 4000. Since both will max $Route.Pickup.Amount to the TS' cargo bay, the 4000 inventory source isn't weighted any more heavily than the 3000, although it should be.

"$Route.Needed.Amount" just happened to be the low-hanging fruit. I'm lazy.

I'm also thinking maybe 12-1 still overly favors "need". A 4-1 bias would favor larger hauls even more. Heck, even equal weight might be best. The priority of an empty fab would exactly equal the priority of a full-size cargo run, so that even a little bit of available inventory of the needed item would tip the scales in favor of the needy factory -- assuming some other factory wasn't in dire need of the more plentiful resource.

Incidentally, to preserve Naz's 10000 scaling factor (needed because we're dealing with long integers, I assume?) divide 10000 by 1 + the "need bias" coefficient. For my bias of 12 I divided 10000 by 13 to get 769. For a 4-1 bias use 10000 / 5 = 2000.

I think I'm going to give the even bias a try, and see if I get more ecell runs without short-changing the food factories.

[Aye Capn]

There's a problem with using $Route.Pickup.Amount ... to paraphrase Inigo Montoya, "I don't think it means what I think it means."

It seems to include volume, which really skews the priorities in favor of high-volume cargoes, or it would if the "need" factor were toned down (I only unmasked the error by making the two priorities even.)

I'll fix it, of course, but I've noticed something else about FLDS that seems troubling.

Ships running FLDS seem to spend a lot of time blocking on the critical section flag. Furthermore, the more ships you add, the more blocking takes place, regardless of what hub the FLDS ships serve. The more you use FLDS, the less efficient it becomes.

This seems to be global across all "hubs", that is, the critical section flag blocks ANY ship from ANY hub from looking for delivery routes. This would seem to be necessary to allow overlapping hubs, but it also means a ship running FLDS on one side of the galaxy can block dozens of ships on the other.

I've been thinking of a way to fix this. Critical sections are supposed to be short. I think I have a solution.

Keep a list of routes in a global array, a "job board".

Run a route-finding algorithm more-or-less continuously at the producing stations. Each producing station is responsible for posting its best send routes -- with attached priority -- to the job board. Route-finding does NOT get flagged as a critical section.

Ships only flag critical section when they scan for a job or update their job's status.

Producing stations only flag critical section when they update the job board.

Producing stations only keep as many entries on the job board per hub as there are ships running on that hub.

When a ship accepts a job, no other ship may take it. The station that "owns" the job may revise the job as part of its normal "job-posting" algorithm any time up until the ship picks up the cargo.

In my next post I'll give an example of how this scheme would work.

[Aye Capn]

How It Might Work

Powering our factory complex we have 3 Crystal Fabs serving 2 SPP's. We'll call the 2 SP complexes Loop 0 and Loop 1 and the third Crystal Fab complex "X".

Our goal for one of our FLDS loops is to move crystals more-or-less evenly from the crystal fabs more-or-less evenly into the SPP's. We set up an FLDS loop to all 5 and assign a couple of freighters.

We would also like the freighters to handle support for the crystal fabs, except for silicon which is coming in from a separate load-balanced FLDS loop. We therefore add the steak and beef plants to the Crystal FLDS loop.

Total stations: 2 SP, 3 Crys, 3 Steak, 3 Beef

We're feeling lucky and think we can run the whole works on 2 freighters.

Our job board is going to be pretty large, so let's focus in on two contributors to the job board, SP 2 and Cahoona Bakery 1.

SP 2 has been quietly running its route-finder on its 9 possible routes for the past 5 minutes and is ready to post to the job board. It locks the job board and puts up 2 jobs -- one for each ship -- then unlocks the board.

There are a lot of competing jobs, but Crys Fab X was just installed and is running low on energy, so that job has a pretty high priority.

Cahoona Bakery 1 has been building up stock because the TL was late installing Crystal Fab X. It's jobs have been dropping in priority because the other Crystal Fabs are filling up from all the extra steak brought in from Cahoona Bakery X. CB1, however, happens to be the first to "notice" Crys X and along with another low-priority job posts a very high-priority job to the job board.

Freighter 0 just finished a job and locks the job board to find another. It picks the highest-priority job -- a full load of ecells from SP 2 to Crys X -- and flags it. The source and destinaton stations note the accrued inventory adjustments in local variables to make new route-finding calculations update properly. The freighter unlocks the job board and heads toward SP 2.

Freighter 1 does the same thing moments later (after a brief wait for the job board to unlock.) It takes up CB1's steak to Crys X route.

The only problem I see is one we've intentionally caused, a tradeoff to ease the pressure on the critical section flag: stale routes. But that's not as bad as it sounds, as they wouldn't be on the job board but in the individual stations' route-finding algorithms.

Since a job would be "verified" after locking the job board and before posting, the stale, incorrect "high priority" job info would get revised downward to a really lame low-priority job just as it posted to the job board. The actual "highest-priority" job from that station won't get posted until the next cycle of its route-finder.

If in our example CB2's route finder was going nuts over the CrysX delivery, its recalculation at the job board given CB1's claiming of the job revises its priority way downward, so that some other steak delivery might have been a better choice. We won't know until CB2's route-finder completes another cycle.

A final difficulty ... the route-finder algorithm might be the equivalent of line 1 of Elmer Fudd's simple recipe for rabbit stew -- "catch a rabbit". It's going to have to handle somewhat inobvious arcana such as treating changes to its inventory-accrual variables as a "restart calculations" semaphore.

Phew. My head hurts. What do you guys think? Is the "job board" method of minimizing critical section blocks a basically sound idea? Or is it one of those things that sounds simple but is in reality nigh impossible?