old LTN discussion thread

[Optera]

just add the unloader for the first position and you can almost keep the original description
"A depot able to service any vanilla train composition of length 4 or lower"

updated the bp string in OP

edit: on reading what i just wrote, i got an idea to halve the number of combinators. instead of "engine1 * 1 = diesel engine", etc six times, i can simply do "engine1 + engine2 = diesel engine", etc three times (connecting all three outputs just like i did before with six outputs). any ideas for reducing that even more ?

That's what I meant. 5 locomotive types would only need 2 additional arithmetic combinators.

btw: i also chained one constant combinator to all requester chests and set all requester chests to "Mode of Operation: set requests". by only changing the value in that single constant combinator, i now can reprogram the whole system to fuel trains with one or more other types of fuel, eg when i have too much wood, or when i start working with oil, using solid fuel or rocket fuel, or with some mods even burning alien artifacts. the only problem i noticed when changing the fuel type is on trains that have only one fuel slot or that useup all their fuel slots for long roundtrips since they start refueling with the new type only when the last unit of the old fuel is used up, and that almost always isn't good enough to go back to the depot in time (worst when switching from wood and/or for longer distances)

To automatically cycle out old fuel type you have a low tech and an overly complicated option.
low tech:
Add an active provider chest with filter inserter set to old fuel type next to every locomotive spot in the depot.

overly complicated:
Construct a override logic for the binary decoder so it empties locomotives when you change fuel type.
The potential problem here is inserters fill fuel slots from left to right, but also empty in that order.

[Ragnaman]

...Thank you. Please be more precise what instructions in the OP are unclear...
...I don't know if i can fit the whole OP in the tech description.

Once I have some free time I can playtest and:
- see what is most confusing and write it down.
- try to write a small "how-to" that should fit the tech description (less is more, kind of thing).

[Anson]

just add the unloader for the first position and you can almost keep the original description
"A depot able to service any vanilla train composition of length 4 or lower"

updated the bp string in OP

i just tried having a look at the new blueprint, but after importing the blueprint string to foreman, foreman couldn't load it to a real blueprint, and instead wrote a message to the console:
- Blueprint failed to load
- Unknown virtual signal name: sum_locomotives stack traceback: __foreman__/control.lua:747: in function ....

did you add a new signal "sum_locomotives" to your mod and didn't publish that version yet ?
or which other mod did you use in the blueprint which could have caused this ?


i also found another bug in the old blueprint, concerning the decoder and conditions for the active providers:
the opposite of "<" is not ">" but ">=", specifically: the opposite of "<0" is not ">0" but ">-1"

the problem is probably never visible when checking for engines and the train starts with an engine, thus causing an uneven binarycoded number ending in a set bit (xxxx1). but the problem becomes visible when reversing the check, using the wagon signals and having no wagon in front of the train, causing an even binarycoded number like xxxx100). as far as i could see, all those trailing zeroes cause a result of 0 from the decoder and thus are neither <0 nor >0 ...

that was probably also the problem of those people in the Binary Decoder thread who messed around with the constants (the powers of 2) to fix some cases where results didn't match the expectations and sometimes delivered no or incorrect results. they tried to fix it by adding or subtracting 1 to the powers, but of course that messed up the system and gave bad results for other ranges of binaryencoded numbers.

here is a blueprint for a demo setup with a double 16-bit output. one output is done with <0 and the other with >-1, and thus always one lamp (either for 1 or for 0) will light up. change it back to a simple >0 on those 16 lamps, and you'll see that both lamps will stay dark when one or more trailing lamps should indicate a 0.

counter - blueprint and picture

16-bit-counter with double display (should completely be done with only vanilla components):

Code: Select all

H4sIAAAAAAAA/81bbY/aRhf9K4iPFTzyvNoodaV9y5M0bdImbb9EFTIwm7VqbGRMmhXiv3cAvzDYwB3DzZJP2cV3mHPnnDN37ngnSSdKxkHUGfrLcJzEc3+5
DOOJ+uaT3jz8EgeRv8yeZ8rvfg3TbBFE3V4cTPWP2w/7Tne16uURFBRBdiLYXkSYqWnx+ESNw4lK++NkOgrjIEtSHbjqqTgLs1Ct57l9bj3pLIiz3Qd7s2Su
n0pif/nN73u9Z79PV71JmKrx5re8p6OyNImGI/UUfA2T1F8+hlGm0vW4EBSjKBj/013pcRZxpnO1xSPXM9RDx9vv0YN97pLu3/4yVRM98Gbuz8Nw4nu9cZiO
F2G2/oGs1v96YDwyx3Muhtfl/KUQTOYYiJ4JJPr/ZTSjrvTyaAqMflPlTjKP59EMGP22jPbIgObBHBj8cxnMnUGBWgCD35XB1OFeueyw4F8q0A4tMLvA4F/L
YEEKyB4w9n01a1EgHgBjP1STpgVg4gCDf6soVuAlUIL9vkOwIhZKr4879CpioeT6VJGrCIVS64+KWkWogFrCenrVT9zSE9wLeYJTIuhTwl3uMVnSHLpwZIfm
LnM58UqyQ9ePVmRn0nOdQUl56CqyivLS40zwkvjQxeQVDMYpcd2S/lCzEBX7XeJ4XqkBqGHISgJMCM5LIUBNw93RgasRlGqAOodXiYFpAI5n6R6DShFkwJnD
bR3kZsdwBy4R1NZGbnfYyD3hSlsvuau4SDn1PFs/ud9hotYUtzWVhx0eakFRa2ehll4iLuQlf1bALR3kr1plReFgd21UHK6zgjTMnqYqC8eHM0H/J2q1I23I
SzXWUH84CfMpPobpPBtCAKtg/KQxz9U6HBRRFKDJTKXBZmLdH7q9ZJHNFjZfCcyq3o56X1KlYuO3hO+md7NEn7u0KZ5II/dTNQkX076K9PemegFmSaSainZS
hcynQRT1o2A6a3jQaSJrMbVyRWwWZFsbb5Wi56H/P50F6Zoifvcn/dlirvTAUaLFkKULBcviwEhCwwFnr87fso+cYl8+UEvqVSeZHK10DLQ/WrGqGm32PNxI
ePiYJtNhGOsRtqmC5Yo0Ms47RLgTjxLDFQg5bAsHeeai8OwBg2euidaBAZQoAO9xhGQAZHa64i+jK1NW/gVl9RhE80O6stBQTYK8hUw4CotuMVhEzCPXpqAC
IBQoCO9QEDomQmonFPoyQqmhf5kNiOzpxKoAOvUsgZapB2nIUGh4g0JDsyjfKwYPIqQoCAcoCMXh9dwDb+5d3Gz0AApjAiyMHZTsuSjZM3NCgQogKAg9FITS
JIEHQogjAIEBkJqGRhkIIM4KSpQV9EyAsKIapxpiKCtoVkMUZtI4uxBHAWgWQ5RaOq8EGi/OOYqgpMS0JQYjNU4BTFEAmpsvNUv8k63QvAl1die0uhcilp3Q
T7VIaoXAvRCC29YI3p6JIO/vHT+BtL3kqsAAeI/TAXJQeG9J9E0X9cKvSJDWlBENlLG+7LG8L7ypRXJQEbpOXKO+Ltd+3u/HtuQEs+WEvCZOsNacGEUL1ZoW
H47TAnYxfzVJ5K2TeNc6g+9aCstFEdYDhrDMIoMB2xsSBeA9jnMYAAeWRsKvSQP1SKgG6lUcVAMfz3URcU0ZpK0z+Lp1BhtNHGYkAkVndxg6M49jHHhxx1EA
3mIA3Gt+MksjoZeXQdNZwPbVJlsZvEeUwekksmvyknr6oUmsF+z2bw/bGQlD0dkNgs642erau2Q4euFyeYADDIB7V7d7xuna+YpzeUU0ChUqCrdBFFYSJ1cG
yDsO6OgNz+UJ6WEQkpsMhF3wOCj4XAx85jtFwvJvVhA27rMI2b7D9NB62znRYTqZw2sTtWydw7M6Mm/a7d44ViIxpGbeNAoKshKcvVsg4BN7775IOytBaCac
JYP2jcl6bxGqgfo52s5KEI4AZ+WwfV/yvnUO23cUcM7bDENqZl0sYQ0FnHMOx8AnjlnlSRkgXHCcJYP2rcl6g/F7VSUIncmzcti+OXlWVVLvDYOsBOcOgCBI
TZotBQl7wQun90q/g5VY3nHk18CXfEuhqalm++rHNSmzfauv3rCDyrLeaQXJEufu0cGg7Zanq/ybiOyPwjUlNGSVdv4Ns6fOJFmMItWZhPNZFDx3V69SlS3S
uDN8peLJfwJ4hu4ARAAA

to reset the counter and start counting from 0 again, click the rightmost counter (a beast with two black signals shown, marked in red in the pic) which is right below the decoder (the combinator with two yellow each signals shown). then click three times on the operator (toggling through all states, through <-1 and =-1 back to >-1).
to do the above mentioned test and see how the old blueprint might misbehave, change conditions of the top row from >-1 to >0 and watch the last binary digits not getting lit (currently! working lamps marked with blue)

16-bit-counter.PNG (140.82 KiB) Viewed 8378 times

[Optera]

I might have grabbed the bp while running a development version. I hope that's the last time i have to edit this string.... I start to see why XKnight only posts a single pic of things working for his demo and says figure it out yourself.

Theres reason for my "mistake" in using >0:
When using engines and checking for >-1 it will trigger all unloading inserters constantly while no train is parked at the station in automatic mode.
I don't like my trains parked in manual mode being stripped of all fuel. Feel free to adept my example if that's what you're looking for.

[Anson]

When using engines and checking for >-1 it will trigger all unloading inserters ...

true, that might be a problem
(train in manual mode -> encoded engines = 0 -> looks like there are wagons everywhere to unload).
and since checking for wagons would be similar
(train in manual mode -> encoded wagons = 0 -> looks like there are engines everywhere to fuelup)
there is probably only one clean solution:
only checking for those things (engines or wagons) that are really there, by using sum-engines for fueling and sum_wagons for unloading.

I might have grabbed the bp while running a development version.

looking at what you spoilered in the blueprint, doing two separate tests soon will be no problem any longer, with just two sum-signals and two decoders per depot station, instead of needing dozens (currently for me: 11 additional combinators for 12 engines and 10 wagons) of auxiliary combinators for each depot station :-)

of course, we always have the most simple solution of not using every engine and wagon that is available, and not building "all-in-one" refuelig depots, but restrict ourselves to one or only very few engine types and wagon types and use a single train composition. this also would make sense since loading and unloading stations probably are optimized for some specific train composition anyway.


another question:
after i grew my network to include 3 copper ore loaders and 3 iron ore loaders (all 6 were almost full, filled to at least 10x or 20x the requested amounts), all delivering ore to a single smeltery drop, i noticed that trains went only to two of the stations for pickup (in this case, to copper 1 and to iron 3). I thought there was some round robin so that trains would pick up ore from iron 1/2/3 in turn, and also from copper 1/2/3 in turn ?
I even tried setting requester priorities on the provider stations. by doing that i could force trains to load someplace else, but again only at one copper and one iron station (selected from those with the same highest priority), and not cycling through all those with the same highest priority.
or does round robin only apply to servicing requester stations in turn (for dropoff) ?
I'll try that next, setting up a few more beltless and robotless general smelteries ...

hehe, it would be nice to have a multiplayer map, where everybody takes care only of one outpost/town that is responsible for specific tasks, and let your mod send trains back and forth between those towns ... i had planned something similar a while ago, and just found and started watching factorio towns by mangledpork :-)

[Optera]

The clean solution would be to have two binary decoder. 1: each*loco=loco => red wire 2: each*wagon=each => green wire check red wire for refueling <0 and green wire for unloading <0.

After testing with summed up engine/wagons signals i dropped the idea again.
When using several engines/wagons having to sum up signals in inserters adds some gameplay challenge for players. You only need 5 combinators for 11 engines: loco2 + loco3 = loco1, loco4+loco5=loco1, ...

[ssilk]

The clean solution would be to have two binary decoder.

Or use only one type of train...

After testing with summed up engine/wagons signals i dropped the idea again.... complicated explanation...

It's a good idea and is really nice to see it working. IMHO this is an over-engendered feature. Maybe easier to use, with 0.15 coming with AND/OR/BITSHIFT operators... but even then still over-engendered.

I don't use it, cause the solution to use only one type of train is so incredibly much simpler.

And will point back to the suggestion to implement several LTNs instead, each with it's own type of train. You have good reasons not to do it, but with any feature you are adding to make it even work, my reasons become more and more valid.

Or - in real life it would work like so: there is a sensor, that measures, if the entity needs fuel. If so, the fuel is inserted. If not, then not. THAT would be really simple. But the current solution is in my eyes a feature, that is beyond scope.

[Optera]

The clean solution would be to have two binary decoder.

Or use only one type of train...

After testing with summed up engine/wagons signals i dropped the idea again.... complicated explanation...

It's a good idea and is really nice to see it working. IMHO this is an over-engendered feature. Maybe easier to use, with 0.15 coming with AND/OR/BITSHIFT operators... but even then still over-engendered.

Do you mean over-engineered? I'm taking that as compliment.
I doubt bitshift could be any faster than using binary overflows. You'd need 1 shift per carriage as opposed to a single tick calculating all at once.

And will point back to the suggestion to implement several LTNs instead, each with it's own type of train. You have good reasons not to do it, but with any feature you are adding to make it even work, my reasons become more and more valid.

My design goal still is to create one network handling all logistics.

Or - in real life it would work like so: there is a sensor, that measures, if the entity needs fuel. If so, the fuel is inserted. If not, then not. THAT would be really simple. But the current solution is in my eyes a feature, that is beyond scope.

Or - in game there is nice little mod called Inventory Sensor doing just that.

[ssilk]

Do you mean over-engineered? I'm taking that as compliment.

Oh. Really?

I doubt bitshift could be any faster than using binary overflows. You'd need 1 shift per carriage as opposed to a single tick calculating all at once.

I dunno. We will see...

Or - in game there is nice little mod called Inventory Sensor doing just that.

Hm. This would be a good idea, yes. I fear it's also over-engineered, if you try to put everything into one.

Maybe this task should have different combinators:
- Scan of inventory
- Scan of fuel/vehicle-entity-type
- These two above should have some kind of "scan-range", so that you can build it - hm - 6 tiles away.
- Scan of logstic requests in this network
- Scan of construction requests in this network

That would make nice things possible.

[Optera]

Or - in game there is nice little mod called Inventory Sensor doing just that.

Hm. This would be a good idea, yes. I fear it's also over-engineered, if you try to put everything into one.

Maybe this task should have different combinators:
- Scan of inventory
- Scan of fuel/vehicle-entity-type
- These two above should have some kind of "scan-range", so that you can build it - hm - 6 tiles away.
- Scan of logstic requests in this network
- Scan of construction requests in this network

That would make nice things possible.

Inventory Sensor does only what the name suggests, reading all inventories, including fuel, from entities into circuit network.

Yes reading requests from the logistic network would make Van Neumann Outpost building really simple.

[SHiRKiT]

I'm experiencing my trains delivering small amounts of items instead of bulky requests. Let me explain my setup:

- I have 13 stations that supply (provide a positive amount) of all individual ores.
- I have 4 depot stations (now with the boolean toogle)
- I have 3 stations that requests (negative numbers)
- On these 3 stations I have Minimum Delivery Size to be 80k

I'm experiencing the trains ignoring my minimum size and grabbing any amount that's available.

Screens: http://imgur.com/a/KPXFj

[Optera]

I'm experiencing my trains delivering small amounts of items instead of bulky requests. Let me explain my setup:

- I have 13 stations that supply (provide a positive amount) of all individual ores.
- I have 4 depot stations (now with the boolean toogle)
- I have 3 stations that requests (negative numbers)
- On these 3 stations I have Minimum Delivery Size to be 80k

I'm experiencing the trains ignoring my minimum size and grabbing any amount that's available.

Screens: http://imgur.com/a/KPXFj

From what I see that's the expected behavior with best effort active. Even if you turn best effort off there will always be the following two stages:
1) you just built those requesters and this is the initial filling:
No need to do anything. Once they reach your desired level check for 2).
2) your providers are restocked slower than requesters drained
increase production capacity

[SHiRKiT]

I'm experiencing my trains delivering small amounts of items instead of bulky requests. Let me explain my setup:

- I have 13 stations that supply (provide a positive amount) of all individual ores.
- I have 4 depot stations (now with the boolean toogle)
- I have 3 stations that requests (negative numbers)
- On these 3 stations I have Minimum Delivery Size to be 80k

I'm experiencing the trains ignoring my minimum size and grabbing any amount that's available.

Screens: http://imgur.com/a/KPXFj

From what I see that's the expected behavior with best effort active. Even if you turn best effort off there will always be the following two stages:
1) you just built those requesters and this is the initial filling:
No need to do anything. Once they reach your desired level check for 2).
2) your providers are restocked slower than requesters drained
increase production capacity

Can't I set a minimum delivery size that won't grab below that amount? My 2-6-2 trains are running with 500-1000 ore, which is hardly efficient, since I'm expanding my network and those ores are stocked in form of processed plates in hundreds of thousands. I could swear that the Minimum Delivery Size would do exactly what I wanted, since that's what's written: minimum amount of items to be delivered at a single time, and not a best effort approach. If I disable best effort, would the trains only deliver the minimum amount requested?

[Anson]

1) you just built those requesters and this is the initial filling:
No need to do anything. Once they reach your desired level check for 2).
2) your providers are restocked slower than requesters drained
increase production capacity

in my test setup, i found a similar problem :
- 20 trains available in my stacker depot
- one new provider which is slowly filling up
- 10 requester, 9 of them full and one still needs more ore
result: all 20 trains are going from depot to provider (where 10 trains queue up waiting their turn for pickup) and then to the requester (where also 10 trains queue up waiting their turn for dropoff). each train transports only 1/20 of the ore that is available at the provider.
min delivery size at the requesters is 3500, the first train arrived at the provider when it had only 4k ore, and all trains only transported around 200. when the provider station's chests slowly filled up, the transported amount increased slowly too, but always in an order of around 1/20 of the available ore, eg delivering around 600 each when the provider station has 12k ore. finally when the chests had 80k+ ore, trains would always transport the intended 3500 ... (20*3500=70k)
the problems got even worse since those queues sometimes caused a timeout that canceled the deliveries, resulting in ore getting unloaded at the depot which after a while might have caused the depot to overflow (active providers not being able to get rid of all ore since there is no ore loading station nearby, and only few storage chests or no storage chests at all)

to solve this last problem, i had thought of doing a central storage station and junkyard, that gets all surplus from everywhere, and also some ore deliveries from faraway stations, and then distributes that to the requesters. but i got the old problem how to handle requesters and providers so that they don't send items from provider to requester, put the items in storage, and immediately put them on the next train at the provider to deliver them back to the requester, etc etc etc

a solution would be to build two separate networks (one for delivering ore and junk to the central storage, and one to deliver items to the final requesters), but is that possible at all with the current mod ?
another solution would be to use different trains, eg short LC trains, to transport junk to central storage, and long LLLCCCCCC trains to deliver ore from faraway orefields to central storage, and use medium LCC or LCL or similar for the normal/final deliveries. but that would require an additional signal "minimum train length" besides the currently available signal for "maximum train length". achieving the minimum train length by specifying a minimum delivery size is not possible since those junk trains should deliver small amounts of items/ore, and also because of the above problem that trains don't always obey that minimum delivery size.

an alternative might be to have a signal "train type" that separates provider and requester stations into several user definable groups of stations (effectively creating a number of separate sub-networks), eg "train type = 1" for junk collectors (with max train length = 2 at their provider stations), "train type = 2" for normal trains (with max train length = 4 at all their stations) and "train type = 3" (with max train length = 9) for the large ore transports (specifying a train length probably wouldn't even be necessary with this system). such sub-networks could also be useful to separate double ended trains (for terminus stations) from single headed trains (for roro stations) ...

just for your amusement - screenshots of my stacker depot and the smeltery setup - 6.2MiB

PS: here is a "proof of concept" for my beltless and robotless multi-smeltery (one smeltery for both copper and iron), using 10 drop stations (buffer chests for 20k+ stacks = 1M ore, 500k copper and 500k iron) and 10 pickup stations (buffer chests for 20k+ stacks = 2M plates, 1M copper and 1M iron) on only 11 parallel rails, each pair having 15 electric smelters for a total of 150 smelters, and during a first test got the achievement for 200k+ iron plates per hour :-)

rightclick images and open in new tab to see them fullsize (taken with max zoom)

stacker-depot1.PNG (1.81 MiB) Viewed 8282 times

BigSmeltery.PNG (4.47 MiB) Viewed 8282 times

when expanding my current test setup, I'll try using a single physical network, but with your mod and its stations for planned normal deliveries, and normal trains (either vanilla or maybe smarttrains) for collecting junk from many different stations in a roundtrip, and getting the big ore deliveries to central storage. I'll also test whether i can split my current single large stacker depot into several small depots, eg one each at each loader or unloader station and a few spare trains at a central bigger stacker depot.
we'll see how that works :-)

[SHiRKiT]

All I wanted is a PROPER minimum delivery size. I don't want my trains to deliver any LESS than 80k ore, since it's just not worth the trip.

[Anson]

All I wanted is a PROPER minimum delivery size. I don't want my trains to deliver any LESS than 80k ore, since it's just not worth the trip.

yes, same for me: no use in delivering 20*200 with 20 trains, when minimum size is 3500 and 4k+ are available at the provider station.

Trains not running deliveries
min_delivery_size is set to 1000 for all stations to prevent rains running wild.
Default size can be overridden for every requesting station individually with the virtual signal "minimum delivery size" feed into the lamp.

that is even the opposite problem :-)
we get too many and/or too small deliveries even though we have set that signal to a larger value.

maybe the default could be to do "best effort",
and when i specify explicitly some minimum value, that value should be respected always.

[SHiRKiT]

Now I understand what you meant by the "best effort". I'll check to see if disabling it gets me the desired behavior. Only thing is that the small cargo trains will have it's best effort disabled as well.

[Optera]

You can imagine minimum delivery size and best effort as decider combinators in front of a stop.

Requester:
1 decider
request > Minimum Delivery Size = output everything

Provider:
2 parallel decider (OR logic)
Use Best Effort > 0 (true) = output everything
provided > Minimum Delivery Size = output everything

If you want only large ore trains to ignore best effort leave it true and add a decider with provided > Minimum Delivery Size = output everything between storage and input. If you use the same Minimum Delivery Size as on your ore unloading station you will have emulated best effort = false for this provider. I'm using this setup myself for my Megabase and have yet to notice an ore train below my min delivery size.

yes, same for me: no use in delivering 20*200 with 20 trains, when minimum size is 3500 and 4k+ are available at the provider station.

Let me get this straight. you managed to get trains run 20 time with only 200 items from a provider with over 4k of that item in stock to a requester with a minimum delivery size of 3.5k?
My first guess would be the stop isn't seeing the whole 4k stored. If it does see the whole 4k I'll need the save for debugging.

[SHiRKiT]

If you want only large ore trains to ignore best effort leave it true and add a decider with provided > Minimum Delivery Size = output everything between storage and input. If you use the same Minimum Delivery Size as on your ore unloading station you will have emulated best effort = false for this provider. I'm using this setup myself for my Megabase and have yet to notice an ore train below my min delivery size.

That would certainly work. And I just noticed that the trains outputs a signal that says what it's requesting! I can make omni loading stations! Thanks!

[Optera]

That would certainly work. And I just noticed that the trains outputs a signal that says what it's requesting! I can make omni loading stations! Thanks!

Positive number means load this amount in, negative number means unload this amount.
Note, it's not updating to save update time, so if you have more than 4 items you need a way to clear unloaded items.

Until 0.15 adds inventory reading for trains either I either use my inventory sensor or a train triggered memory cell to calculate inserter filter signals.

requester station blueprint for outpost building

Code: Select all

H4sIAAAAAAAA/9VYXY+jNhT9KxGPFV4BISTRlkr7vlpVbR8qrSrkgRtiLdisMdlJo/z3GvKFwQTwaFp1HmYmw5zr63OOfe8lYYuMxThbROEJqCCCQBmeThTn
EFql4Jike4Hkj8yyC1bK54yGp9cQeY59lN/PdkI4xM2f5YcJQHdjCgxMgb4p0DMFmpJjyo0pNabMGBJjSIvhaoabM+TSUDpTq5h60/QwPD19CcQkAY5ilr8Q
igXjHfDmw6oH9+2YUcFZFr3AHh8I4+HpGiiST5IGLS+jHeGliEqSUpyFJ3Es5IIHwkWFZYqX9T//8QXFmKcM/cApo9a5Dl0KTIW0nEyqwLxOKrRCy2aVKKqR
eJeHyGkCFUeZTkVFtOMsjwiV6HCHsxLOzTL0sh2Z6FfLtf4KTxwSeYM2l+kxIknouXZMeFwRUX9yJWmPZ8v1WUb5ank6oO+owPrrxjjmROxzECQeJn07kfRH
rLm8X3kCHO/bnCPXZgVIyusVrZ9mcX6JNZXaHkODXHrt//QULnNISJUjyORyXBJasAx6Ravh0vmwmpjYSoZPOQDt/bm18I5kQp4aQkvg8pfumsuLfrdFO6rd
tpOzBCK2ix6Mu9NzbCWTsZSUjZ/2UApU4LIkB0AFZ4f6SOqTGyRkdO9TSHdnkr5UzpbnqR83ekn8MdBkwYJ31mvzBr2C2XJt5srlz1QrUJleqRejq1drPQaa
qpbzvmJ1UpklljNXq85i41p5M6XaqKxvVdYDvVQqaOn0QK2UZd2Ivw0o1T5WrUI2xG0pCyFOQRejDjHNHet3dkdg7o71bHcEM92xneeOZaelUS9UX3+Qu6BV
D6Tjp25Paa1wgS4tRbdH1VrF00h4Ub8edac0JTL/Y9PgyDYwdG1CE3i9tBtmXcrzrTUtpnZnI368d29zmjdMj2JPaDrcNP8iH1UlyPAZk5QJXsG0jfu+Vvtx
dTWjh/OmycN5p8FDGRSu5LlvmDjgALwlh270aOg3MZ7a2agNsf6Q+u2OWvP4TT21O3KRae7M4fw9/SWjQpZqReqOV8qz1fCRHbXc9l+3nKdY7uf/0HK9mVVn
q55vBqc2VRV1kvaeKKb3Q9fzw25QzVzmOMtQhvNC2/K67bbipsmwPYI7aMQgE2tUjl+vV2cGNBX7e6Fa3QuVPRJBYhPISO0EVJK/4VHrnGsMrxeDCMhvATgU
mHDZuMTf7lDkOjdw8BScYdmBIVFxDuKB9m7g9VOwrBYU0A+pzwO6ukE3T6EpFtDO9graPgU18vKqEQ1x9sKEZl23z7iy4VvBG8Q/Z7tlx3767vIpVnsv90l3
/anNzVKdEye9l+rbX9ei/X9eS41Uzjnvooaummu1bK6as03iZvkpHms1VedH4/p4b7pAi18//bn4Db5XcvYAvvhdNARZ54/yPFacLqKPQJN/AOF17i8oGgAA