Friday Facts #318 - New Tooltips

Regular reports on Factorio development.
mrvn
Smart Inserter
Smart Inserter
Posts: 3892
Joined: Mon Sep 05, 2016 9:10 am
Contact:

Re: Friday Facts #318 - New Tooltips

Post by mrvn » Mon Oct 28, 2019 10:46 am

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.

User avatar
EstebanLB
Fast Inserter
Fast Inserter
Posts: 100
Joined: Mon Apr 15, 2013 3:00 am
Contact:

Re: Friday Facts #318 - New Tooltips

Post by EstebanLB » Mon Oct 28, 2019 4:01 pm

Personal Roboport tooltip is missing Logistic area

posila
Factorio Staff
Factorio Staff
Posts: 4014
Joined: Thu Jun 11, 2015 1:35 pm
Contact:

Re: Friday Facts #318 - New Tooltips

Post by posila » Mon Oct 28, 2019 5:17 pm

EstebanLB wrote:
Mon Oct 28, 2019 4:01 pm
Personal Roboport tooltip is missing Logistic area
Personal roboport doesn't have logistic area.

User avatar
EstebanLB
Fast Inserter
Fast Inserter
Posts: 100
Joined: Mon Apr 15, 2013 3:00 am
Contact:

Re: Friday Facts #318 - New Tooltips

Post by EstebanLB » Mon Oct 28, 2019 5:27 pm

posila wrote:
Mon Oct 28, 2019 5:17 pm
EstebanLB wrote:
Mon Oct 28, 2019 4:01 pm
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

User avatar
Masterpintsman
Burner Inserter
Burner Inserter
Posts: 11
Joined: Tue Feb 02, 2016 10:03 am
Contact:

Re: Friday Facts #318 - New Tooltips

Post by Masterpintsman » Mon Oct 28, 2019 11:57 pm

TheRaph wrote:
Sat Oct 26, 2019 3:34 pm
Just now my idea to let bots do more than one job:
^ What's in this post, please ^

User avatar
KunibertSegensreich
Burner Inserter
Burner Inserter
Posts: 16
Joined: Fri Jun 08, 2018 9:22 pm
Contact:

Re: Friday Facts #318 - New Tooltips

Post by KunibertSegensreich » Tue Oct 29, 2019 12:18 pm

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);
}

User avatar
eradicator
Smart Inserter
Smart Inserter
Posts: 3770
Joined: Tue Jul 12, 2016 9:03 am
Contact:

Re: Friday Facts #318 - New Tooltips

Post by eradicator » Tue Oct 29, 2019 2:47 pm

Oxyd wrote:
Fri Oct 25, 2019 3:18 pm
eradicator wrote:
Fri Oct 25, 2019 3:04 pm
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.
Author of: Hand Crank Generator, Screenshot Hotkey 2.0
Mod support languages: 日本語, Deutsch, English
My code in the post above is dedicated to the public domain under CC0.

mrvn
Smart Inserter
Smart Inserter
Posts: 3892
Joined: Mon Sep 05, 2016 9:10 am
Contact:

Re: Friday Facts #318 - New Tooltips

Post by mrvn » Tue Oct 29, 2019 5:24 pm

KunibertSegensreich wrote:
Tue Oct 29, 2019 12:18 pm
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
Long Handed Inserter
Long Handed Inserter
Posts: 50
Joined: Sun Mar 27, 2016 4:24 pm
Contact:

Re: Friday Facts #318 - New Tooltips

Post by NeilN » Tue Oct 29, 2019 7:41 pm

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
Inserter
Inserter
Posts: 49
Joined: Tue Apr 12, 2016 5:39 am
Contact:

Re: Friday Facts #318 - New Tooltips

Post by Ironhair » Thu Oct 31, 2019 4:44 am

So, for now they just batch build tiles.
Is it possible to enable it for walls/gates?

User avatar
eradicator
Smart Inserter
Smart Inserter
Posts: 3770
Joined: Tue Jul 12, 2016 9:03 am
Contact:

Re: Friday Facts #318 - New Tooltips

Post by eradicator » Thu Oct 31, 2019 2:34 pm

NeilN wrote:
Tue Oct 29, 2019 7:41 pm
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.
Author of: Hand Crank Generator, Screenshot Hotkey 2.0
Mod support languages: 日本語, Deutsch, English
My code in the post above is dedicated to the public domain under CC0.

TheRealBecks
Inserter
Inserter
Posts: 32
Joined: Sat Mar 26, 2016 3:47 pm
Contact:

Re: Friday Facts #318 - New Tooltips

Post by TheRealBecks » Thu Oct 31, 2019 3:51 pm

Twinsen wrote:
Sat Oct 26, 2019 8:26 pm
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
Burner Inserter
Burner Inserter
Posts: 16
Joined: Sat Dec 08, 2018 9:42 pm
Contact:

Re: Friday Facts #318 - New Tooltips

Post by Byproduct » Thu Oct 31, 2019 3:57 pm

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.

User avatar
BlueTemplar
Smart Inserter
Smart Inserter
Posts: 1820
Joined: Fri Jun 08, 2018 2:16 pm
Contact:

Re: Friday Facts #318 - New Tooltips

Post by BlueTemplar » Thu Oct 31, 2019 7:42 pm

Byproduct wrote:
Thu Oct 31, 2019 3:57 pm
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.)
Last edited by BlueTemplar on Thu Oct 31, 2019 10:02 pm, edited 1 time in total.

Byproduct
Burner Inserter
Burner Inserter
Posts: 16
Joined: Sat Dec 08, 2018 9:42 pm
Contact:

Re: Friday Facts #318 - New Tooltips

Post by Byproduct » Thu Oct 31, 2019 8:31 pm

BlueTemplar wrote:
Thu Oct 31, 2019 7:42 pm
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. :D

Syriusz
Inserter
Inserter
Posts: 36
Joined: Thu May 07, 2015 12:34 pm
Contact:

Re: Friday Facts #318 - New Tooltips

Post by Syriusz » Fri Nov 01, 2019 10:28 am

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
Factorio Staff
Factorio Staff
Posts: 1072
Joined: Tue Sep 23, 2014 7:10 am
Contact:

Re: Friday Facts #318 - New Tooltips

Post by Twinsen » Mon Nov 04, 2019 10:24 am

TheRealBecks wrote:
Thu Oct 31, 2019 3:51 pm
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
Filter Inserter
Filter Inserter
Posts: 250
Joined: Thu Oct 03, 2019 7:10 am
Contact:

Re: Friday Facts #318 - New Tooltips

Post by Honktown » Mon Nov 04, 2019 11:59 am

Twinsen wrote:
Mon Nov 04, 2019 10:24 am
TheRealBecks wrote:
Thu Oct 31, 2019 3:51 pm
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
Smart Inserter
Smart Inserter
Posts: 3892
Joined: Mon Sep 05, 2016 9:10 am
Contact:

Re: Friday Facts #318 - New Tooltips

Post by mrvn » Mon Nov 04, 2019 12:14 pm

Honktown wrote:
Mon Nov 04, 2019 11:59 am
Twinsen wrote:
Mon Nov 04, 2019 10:24 am
TheRealBecks wrote:
Thu Oct 31, 2019 3:51 pm
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
Filter Inserter
Filter Inserter
Posts: 250
Joined: Thu Oct 03, 2019 7:10 am
Contact:

Re: Friday Facts #318 - New Tooltips

Post by Honktown » Mon Nov 04, 2019 12:17 pm

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.

Post Reply

Return to “News”

Who is online

Users browsing this forum: No registered users