Friday Facts #318 - New Tooltips

[mrvn]

Will the tooltip for solar cells also show "Power output" and "Available power"?

It would be nice to also show this in the electrical info window when you click on a power pole. I never know how much of my solar is actually used unless it is 100% and steam power kicks in too.

[EstebanLB]

Personal Roboport tooltip is missing Logistic area

[posila]

Personal Roboport tooltip is missing Logistic area

Personal roboport doesn't have logistic area.

[EstebanLB]

Personal Roboport tooltip is missing Logistic area

Personal roboport doesn't have logistic area.

Right, my bad. I haven't played lategame in a long time

[Masterpintsman]

Just now my idea to let bots do more than one job:

^ What's in this post, please ^

[KunibertSegensreich]

Has anyone made the suggestion of adding a random recharge limit? It could reduce the cluttering around the player when bots run out of juice, because the all recharge at different levels.

Code: Select all

if ( rechargelimit > energy+randomrechargeofs ) {
  recharge();
  randomrechargeofs = random(whatever);
}

[eradicator]

but in game you will notice that they are slightly transparent and the also have a blurring effect

Please, please if that's anything like MSWindows™ Aero Glass add a "not transparent" setting somewhere. It has horrible readability for my shitty eyes.

Other than that the tooltips look really nice! I hope moddability of tooltips is also considered.

We've been using transparency with blurry background in the technology GUI tooltips for a while now. If your eyes have no problem in the tech tree, they won't have a problem anywhere else.

Thanks for the answer. The transparency in the tech screen isn't as bad as on windows. Maybe because white text in the background is less visibile due to the general grey scheme of the interface. Personally i just prefer less "fancy" interfaces, but i guess that's a strange thing to want from a game ;).

Is the transparency part of the gui styles definitions and thus moddable btw? That would please everyone.

[mrvn]

Has anyone made the suggestion of adding a random recharge limit? It could reduce the cluttering around the player when bots run out of juice, because the all recharge at different levels.

Code: Select all

if ( rechargelimit > energy+randomrechargeofs ) {
  recharge();
  randomrechargeofs = random(whatever);
}

I don't see how that would help. It would make things worse since bots now recharge earlier and waiting bots waste their remaining energy bobbing around instead of doing work.

The cluttering comes from not being able to recharge fast enough, which usually means not generating enough energy early/mid game.

[NeilN]

If you're going to rework tooltips maybe look at adding one showing what the belt under the mouse pointer is carrying? If you use mods that add a lot of entities, visually distinguishing between three slightly differently shaded white squares is challenging.

[Ironhair]

So, for now they just batch build tiles.

Is it possible to enable it for walls/gates?

[eradicator]

If you're going to rework tooltips maybe look at adding one showing what the belt under the mouse pointer is carrying? If you use mods that add a lot of entities, visually distinguishing between three slightly differently shaded white squares is challenging.

+1 show that in tooltip. Also showing the current transfer speed next to the maximum speed would be really nice.

[TheRealBecks]

Storage tanks, pipes and a few other entities still show the amounts. For boilers and steam engines it's not very useful(or arguably not useful at all) and it was competing with other more relevant information.

It would be nice to get the rate of flow on pipes. Because actually I have no idea how much fluid flows in the pipe per second and what is possible with that pipe. Also in the wiki is that general information missing. And when installing mods with additional pipes it's still not clear if any type of that pipes can have a higher rate of flow.

[Byproduct]

Thanks for a great blog yet again!

Two things come to mind with these topics:

1) Regarding the tooltips: energy is in MW and capacity (e.g. accumulators) is in MJ, and I have no context as to how these relate. What about a somehow comparable number, e.g. MWh - or perhaps megawatt-minutes or something like that?

2) The bots: it's always bothered me how they clear areas instantly, like it takes one bot and 0.001 seconds to destroy an entire tree for example. (Not sure if this is still the case as it's been a while since I last played with bots, but anyway.) I'd love it if I'd still use the bots exactly as before, but it'd take several bots and a few seconds to actually destroy a large thing like a tree. It'd be a more "realistic" feeling and more resources/energy required towards it. Also flying speed, energy requirement or the number of required bots could change depending on the item. Could be either weight in kg or just some classification like a tiny/medium/large/huge item.

[BlueTemplar]

1) Regarding the tooltips: energy is in MW and capacity (e.g. accumulators) is in MJ, and I have no context as to how these relate. What about a somehow comparable number, e.g. MWh - or perhaps megawatt-minutes or something like that?

Energy is in Joules.
Power is in Watts. 1 Watt = 1 Joule / 1 second
(IRL condensers have a "capacitance" - which is not the exact same thing as stored energy - measured in Farads, but that's too detailed for Factorio to go in.)

(If this isn't already in the starting game tips, it should be.)

[Byproduct]

Power is in Watts. 1 Watt = 1 Joule / 1 second

Welp, should've educated myself on basic stuff like that before commenting. How embarrassing. But at least I know now, thanks for spelling that out for me.

[Syriusz]

Hmm bathing all entities would be great, but if entity size makes it more difficult, maybe it could be enough to just give them "item size" so construction bot with 5 slots could carry 5 belts but only 2 assemblers or 1 nuclear plant for example? And maybe 10 tiles?
Also, for me it does not have to be perfect, so solution might be a little weird looking as long as they work. Especially solution 3 would be great and probably even decrease CPU usage since next items would have fewer tasks than current case.

1. Bot get task for entity. He looks in chunk, maybe nearby chunks for same blueprints and if there are more then he gets more items and build them. If not, he
builds just this one. And he search only if chest that he takes items from have enough items. Maybe use tech to upgrade searching range for bots? Of course it would look funny if bot would not build entity next to first one (near border of chunk) when it looks like it should, but if his searching size is more than one chunk it should not be visible.
2. There are E number of same entitles to build and B number of bots. Bot grabs up to E/B number of items, goes to his destination, drops entity and THEN searches for closest entity to build. If it fails to do this (other bots did it already or they are closer) then he drops items he took to storage and gets back to roboport. Of course it would mean that storage can get full of junk so it should be better for advanced users, so maybe it could be steered by signal to roboport? No special signal- grab only 1 entity, otherwise grab up to signal value.
3. Same as 2 but instead of bot taking more than 1 item, bot "teleport" more when he finds next target. Of course up to his cargo size, so it is like he would know in advance if he needs them or not. But without the need to calculate it. The only downside to that is that assemblers (and networks if used) would not know to produce more when bots goes to chest, but with small delay.

[Twinsen]

It would be nice to get the rate of flow on pipes.

We have some internal flow rate, because of the un-intuitive way that pipes work, showing the flow will make it even more confusing. We are experimenting with a new fluid algorithm that will solve this issue, but there seem to be new problems. We will keep you updated if something comes up.

[Honktown]

It would be nice to get the rate of flow on pipes.

We have some internal flow rate, because of the un-intuitive way that pipes work, showing the flow will make it even more confusing. We are experimenting with a new fluid algorithm that will solve this issue, but there seem to be new problems. We will keep you updated if something comes up.

I am not a developer (should it be IANAD?) but I felt like observing/asking.

Currently, pipes act as singular entities. each one can average it's value with connecting pipes, which leads to the sadness of pipes having terrible fall-off at distance (the distant pipe can only get 1/2 of 1/2 of 1/2... per update). Pipes check their fluid exchange at a rate of 120 times per second (by assuming their value is related to their 1200 units/s maximum). Pumps act as a virtual source with strength 100 at their output, and virtual sink of 0 at their input, with the caveat that any fluid they can't output is stored in the internal buffer first, and when that is maxed out, then the fluid must stay at the input, overriding the sink-effect.

In practicality, pipes should be based more on accumulator/power line logic. Each pipe is effectively meaningless, it just adds to the overall capacity. The pipe forms a net/graph, and when something is attached as a drain, it pulls from the capacity of the net. What you'd see if you hovered over a pipe is fluid present / number of pipes (a pipe net of 10 pipes that has 500 fluid present would show 50 if you hovered over any pipe). One would need to check drain elements before source elements, so each fluid pass, fluid is taken from the pipe before a filling pass. If that order wasn't kept, then there'd be a weird pipe limit: even if a drain could pull 100 fluid, and a source could provide 100 fluid, a full pipe would try and be filled, which doesn't work, then it would be drained by 100. Each update would show it filling from capacity-100 to maximum, then draining back to maximum - 100, an average of 100 away from the actual maximum of the pipe - which doesn't make sense if you have a full pipe, and a source and sink that are matched.

Edit: going further, to even drain amounts, the fluid permitted to be drained should be capacity / number of drains, then each drain checked. If it can't be filled, it is removed from the number of drains and the fluid drain check goes down the list of connected drains. Unfortunately, the "perfect" way of doing this is dangerous: say there were three drains, and the pipe had 100 fluid. The first drain could take 33. If the other two didn't want to take fluid however, then a single-pass would result in 33 drained, even though there's 67 left in the pipe and a drain that's not being filled. The drain check would have to keep circling around, only permitting as much fluid to be drained as if all previous drains that wanted fluid hadn't been filled. For a pipe with 100 drains, this could result in massive, massive penalties, as you may have to recheck the net many times to get "perfect" behavior. Probably still not as bad as current pipes in most cases, but it's something like an N! order of operations vs N that pipes are now.

[mrvn]

It would be nice to get the rate of flow on pipes.

We have some internal flow rate, because of the un-intuitive way that pipes work, showing the flow will make it even more confusing. We are experimenting with a new fluid algorithm that will solve this issue, but there seem to be new problems. We will keep you updated if something comes up.

I am not a developer (should it be IANAD?) but I felt like observing/asking.

Currently, pipes act as singular entities. each one can average it's value with connecting pipes, which leads to the sadness of pipes having terrible fall-off at distance (the distant pipe can only get 1/2 of 1/2 of 1/2... per update). Pipes check their fluid exchange at a rate of 120 times per second (by assuming their value is related to their 1200 units/s maximum). Pumps act as a virtual source with strength 100 at their output, and virtual sink of 0 at their input, with the caveat that any fluid they can't output is stored in the internal buffer first, and when that is maxed out, then the fluid must stay at the input, overriding the sink-effect.

In practicality, pipes should be based more on accumulator/power line logic. Each pipe is effectively meaningless, it just adds to the overall capacity. The pipe forms a net/graph, and when something is attached as a drain, it pulls from the capacity of the net. What you'd see if you hovered over a pipe is fluid present / number of pipes (a pipe net of 10 pipes that has 500 fluid present would show 50 if you hovered over any pipe). One would need to check drain elements before source elements, so each fluid pass, fluid is taken from the pipe before a filling pass. If that order wasn't kept, then there'd be a weird pipe limit: even if a drain could pull 100 fluid, and a source could provide 100 fluid, a full pipe would try and be filled, which doesn't work, then it would be drained by 100. Each update would show it filling from capacity-100 to maximum, then draining back to maximum - 100, an average of 100 away from the actual maximum of the pipe - which doesn't make sense if you have a full pipe, and a source and sink that are matched.

Edit: going further, to even drain amounts, the fluid permitted to be drained should be capacity / number of drains, then each drain checked. If it can't be filled, it is removed from the number of drains and the fluid drain check goes down the list of connected drains. Unfortunately, the "perfect" way of doing this is dangerous: say there were three drains, and the pipe had 100 fluid. The first drain could take 33. If the other two didn't want to take fluid however, then a single-pass would result in 33 drained, even though there's 67 left in the pipe and a drain that's not being filled. The drain check would have to keep circling around, only permitting as much fluid to be drained as if all previous drains that wanted fluid hadn't been filled. For a pipe with 100 drains, this could result in massive, massive penalties, as you may have to recheck the net many times to get "perfect" behavior. Probably still not as bad as current pipes in most cases, but it's something like an N! order of operations vs N that pipes are now.

Pipes only check once per tick, which defaults to 60 ticks a second (the UPS). Pipes not only have a source, drain and internal buffer. They also have a flow. So while a simple source/drain would get 1/2, 1/4, 1/8, 1/16, ... fluid moved to the next pipe the flow means the fluid remembers it's flowing and pick up throughput. So the math is more complex.

Next to what you suggest: It's been suggested before and you skipped reading a lot of suggestions and discussion on the topic. What you describe is a pressure model for a fluid with no mass and no friction and no turbulence. Far from how a pipe behaves and not something the devs and most players want.

[Honktown]

How does the power line code handle it. Clearly this is a problem that's been solved on the power line side, because when you run low on power, the game doesn't shit itself, but distributes a percent of power to each machine.