This order also makes more sense because the Character tab is there from the start but Logistics is only added later. Which means the Character tab changes position, which would likely harm usability much more than a different-than-preferred order could.


Yeah, the progression aspect, combined ...

The reason for that is to keep consistency with keybindings. It's really unintuitive when the second tab is mapped to F3, and F2 does nothing(before researching logistics.).

Keybindings? Nice! Was not aware of them. Makes navigation easier :D
Did not see this in the changelogs, but was kinda ...

I know the character GUI was revised in 18.13, but I'm just checking it out now on 18.14 and something seemed backwards. I recall the initial design being shown in one FFF, and feedback suggested that the less frequently used Character tab be on the far right. This feedback appeared to have been ...

Koub wrote: Tue Mar 10, 2020 4:17 pm 2020-03-10 17_16_09-Clipboard.jpg

...this was actually a game bug, so it may be wise to back down a tad on the hair-trigger to point the blame elsewhere in the future, especially where there was nothing in the changelog that would normally be attributed to causing that new issue with a given mod.

I thought the zoomed in map view was intentionally 'fuzzy' as you are supposed to be looking at remote data from the radar.

This report: https://forums.factorio.com/viewtopic.php?f=30&t=78550 which hasn't had the fix released yet.


I was able to replicate again in 18.8. Attached are two saves. The Creative Mod button (upper left) is functional in save -1, but non-functional in save -2. If we can nail down what ...

This report: https://forums.factorio.com/viewtopic.php?f=30&t=78550 which hasn't had the fix released yet.


I was able to replicate again in 18.8. Attached are two saves. The Creative Mod button (upper left) is functional in save -1, but non-functional in save -2. If we can nail down what ...

I think the only 'big' graphical thing left in need of optimization is when zooming out map view on larger bases - it noticeably slows the game even on the fastest of systems.

Which links to this article where rseding mentioned that it “would be a lot of hassle” for pipes:
https://forums.factorio.com/viewtopic.php?p=227463#p227463


Indeed it was 'a lot of hassle' back then, but now we have pump flow tracked by the base game. Anywhere that fluid flow is desired to be ...

Circuit networks can read lots of stuff, but there are a few missing items that folks have repeatedly requested. I think the holdup has been with figuring out how to implement, so here are my suggestions to improve the signal-reading experience:

Fluid flow:
- There used to be no easy way to do this ...

Bilka wrote: Thu Jan 30, 2020 2:47 pm Okay, done for the next version.

Thank you! While you were testing that, did you notice the odd ‘toggle’ behavior while loading a wagon?

I tested this based on a blueprint of a pump-bus nuclear reactor design from 0.16 (which used to do the full 12k water/s). The sum of the steam output after reaching equilibrium is around 6.8k per second going by the sum of the steam consumption from the turbines.


I stumbled across this thread ...

So, this may not be a bug
...
I should be getting 720k water/minute, but production stats only shows 648k.


This appears to have actually been a bug, though I'm currently trying to convince the devs of this .

The issue relates to the fluid system change, where the pump fluidbox size no longer ...

@BlueTemplar:
I'd need to download 0.16 again and invest the time into dissection, but my naive guess would be moving fluid simulation out of entity logic into its own system so it can run on a parallel thread. As it stands right now, all entities that have fluidboxes run their logic before fluid ...

@malventano: Reducing the rate like that can severely impede the fluid wagon loading time, since pump-to-wagon transfer is not based on fluid mechanics, but still uses the pumping rate number.


I've already tested it. Empty rate is 100/tick / 6000/s with pumping_speed = 100. Wagon fill rate is ...

If the fluidbox were enlarged, that would be making the pumps even more overpowered. The only viable "fix" would be to partially reduce their listed flow rate now, but I'm not sure how badly that would interefere with the fluid wagon loading logic.

If the desire was to reduce the power of the ...

Your example is going out of its way to show >6,000/s in a configuration that the player will never employ, while the real example (even provided by the devs when the pump was changed to a 1x2), was tank>pump>wagon and wagon>pump>tank. Those configurations only see 6,000/s, where they used to see 12 ...

...

I see, your model was based on per-tick changes, accounting for momentum, etc, while my practical experiments were using continuous flow (or at least flow over the course of a few ticks, once the momentum was established). If I'm reading that correctly, it looks like you have provided ...

The desired rated 12000/s fluid flow is achieved with the following settings:
fluid_box =
{
base_area = 1,
height = 4 ,

(height doubled from 2 to 4).

Result:
https://i.imgur.com/IS9RGKs.png

I have also confirmed that steady-state flow through a single pump (with the above change) can once ...

Two notes:
The statement that a fluidbox can only change by half per tick is incorrect.

The behavior I have observed while investigating fluid flow does not match up with what your fluid sim predicts. If the game was performing as many fractional calculations as your sim suggests, not only ...