Page 2 of 3
Re: Friday Facts #232 - PAX, Bugs, Graphs
Posted: Sat Mar 03, 2018 10:09 am
by Tirus
My querstion to the factorio dev team:
Is there a special reason for supporting DirectX explicitly if OpenGL works great on
all supported platforms. Is there a benefit?
Also i would suggest to support the minimum required DirectX/OpenGL version.
Because as i see your game just does 2D graphics, there should be no need
for e.g. the tessellation features that comes with DirectX 11 or OpenGL 4+.
If the game requires a "to new" graphics engine you may stop some players
with not the newest hardware to be able to play the game without need.
For example: On linux some graphics driver just supports OpenGL 3.0
while the hardware is more than good enough to play the game.
(The intel HD drivers support only OpenGL 3.0 compatible and OpenGL 3.3 core
profile with CPU's of the 4000 and prevoius series).
Re: Friday Facts #232 - PAX, Bugs, Graphs
Posted: Sat Mar 03, 2018 11:18 am
by dasiro
MeduSalem wrote:... also don't forget a "pause research" button. It would be nice to have that as well. Then I don't have to run through half my factory to hit a powerswitch.
why would you pause research manually? just hook that powerswitch up to a signal and define when it should stop (for instance when battery charge dives under 10%)
Re: Friday Facts #232 - PAX, Bugs, Graphs
Posted: Sat Mar 03, 2018 12:43 pm
by kitcat
Claudius1729 wrote:Could we get native support for all keyboard layouts? Like AZERTY, DVORAK, etc. Many game have it nowaydays by default.
Unless it happened at some point and I didn't notice it.
Neo 2.0 (aka. XVLCW) is working almost perfectly at least on Linux. (Some layer 4 keys don’t work, but other layouts don’t have those and I don’t expect special treatment.)
Are you actually using an alternate layout if you didn’t notice if it works or not?
Re: Friday Facts #232 - PAX, Bugs, Graphs
Posted: Sat Mar 03, 2018 3:56 pm
by MeduSalem
dasiro wrote:MeduSalem wrote:... also don't forget a "pause research" button. It would be nice to have that as well. Then I don't have to run through half my factory to hit a powerswitch.
why would you pause research manually? just hook that powerswitch up to a signal and define when it should stop (for instance when battery charge dives under 10%)
Sometimes I need the resources for something else... like for example expanding the base in case of a bottleneck. Don't feel like waiting for an eternity for the research to finish first before crafting speed for the other stuff becomes decent again. That is usually when I pause the research manually for a short period of time to resolve bottlenecks because it is faster than when everything is drawing resources in parallel.
But there are several other situations as well other than just "saving energy".
If you say that you never experienced a situation where you wished to pause the research manually then I think that you haven't played the game enough.
Re: Friday Facts #232 - PAX, Bugs, Graphs
Posted: Sat Mar 03, 2018 5:12 pm
by Jon8RFC
We love data, (some of) you guys love providing data, so what about a web page with historical crash-submission graphs which updates daily? Factorio is about management, after all, so we're only missing observational data management of the game itself
Toss in some git-like +/- lines of code and commits for each release, and a multiplayer server report of version distribution with a historical stacked-area percentage chart and a daily pie chart (maybe a sunburst pie chart...googled a bunch), and we're good...until y'all think of another awesome bit of data to include. Because who doesn't love a site like
https://steamstat.us/
Re: Friday Facts #232 - PAX, Bugs, Graphs
Posted: Sat Mar 03, 2018 6:41 pm
by Jap2.0
Jorn86 wrote:Just curious, is the toolbar update from
FFF #191 still on the radar? Because that sounded (and still does) like a great improvement.
That's for 0.17, which will include an updated (actually largely or entirely rewritten) GUI and graphics engine.
Re: Friday Facts #232 - PAX, Bugs, Graphs
Posted: Sat Mar 03, 2018 8:47 pm
by tazdu29
MeduSalem wrote:dasiro wrote:MeduSalem wrote:... also don't forget a "pause research" button. It would be nice to have that as well. Then I don't have to run through half my factory to hit a powerswitch.
why would you pause research manually? just hook that powerswitch up to a signal and define when it should stop (for instance when battery charge dives under 10%)
Sometimes I need the resources for something else... like for example expanding the base in case of a bottleneck. Don't feel like waiting for an eternity for the research to finish first before crafting speed for the other stuff becomes decent again. That is usually when I pause the research manually for a short period of time to resolve bottlenecks because it is faster than when everything is drawing resources in parallel.
But there are several other situations as well other than just "saving energy".
If you say that you never experienced a situation where you wished to pause the research manually then I think that you haven't played the game enough.
This !
Or when you're running out of ores, and you need to keep your resources for ammo and next expansion.
ThaPear wrote:Impressive decline in crashes.
The real question is : "Is that a side effect of last FFF ?"
Claudius1729 wrote:Could we get native support for all keyboard layouts? Like AZERTY, DVORAK, etc. Many game have it nowaydays by default.
Unless it happened at some point and I didn't notice it.
I'm using an AZERTY layout under both windows (steam) and linux (drm free) versions of the game, and it's working perfectly fine.
Re: Friday Facts #232 - PAX, Bugs, Graphs
Posted: Sat Mar 03, 2018 9:42 pm
by unobtanium
So what is the GUI queue going to be used for?
Re: Friday Facts #232 - PAX, Bugs, Graphs
Posted: Sat Mar 03, 2018 10:40 pm
by thecatlover1996
unobtanium wrote:So what is the GUI queue going to be used for?
FFF-232 wrote:
a new technology GUI that among other small things, has a queue.
My guess is that you will be able to queue technologies for research

Re: Friday Facts #232 - PAX, Bugs, Graphs
Posted: Sun Mar 04, 2018 8:28 am
by DaemosDaen
tazdu29 wrote:MeduSalem wrote:dasiro wrote:MeduSalem wrote:... also don't forget a "pause research" button. It would be nice to have that as well. Then I don't have to run through half my factory to hit a powerswitch.
why would you pause research manually? just hook that powerswitch up to a signal and define when it should stop (for instance when battery charge dives under 10%)
Sometimes I need the resources for something else... like for example expanding the base in case of a bottleneck. Don't feel like waiting for an eternity for the research to finish first before crafting speed for the other stuff becomes decent again. That is usually when I pause the research manually for a short period of time to resolve bottlenecks because it is faster than when everything is drawing resources in parallel.
But there are several other situations as well other than just "saving energy".
If you say that you never experienced a situation where you wished to pause the research manually then I think that you haven't played the game enough.
This !
Or when you're running out of ores, and you need to keep your resources for ammo and next expansion.
ThaPear wrote:Impressive decline in crashes.
The real question is : "Is that a side effect of last FFF ?"
Claudius1729 wrote:Could we get native support for all keyboard layouts? Like AZERTY, DVORAK, etc. Many game have it nowaydays by default.
Unless it happened at some point and I didn't notice it.
I'm using an AZERTY layout under both windows (steam) and linux (drm free) versions of the game, and it's working perfectly fine.
What dasiro was saying was to just hook up a power switch to the between the labs and what ever powers them, then simply send a signal to the labs to turn them off. You'll need to wire your whole rail network as well as getting the signal to the labs and you can send the signal via a constant combinatory.... why I have never thought of that simple idea before is beyond me.
Re: Friday Facts #232 - PAX, Bugs, Graphs
Posted: Sun Mar 04, 2018 12:51 pm
by milo christiansen
Well, for me I have all my big power poles wired into a single network in order to carry certain global control signals anyway (used mostly for emergency power cutoffs to keep the base defenses from turning off during a major brownout), so I just add latches to anything I want to control remotely.
With a bit of combinator fun and games, all I need to do is send a signal pair to toggle most things on or off. "red" and "copper wire" for example turns off everything except the base defenses, sending "green" and "copper wire" later resets the system. The signal is only needed momentarily, so you just plop down a constant combinator, set the signals, then pick it back up and go on your way. I have quite a few sub-factories switched this way.
Re: Friday Facts #232 - PAX, Bugs, Graphs
Posted: Sun Mar 04, 2018 4:03 pm
by MeduSalem
DaemosDaen wrote:What dasiro was saying was to just hook up a power switch to the between the labs and what ever powers them, then simply send a signal to the labs to turn them off. You'll need to wire your whole rail network as well as getting the signal to the labs and you can send the signal via a constant combinatory.... why I have never thought of that simple idea before is beyond me.
milo christiansen wrote:Well, for me I have all my big power poles wired into a single network in order to carry certain global control signals anyway (used mostly for emergency power cutoffs to keep the base defenses from turning off during a major brownout), so I just add latches to anything I want to control remotely.
With a bit of combinator fun and games, all I need to do is send a signal pair to toggle most things on or off. "red" and "copper wire" for example turns off everything except the base defenses, sending "green" and "copper wire" later resets the system. The signal is only needed momentarily, so you just plop down a constant combinator, set the signals, then pick it back up and go on your way. I have quite a few sub-factories switched this way.
Wiring the entire train network is an ugly pest. I used to do that years ago... but it is so not worth it.
Instead I turn the loading and unloading train stations on/off based on the logistic network content, so they are only ever active if there is enough for a train to pick up or if more stuff is required. All my trains have 4 trainstations in their schedule:
Also I use logistic/circuit network conditions in the research modules to turn off the labs in certain detectible cases like ore shortages etc. My trains unload into Active Provider chests (so that the chests are always empty when a train arrives) and the stuff then gets put temporarily into Storage Chests. If the amount of Ore in the Storage Chests ever drops below a certain threshold I know that I am consuming more than is delivered... which can only mean one thing: Running out of that particular ore type.
I use a roboport and feed the logistics content as signal to several deciders... each checking for one ore type and only if the amount of ore is beyond the threshold for all the ore types then the research module is activated at all. And if the conditions are not met I use the signal to completely shut down everything of the research module. Not just the labs, but also every other related assembler/chemplant/refinery, beacons and inserters. I use just-in-time production for research anyway so if only one thing runs out the entire research module would grind to a halt anyway to wait up for that thing, so might as well just shut off everything then.
That said some things are rather hard/complicated or outright impossible to detect using logistic/circuit network conditions, hence why it is always good to have a way of manual interference ontop of that as well just in case everything goes haywire.
Re: Friday Facts #232 - PAX, Bugs, Graphs
Posted: Sun Mar 04, 2018 7:29 pm
by taikodragon
MeduSalem wrote:I use just-in-time production for research anyway so if only one thing runs out the entire research module would grind to a halt anyway to wait up for that thing, so might as well just shut off everything then.
Could you explain what "just-in-time production" is? I haven't heard of that with respect to Factorio.
Re: Friday Facts #232 - PAX, Bugs, Graphs
Posted: Sun Mar 04, 2018 9:41 pm
by MeduSalem
taikodragon wrote:MeduSalem wrote:I use just-in-time production for research anyway so if only one thing runs out the entire research module would grind to a halt anyway to wait up for that thing, so might as well just shut off everything then.
Could you explain what "just-in-time production" is? I haven't heard of that with respect to Factorio.
Well, just-in-time is exactly that... you produce an item only when it is requested.
The opposite would be buffering, where you buffer items up so you have them already in store when you eventually need them.
So what that means in my case is that every science pack and every ingredient is only produced on demand. There is no overproduction. The amount of machines are matched exactly to meet the demand of the recipes.
When one of the ingredients is lacking it automatically becomes the bottleneck because there is no buffer of anything to deal with that.
Re: Friday Facts #232 - PAX, Bugs, Graphs
Posted: Sun Mar 04, 2018 11:02 pm
by foodfactorio
MeduSalem wrote:So what that means in my case is that every science pack and every ingredient is only produced on demand. There is no overproduction. The amount of machines are matched exactly to meet the demand of the recipes.
for science packs, it could be good to let them build lots of spares (but still with a pause if low on items), because some of the Tech Research needs lots of science packs, and later in the game when Labs get speed bonuses, you might run out of science. (either way, it is either a case of running out of packs and waiting for more to be built, or using up resources and being stuck with packs)
i tend to put all science into 1 chest, and let the chest fill up as much as it can, but nearer the end game i will probably try to limit it some more as tech gets unlocked. (but now with some of the Inifinite Research mods, there is probably a good use for making lots of Science Packs)

Re: Friday Facts #232 - PAX, Bugs, Graphs
Posted: Sun Mar 04, 2018 11:09 pm
by impetus maximus
OpenGL 3.3, and DirectX11?

a lot of players are not going to have support for these.
Re: Friday Facts #232 - PAX, Bugs, Graphs
Posted: Sun Mar 04, 2018 11:43 pm
by posila
Tirus wrote:My querstion to the factorio dev team:
Is there a special reason for supporting DirectX explicitly if OpenGL works great on
all supported platforms. Is there a benefit?
...
(The intel HD drivers support only OpenGL 3.0 compatible and OpenGL 3.3 core
profile with CPU's of the 4000 and prevoius series).
The reason to have DX implementation is that OpenGL
doesn't work great on any platform.
We are going for OpenGL 3.3 core, and DirectX 11 with feature level 10 (so you'll need Direct3D 10 capable GPU to run the game), according to Steam HW survey, that coveres 98% of our current player base. We might have some legacy mode for older PCs.
impetus maximus wrote:OpenGL 3.3, and DirectX11?

a lot of players are not going to have support for these.
Intel HD Graphics 3000 is DX10 capable, so you should be fine.
Re: Friday Facts #232 - PAX, Bugs, Graphs
Posted: Mon Mar 05, 2018 12:09 am
by impetus maximus
posila wrote:
impetus maximus wrote:OpenGL 3.3, and DirectX11?

a lot of players are not going to have support for these.
Intel HD Graphics 3000 is DX10 capable, so you should be fine.
whew! many thanks.

Re: Friday Facts #232 - PAX, Bugs, Graphs
Posted: Mon Mar 05, 2018 11:17 am
by mrvn
ThaPear wrote:Impressive decline in crashes.
Or just people learning what not to do because then the game crashes.
Re: Friday Facts #232 - PAX, Bugs, Graphs
Posted: Mon Mar 05, 2018 11:25 am
by 5thHorseman
mrvn wrote:ThaPear wrote:Impressive decline in crashes.
Or just people learning what not to do because then the game crashes.
Which would be a weird result of the automatic log uploading.