Factorio Forums

Posted: **Mon Nov 05, 2018 9:40 am**

bobingabout wrote: Mon Nov 05, 2018 9:25 am
Light wrote: Fri Nov 02, 2018 8:38 pm Nice to know feedback isn't considered before making major changes. After seeing the latest FFF which swept the issue aside, I've got little hope for the future of the game if they keep to that mindset.
I believe, and this is speculation, that this was mostly just Korverax looking at it funny, and then making changes himself, with minimal consultation with the dev team, let alone considering the community.

in either case, don't worry too much about bob's mods being updated. there will be a 0.17 version, even if I have to work around all these changes.

+1 admiration for doing the 0.17, not that i ever doubted it. If you ever need help with the scripting part don't hesitate to ask ^^ (not a very likely situations i guess).

@speculation: A bit suprised there. I don't know anything about the company structure, but i thought there were at least some...democratic elements(?)...in there. Can kovarex really just make random changes even if most of the others/everyone were against it?

Posted: **Mon Nov 05, 2018 12:42 pm**

eradicator wrote: Mon Nov 05, 2018 9:40 am @speculation: A bit suprised there. I don't know anything about the company structure, but i thought there were at least some...democratic elements(?)...in there. Can kovarex really just make random changes even if most of the others/everyone were against it?

It's Korvarex's game, he's the 1 man in the basement who started it, and he's the CEO man right now.
Also, as I said, speculation, there probably was some consultation.

Posted: **Mon Nov 12, 2018 11:01 pm**

bobingabout wrote: Wed Mar 21, 2018 10:11 pm
danyax wrote:
danyax wrote:Hi Bob,

I wonder what is the practical difference between Pumps MK1-MK4? I did a lot of experiments with fluid pumping and all of them produce exactly the same results regardless of pump type. Even is the simplest test "storage tank - pump - storage tank" all pumps have exactly the same throughoutput.
Bob, any hint on this question?
It's disappointing to think about. they do actually all have different pumping speeds, 200 for the base game version, 300 for MK2, 400 for MK3 and 500 for MK4.
I basically just updated the entities that already existed when they changed the way pumps work back when they added the fluid wagon, I hadn't actually done any tests to know they were all effectively the same.

I guess if the higher tiers are pointless, I could just remove them.

pumping_speed values above 200 doesn't seem to have any effect in the game. ~~This is a bug i would say and would need to be brought up to whomever is responsible prototyping.~~

I did change the base_area to accommodate for the fact that it would need more than 200 units of fluid space at higher speeds. And just to be sure, if i set the pumping speed to 200 (same as vanilla pump) and base_area to 0.5, the pump is slower than the vanilla pump. So base_area does affect the available pumping speed.
Finally, you have a "missing parameter" (more like it's not used normally) in your fluid box definition. "base_level" which defaults to zero. I tested that, first with -1 which reduced the speed of the pump and then i set it to 1 which seemed to make the pump as fast as it should be. According to what i've read, base level is height above sea level and it did affect the pump.
With some further testing, i changed the pumping speed value back to 200 and left base level at 1. The pump is STILL faster than the vanilla pump. So pumping speed itself had no effect, only the base_level.

Setting base_level to 10 (still keeping the rest of the stuff at vanilla values) had no effect on the speed of the pump. base level 1 and base level 10 made no difference.
So i also tested base level 10, pumping speed 2,000 and base_area 10. Just to cover all bases... And BLAMMO! It pumped like a champ! Ten times faster than the vanilla pump for sure! (no, i am not measuring with a timer, by eye only)

So let's work backwards from that... I will start by reducing the base_level back to 1. And the pump got slower. Now, how base_level affects the speed exactly i don't really know. But at this point i do know that pumping_speed does have an effect. And so does base_level. Even the vanilla pump benefits from an increased base_level value. And someone did measure the vanilla pump speed using some in game timer setup and they measured a speed of 138 units per tick. (viewtopic.php?t=46030)

Now, let's test base_area, setting it back to 1 while keeping base_level at 10 and pumping speed at 2,000. And the results are in... The pump is just as fast as it was with pumping speed 200, base level 1 and base area 1.
And so, i have conclusively determined that ALL THREE values need to be raised for the pumps to actually be faster (apart from vanilla base level on the vanilla pump which might just explain why it's 138 units/tick rather than 200)

With this newfound knowledge i will take the easy way out. I will raise base area and base level on each pump tier to match their tier number.
And finally, i will check pipes. Because i am pretty sure pipes also need to have their base area increased to accommodate the increased pumping speed.

DO NOTE, pumps with a base level above 1 will NOT auto level with tanks. They will automatically drain into any entity with space and a lower base level.

... Did i say i hate fluid mechanics in this game? No? Well i have now!

So, on to pipes... I raised the base area of one pipe to 3 (300 units) and used mk 2 pumps for testing, tank->pump->pipe->pump->tank. And in the other setup i used a base area 1 pipe for comparison.
And indeed, you also need to raise the pipe base_area to allow for the now faster pump to push that liquid faster. The pipe with base area 3 has 190 units of liquid in it, the base area 1 pipe has 100 units of liquid in it while transferring.

And i also tested tank->pipe->tank and to my surprise, the bigger pipe won!
When the pipe with base_area 1 had moved 30k units of fluid, the pipe with base_area 3 had moved 35k units.
This doesn't hold true for more pipes between tanks though. With just ten pipes, the auto equalization was clearly faster with the base_area 1 pipes. I am sure this is down to just how fast the pipes themselves will find an equalization between themselves. Less units means the effective transfer to the tank is faster.

So finally, lets compete using pumps and many pipes, 100 pipes for good measure. And yeap, as expected. The smaller pipe is about a billion times faster than the bigger pipe. What we can conclude from this is that, if you want throughput over short distances (one to two pipe segments between pumps) you should use a bigger pipe. Whereas if you intend to have long distance connections with pipes and no pumps you should use a smaller pipe.
In fact, pipes are just glorified storage tanks anyways.

So if anything, you could make a "fat" pipe for whenever someone needs the throughput between pumps. "Use fat pipes when you have no more than 2 pipe segments between pumps."

Finally, base area 3 for pipes (with a 300 speed pump) is not enough really to make full use of the pumps capacity. So i raised all pipes to base area 10 (twice the size of the mk4 pump speed) and that's surely going to be enough. Either way, i am done messing with the mod.

...

Anyways, i hope this helps.

Posted: **Tue Nov 13, 2018 8:50 am**

Given just how awesome the base game pump is, I'm thinking about reducing the base game pump to a quater speed, then leveling up so the top level is base game speed. So their new speeds would be 50, 100, 150 and 200.
Depending on application, 50 should be good for most applications. also having pumps of different speeds slower than the max viable speed of 200 would mean you can more easily make equalised fluid splitters.

The reason why my higher tier pumps exist in the first place is from before 0.15, before fluid wagons were a thing, when the pumping speed of a pump was slow, you needed the higher tier pumps.
Then when we updated to 0.15, the pumping speed went from about 10, to 200. My natural response was just to scale up without testing (Because there was a lot of fixing required just to make the mods work)
And since it worked (even though upgrades were pointless) I kind of forgot to look back at it again. The hard part is remembering to do it.

Posted: **Tue Nov 13, 2018 4:55 pm**

Well, fluid mechanics are going to change again so perhaps one should wait with any massive changes.

Also, don't forget that some machines literally gobble up and puke fluids. Especially when you use them en masse. With the current fluid dynamics, it's not possible to avoid 2 tile piping (underground pipes) and merging and splitting pipes is not as simple as with belts.

I considered the possibility of reducing pump speeds instead of raising them but as it is now, belts and items are far more balanced than pipes are. Belts can connect to any side of a machine or chest whereas pipes can only use dedicated ports. For example, i would really really love to have a fluid storage tank with 8 ports on it. It would simplify balancing designs a lot.
And fluid storages (useful ones) are ALWAYS 3x3 and larger. Whereas useful chest storages come in 1x1, 3x3 and 6x6 sizes. And there's a mod that can make any size chest storage for when you need that. There are no mods for making useful fluid storages. While a pipe is a storage, it's far too small in volume to be of any use. A chest can hold several hundred runs of machine recipes but a single pipe can barely hold one. The upswing to that is that pipes transfer full stacks of fluid in about one tick when pumps are involved.

So if you reduce pumping speed, we would also need to reduce the amount of fluid used and produced in every single recipe for the machines to not completely bottleneck because of fluid flow. At which point, barrels once again become viable means of fluid transport...

I would say, reduce the vanilla pumping speed to 100, Mk2 at 150 speed, Mk3 at 300 and Mk4 at 500. With that there's more progression without completely nerfing the use of pumps. And do change half your pipes into fat ones that have larger capacity at the expense of "pressure".

The only reason i found out that pumps didn't actually help when upgraded was because i was already overloading a machines single port at 12,000 units/s using beacons and speed modules. I put a Mk2 pump on it and nothing changed so i thought it was due to piping or consumers not keeping up.
And i am only using Speed 4 modules at the moment. Imagine how silly it will get later on? And yes, it's also consuming 18 express belts of items at full speed.

Posted: **Wed Nov 14, 2018 3:43 am**

Regardless of pump speeds or even assembly machines/refineries creating fluids, the pipes are always the bottleneck. Their "volume" is so small compared to a lot of production and demand needs that it seems I am working with straws in some production cases. This is why my main refineries are purely barrels. I use Bob's pumps at each refinery/chemical plant inlet and outlet for barreling, and let the bots move the barrels to each location. This works surprisingly well. Just ram the fluids in and pull them out.

Barrel->Pump->(no pipe)Refinery->(no pipe)Pump->barrel

Of course, I use some combinator magic to control the balance of deliveries of barrels of crude and water to them as well as balance the pull of barrels from the other side. It is a flawless dance of over 5,000 bots managing a superior barreling process.

Posted: **Wed Nov 21, 2018 6:53 pm**

Hi Bob, I just started my first game with your mods and I finally why they are so famous.

But there is one thing bugging me now. The artillery projectiles in Bob's Warfare 0.16.7 don't reveal map like the vanilla one. This is sad when you cannot see the aliens far away die in pain. Surprised that no one has mentioned about this.

Anyway, I've compared your files with the base ones, and come to a fix for this:

In projectile.lua, change their projectile type from "projectile" to "artillery-projectile".
In ammo.lua, change the action_delivery type of their shells from "projectile" to "artillery".

Nothing has broken and I can now see the aliens fall apart.

(It is now my only entertainment so it needs to be perfect

)

Posted: **Thu Nov 22, 2018 8:56 am**

Mooncat wrote: Wed Nov 21, 2018 6:53 pm The artillery projectiles in Bob's Warfare 0.16.7 don't reveal map like the vanilla one.

I understand what you're saying. I can't remember why I didn't do it, probably because of issues that were later fixed.

Posted: **Sun Nov 25, 2018 1:03 am**

bobingabout wrote: Tue Nov 13, 2018 8:50 am Given just how awesome the base game pump is, I'm thinking about reducing the base game pump to a quater speed, then leveling up so the top level is base game speed. So their new speeds would be 50, 100, 150 and 200.
Depending on application, 50 should be good for most applications. also having pumps of different speeds slower than the max viable speed of 200 would mean you can more easily make equalised fluid splitters.

The reason why my higher tier pumps exist in the first place is from before 0.15, before fluid wagons were a thing, when the pumping speed of a pump was slow, you needed the higher tier pumps.
Then when we updated to 0.15, the pumping speed went from about 10, to 200. My natural response was just to scale up without testing (Because there was a lot of fixing required just to make the mods work)
And since it worked (even though upgrades were pointless) I kind of forgot to look back at it again. The hard part is remembering to do it.

Having slower pumps to start with sounds great Bob. I like the idea of splitting with different pumps. What I do not know are the rate from which producers and consumers use fluids. For example, a chemical plant produces lubricant. At what rate is the amount produced "pumped" out into the pipes?)

I wonder how their new fluid mechanics are going as these are idea to go along with that.

Posted: **Sun Nov 25, 2018 4:38 am**

btw i still have my game folders from v0.14 and have been doing this every time i find a cool set of modpacks to play, especially my first proper session of modded games, which was an AngelBobs (after seeing arumba play it on youtube)

(another updated version of it became AngelBobYuoki)

usually you can compress the folder until you need to play it again to save space, but theres a savegame/mod file manager (called MMF) which i still have to try, but yes, as a general rule for all things ,if you have the space, and if you like something the way it is and want it to persist, make a backup.

(similarly, if you ever find a web page browsing and want to take a snapshot, save it as .mhtml, - just test it offline sometime to make sure the save worked properly) much better than only just bookmarking the webpage which might have changed or been lost etc.

Posted: **Sun Nov 25, 2018 2:56 pm**

RocketManChronicles wrote: Sun Nov 25, 2018 1:03 am Having slower pumps to start with sounds great Bob. I like the idea of splitting with different pumps. What I do not know are the rate from which producers and consumers use fluids. For example, a chemical plant produces lubricant. At what rate is the amount produced "pumped" out into the pipes?)

I wonder how their new fluid mechanics are going as these are idea to go along with that.

The rate of producers and consumers are all between 1 fluid/s to 60,000 fluid/s depending on a few factors, mainly if you have researched module beacons or not.
Take the salination plant recipe for example. It takes (from memory) 1000 water and converts it to 1000 saline water. I don't recall how many seconds that base recipe takes but with a few speed modules you can easily run into a pipe bottleneck if you have so much as a single underground pipe section somewhere.

There is no "speed modifier" for pipes currently. They don't burst from overpressure and there's no sizes because bigger sizes means they move liquids SLOWER without pumps to keep them topped up always. (fluids don't work that way but the game isn't a fluid simulator)
And fluids don't have viscosity.

Hence, changing pumping speeds only affect those that already need insane amounts of fluid movement in single pipes. Reducing the speeds at the tier where you have the capability of maxing out a single machine means you are nerfing speed modules, not pumps.
The only argument for it is train loading. Because fluid trains load kinda fast compared to item trains. But then we can do some math on the volume of fluid wagons.

Let's assume a tile is 1x1 meters. A fluid wagon is a cylinder of 2x2x6 meters so 18.85 m³. Or 18,850 liters.
If you want to load a fluid train at the same rate as a 40 slot wagon of say coal (200 items/stack) for a total of 8,000 items you'd need to limit the fluid pump down to 120*12=1440 fluid per second because that's the theoretical limit of 12 belts feeding a single item wagon.
But fluid recipes are not item recipes. Most fluid recipes take and produce in the hundreds, not singles or tens.
So since almost all fluid machines have such heavy recipes, you need pumps that move 100 times as much fluid as four belts would move items. Why four belts? Because fluid wagons only have 3 ports for fluids whereas item wagons have 12 for items.

So that leaves us with a max theoretical speed of 120*4*100=480,000 fluid/s. That is, four ultimate belts can move 480 items/s to and from machines (with certain inserter mods such as loaders) and fluid recipes are generally 100 units so fluid flow is 480,000 to keep up.
And that is before you consider that single machines can't input more than 2 pipes and sometimes only one. In the cases where there's more inputs/outputs the recipes produce different fluids for each port but in the end you still need the sixty hundred units of fluid per tick per port with a fully sped up fluid machine.

...

Yes, i am blabbing. Basically, pumps are not comparable to belts and items and never will be. Hence, pumps need "weird" speeds. That until all fluid based recipes stop using hundreds of liters of fluid to produce one item.

Or one can think of it another way. It's much much faster to move several tonnes of liquid cargo in real life than it is to move bulk cargo.

EDIT:

RocketManChronicles wrote: Sun Nov 25, 2018 1:03 am For example, a chemical plant produces lubricant. At what rate is the amount produced "pumped" out into the pipes?

machine output ports tend to have a higher "height above sea level" than other machines. As such, they will always drain immediately into any fluid receiver with a height above sea level less than that.

Code: Select all

Machine output -----------
                               pipe
                                     ----------------- machine input

Imagine a waterfall, fluids will naturally drain from machine output to machine input (which have height above sea level in the negatives) and the hurdle in the way is the pipes. All pipes are on the same level and they only move as much fluid as they have available in them divided by some kind of formula in the game source code. At some point there's also a limit to how much fluid can move even though the pipes are immensely large.

Posted: **Mon Nov 26, 2018 9:10 am**

Yeah, pipes basically work on fluid levels, you can specify the base height (height of the floor) of the pipes. they just flow from one pipe to another on level until everything is the same level, so when a base height is higher up, it flows out of that pipe.

A pump on the other hand will take anything that goes into the input and put it on the output until the output is full, allowing the fluid level to be higher on the output than the input, which lets the fluid flow faster and further.

It's pretty much just that simple.

Posted: **Mon Nov 26, 2018 9:54 am**

RocketManChronicles wrote: Sun Nov 25, 2018 1:03 am Having slower pumps to start with sounds great Bob. I like the idea of splitting with different pumps. What I do not know are the rate from which producers and consumers use fluids. For example, a chemical plant produces lubricant. At what rate is the amount produced "pumped" out into the pipes?)

I wonder how their new fluid mechanics are going as these are idea to go along with that.

Chemical plants have fluid boxes just like pumps and pipes. If the input fluid boxes are full enough the plant takes the amount required for the recipe out in an instant. At the end of the cycle it dumps all the produced liquids into the output fluid boxes again in an instant. Everything else is then generic fluid mechanics.

Visualizing the fluid boxes with how the fluid system was described by the devs you get: The input fluid boxes are below ground so they actively drain everything from a connected pipe or pump. That way they can become full even if the connected pipe is basically empty. The output fluid boxes are raised so everything actively drains from them. So even if the connected pipe is 99% full the fluid box is still at a higher level and tops it up to 100%.

Posted: **Mon Nov 26, 2018 11:29 am**

some fluid boxes have a height of 2 too, to let things flow in/out in a special way.

EG
Boilers and steam engines both have a height of 2, but a base level of -1 or 1, meaning only have the boiler's output is "Forced" out, and will stay at 45% if the pipe next to it is 90% full. Likewise the steam engine will fill only to 75% if the pipe leading to it is 50% full. this means that when you have a chain of steam engines, the first has to fill to 50% before the next one starts to fill.

Posted: **Mon Nov 26, 2018 12:43 pm**

I think that is a performance improvement to keep boiler chains with not enough water and to many engines in a row from blinking on and off.

Posted: **Wed Jan 02, 2019 6:07 pm**

Bob, with the latest FFF considering Science Packs, I am curious of you next move. I am sure you are busy trying to reel in all of the changes coming to 0.17 so far, and I can only feel for you with the new Sciences.

In particular, they are renaming the green one to Logistics, which is your current pink science. Honestly, I think their green science should be named Transport, as it unlocks all of the transportation in the game: car, tank, railroad, bots, etc. Anyway, I am curious if you plan to follow in their pursuit of having larger separate branches of the higher tiered science packs (technologies without both, but one or the other)? You already have the Logistics nicely spread into their own branch of science, which does what it intends to.

Posted: **Mon Jan 07, 2019 9:13 am**

RocketManChronicles wrote: Wed Jan 02, 2019 6:07 pm I am sure you are busy trying to reel in all of the changes coming to 0.17 so far.

I'm not sure what's worse, not having source access and having to do it all on release day, or having source access, getting the mods to work, and then having them broken again within a week because of some new change, like science pack rename.
Yeah, all on release day is probably worse. They're in a "working state" right now, but there's still so much that needs to be updated before I can release them for 0.17.

RocketManChronicles wrote: Wed Jan 02, 2019 6:07 pm Bob, with the latest FFF considering Science Packs, I am curious of you next move, and I can only feel for you with the new Sciences.

In particular, they are renaming the green one to Logistics, which is your current pink science. Honestly, I think their green science should be named Transport, as it unlocks all of the transportation in the game: car, tank, railroad, bots, etc. Anyway, I am curious if you plan to follow in their pursuit of having larger separate branches of the higher tiered science packs (technologies without both, but one or the other)? You already have the Logistics nicely spread into their own branch of science, which does what it intends to.

The actual changes to recipes and the like were done months ago, and I have already changed to a whole new set of recipes, twice. (remember I said they keep changing things after I fix them? yeah, one of those changes science pack recipes less than a week after I changed to the new ones.) The rename was more a pain in the backside. I decided to just change logistic-science-pack to logistic-science-pack-2 internally, and name it "Advanced Logistic science pack". It's something I need to revisit, such as renaming the early game logistic science pack to revert back to just Logistic science pack, but, we'll see. Transport science pack does seem appropriate.

Posted: **Mon Jan 07, 2019 4:56 pm**

bobingabout wrote: Mon Jan 07, 2019 9:13 am
RocketManChronicles wrote: Wed Jan 02, 2019 6:07 pm I am sure you are busy trying to reel in all of the changes coming to 0.17 so far.
I'm not sure what's worse, not having source access and having to do it all on release day, or having source access, getting the mods to work, and then having them broken again within a week because of some new change, like science pack rename.
Yeah, all on release day is probably worse. They're in a "working state" right now, but there's still so much that needs to be updated before I can release them for 0.17.

Hey, take your time. I am sure a lot of us are eager to play Bob's Mods in 0.17, but if we have to wait extra time for things to work correctly, by all means do so.

bobingabout wrote: Mon Jan 07, 2019 9:13 am
RocketManChronicles wrote: Wed Jan 02, 2019 6:07 pm Bob, with the latest FFF considering Science Packs, I am curious of you next move, and I can only feel for you with the new Sciences.

In particular, they are renaming the green one to Logistics, which is your current pink science. Honestly, I think their green science should be named Transport, as it unlocks all of the transportation in the game: car, tank, railroad, bots, etc. Anyway, I am curious if you plan to follow in their pursuit of having larger separate branches of the higher tiered science packs (technologies without both, but one or the other)? You already have the Logistics nicely spread into their own branch of science, which does what it intends to.
The actual changes to recipes and the like were done months ago, and I have already changed to a whole new set of recipes, twice. (remember I said they keep changing things after I fix them? yeah, one of those changes science pack recipes less than a week after I changed to the new ones.) The rename was more a pain in the backside. I decided to just change logistic-science-pack to logistic-science-pack-2 internally, and name it "Advanced Logistic science pack". It's something I need to revisit, such as renaming the early game logistic science pack to revert back to just Logistic science pack, but, we'll see. Transport science pack does seem appropriate.

I do remember, I did not realize they were looking at this that long ago, definitely puts a perspective on their thought process through it all. I can give them more credit for being well thought out then. With that said, their renaming gave me ideas about the science paths. One such was the Transport name, another was their use of "Chemical," in which I immediately thought of all of your chemicals and where they were researched. If I remember correctly, they were mostly researchable with the blue science pack already, and so most of your sciences fall right into that category.

I do like that the science branch is a heavy resource sink, as it allows continuous use of many resources from the early to mid-game while most construction is using late game resources. I am assuming you have been balancing the resource usage with all of your recipe work?

Posted: **Mon Jan 07, 2019 5:04 pm**

RocketManChronicles wrote: Mon Jan 07, 2019 4:56 pm I am assuming you have been balancing the resource usage with all of your recipe work?

nope. I mostly just did what felt right, though it did occur to me, especially with this latest news about science packs that I do need to run the numbers through some sort of calculator, as there may be some tweaks required.

Posted: **Mon Jan 07, 2019 9:13 pm**

It may be that I'm blind, and you did already address this, but I didn't find a post from you about it when I went looking.

With the removal of assembler ingredient limits in vanilla 0.17, will your mods follow suit, or will you be readding the limits? Not having to do hand assembly of anything as you're bootstrapping into Basic Electronic Circuits would be really, really nice.

Factorio Forums

Feedback

Re: Feedback

Re: Feedback

Re: Feedback

Re: Feedback

Re: Feedback

Re: Feedback

Re: Feedback

Re: Feedback

Re: Feedback

Re: Feedback

Re: Feedback

Re: Feedback

Re: Feedback

Re: Feedback

Re: Feedback

Re: Feedback

Re: Feedback

Re: Feedback

Re: Feedback

Re: Feedback