Factorio Forums

Posted: **Wed Jun 10, 2020 5:58 pm**

I am red-green blind (Deuteranopie) and I cannot see any improvement.
- Red and green chips still look the same for me
- red, green and normal wires I can only distinuish if the are close together.
- red, green and yellow as well as blue and violett potions look the same
- on map trees are difficult to see, especially on preview, where I cannot zoom in
- Logistic chests: same: active vs. requester and passive vs. storage vs. buffer chest
- inserters: default vs. stack inserter, fast vs. filter
- moduls: effectivity vs. productivity
For calculator and combinator there is no problem, since the actual function can be used as second infomation channel (the primary channel for colorblind people).
Why not considering such a secondary channel as default for all sprites? Color-coded information is always a hell for colorblind people. You cannot find a solution to this problem just by mapping colors. It just will not fit to the quality standard of the rest of factorio. It will just be dirty and cheap looking.
If you really interested in solving this problem you probably should consider asking some expert. Otherwise those half-way-solutions are just wasted time and money

Posted: **Wed Jun 10, 2020 5:59 pm**

Pi-C wrote: ↑
Wed Jun 10, 2020 5:09 pm

invisus wrote: ↑
Wed Jun 10, 2020 4:58 pm
Not to mention that the bottleneck indicators are now made redundant by the built-in indicator on the new miner model.
I thought these new indicators were only in the new miners? So bottleneck would be redundant just for them, not for assemblers, furnaces, etc. Is that correct?

Yep yep, totally right. Hence, "the built-in indicator on the new miner model"

Who knows, maybe if/when they release a redesigned assembler lineup, we'll see the same built-in indicators included with those new models as well.

tylere wrote: ↑
Wed Jun 10, 2020 5:37 pm
In any case, bottleneck doesn't actually overlap with the belts AT ALL. Not one single pixel.

Totally right, but you mentioned visual clarity, and often more visual "noise," especially redundant visual cues, add to that noise. Making things worse and not better. But you're right that they don't specifically block anything visually important, only that they're now (given the new indicators on the model itself), adding nothing that isn't already in/on the model.

Posted: **Wed Jun 10, 2020 6:02 pm**

P.S. : And it would be nice to solve the colorblindness-problem in vanilla, otherwise color-blind people always have to use mods to get a comfortable experience

Posted: **Wed Jun 10, 2020 7:14 pm**

FactorioBot wrote: ↑
Wed Jun 10, 2020 11:01 am

Added LuaBootstrap::register_on_entity_destroyed().

Added on_entity_destroyed event fired after an entity registered with LuaBootstrap::register_on_entity_destroyed() is destroyed.

the old entity removal events where not raised when entities are removed during chunk/surface removal.
Is this new event finally reliably raised whenever a monitored entity gets removed, or do we still have to fall back to constructs like

Code: Select all

function entity_handler(entity)
  if not entity.valid then 
    on_entity_removed(entity)
    return
  end

Posted: **Wed Jun 10, 2020 7:20 pm**

invisus wrote: ↑
Wed Jun 10, 2020 5:59 pm

Pi-C wrote: ↑
Wed Jun 10, 2020 5:09 pm

invisus wrote: ↑
Wed Jun 10, 2020 4:58 pm
Not to mention that the bottleneck indicators are now made redundant by the built-in indicator on the new miner model.
I thought these new indicators were only in the new miners? So bottleneck would be redundant just for them, not for assemblers, furnaces, etc. Is that correct?
Yep yep, totally right. Hence, "the built-in indicator on the new miner model"
Who knows, maybe if/when they release a redesigned assembler lineup, we'll see the same built-in indicators included with those new models as well.

the point was that despite what you wrote it is NOT redundant now, and will not be made redundant even if they add this indicator to new assemblers.
It will only be redundant if A L L machines get this indicator, and it will be as clearly visible and as configurable as Bottleneck is.

Posted: **Wed Jun 10, 2020 8:01 pm**

Shingen wrote: ↑
Wed Jun 10, 2020 7:20 pm
the point was that despite what you wrote it is NOT redundant now, and will not be made redundant even if they add this indicator to new assemblers.
It will only be redundant if A L L machines get this indicator, and it will be as clearly visible and as configurable as Bottleneck is.

Posted: **Wed Jun 10, 2020 8:18 pm**

ixu wrote: ↑
Wed Jun 10, 2020 6:02 pm
P.S. : And it would be nice to solve the colorblindness-problem in vanilla, otherwise color-blind people always have to use mods to get a comfortable experience

Having multiple "themes" and also making more addable by mods (wich obviously should not count as mods for multiplayer compatibility or vanilla achievements, as they only change the look of the game) is the only way to actually fix the problem without constraining the design too much (at least from my point of view - wich is that of a player having mainstream color vision).
I currently assume, that they are already going in that direction. But full theme support isn't easy and will probably not arrive before 1.0.0.

Posted: **Wed Jun 10, 2020 8:29 pm**

Oktokolo wrote: ↑
Wed Jun 10, 2020 8:18 pm
at least from my point of view - wich is that of a player having mainstream color vision

That seems to be the central problem: It is hard to understand how to solve it if you are not involved.
And it seems that even Wube fell into that trap.

Posted: **Wed Jun 10, 2020 8:59 pm**

Changed mining drill graphics definitions. Graphics are now defined using working visualizations contained in graphics_set and wet_mining_graphics_set prototype properties. If graphics_set is not defined, old animations property will be loaded instead for limited backwards compatibility, but other old graphics properties will be ignored.

I'm confused about this. What's the motivation to support the deprecated animations property but not also the other deprecated properties needed to have correct fluid behavior using the classic sprites?

Perhaps it's possible to use the new system to setup the old graphics, but the Wiki is not updated, so I don't know. :>

Posted: **Wed Jun 10, 2020 9:43 pm**

The new mining drill looks really god, but from map view or at max zoom its impossible to see the really smal red or green light, with alt mode and green modules in it its even worse also when zoomed in.
Maybe its possible to make the light a bit larger, so you can find the not working ones without mouseover evry singel one in fields with over 100 aktive mining drills.

Posted: **Wed Jun 10, 2020 9:46 pm**

FactorioBot wrote: ↑
Wed Jun 10, 2020 11:01 am

Added experimental Color Filters graphics option to attempt to improve accessibility for color-blind players.

On the one hand, it's very cool that you're even thinking about features like this. On the other hand, it seems to fall into the usual trap of assuming that the only kind of colourblindness that matters is dichromacy; as an anomalous trichromat (protanomaly, to be specific), this feature is basically useless to me, even though my specific form of colourblindness is more common than any form of dichromacy. Looks like I'll be sticking with mods for the foreseeable future.

Posted: **Thu Jun 11, 2020 12:59 am**

MageKing17 wrote: ↑
Wed Jun 10, 2020 9:46 pm

FactorioBot wrote: ↑
Wed Jun 10, 2020 11:01 am

Added experimental Color Filters graphics option to attempt to improve accessibility for color-blind players.

On the one hand, it's very cool that you're even thinking about features like this. On the other hand, it seems to fall into the usual trap of assuming that the only kind of colourblindness that matters is dichromacy; as an anomalous trichromat (protanomaly, to be specific), this feature is basically useless to me, even though my specific form of colourblindness is more common than any form of dichromacy. Looks like I'll be sticking with mods for the foreseeable future.

ixu wrote: ↑
Wed Jun 10, 2020 5:58 pm
I am red-green blind (Deuteranopie) and I cannot see any improvement.
- Red and green chips still look the same for me
- red, green and normal wires I can only distinuish if the are close together.
- red, green and yellow as well as blue and violett potions look the same
- on map trees are difficult to see, especially on preview, where I cannot zoom in
- Logistic chests: same: active vs. requester and passive vs. storage vs. buffer chest
- inserters: default vs. stack inserter, fast vs. filter
- moduls: effectivity vs. productivity
For calculator and combinator there is no problem, since the actual function can be used as second infomation channel (the primary channel for colorblind people).
Why not considering such a secondary channel as default for all sprites? Color-coded information is always a hell for colorblind people. You cannot find a solution to this problem just by mapping colors. It just will not fit to the quality standard of the rest of factorio. It will just be dirty and cheap looking.
If you really interested in solving this problem you probably should consider asking some expert. Otherwise those half-way-solutions are just wasted time and money

I am also colorblind, and I tried all 3 modes. I can't really see that anything has changed. In fact, until reading these posts, I didn't even know different combinators were colored differently.

I also have a very difficult time with fluids. Some of the new iconography has helped because it made the different oil recipes more visually distinct.

I think one thing that would help me is if the icons in "alt-mode" could have a mode where there information in a non-color channel.

However, if you are insistent in keeping it in the color channel, you might make use of the temporal domain and encode some differences there. For instance, having stack inserters 'glow' at a higher rate than regular inserters. I don't know how well this would work.

Inuitively, I don't think that a shader-based system is likely to work if you have a poor initial selection of colors. I think a good colorblind mode for this game would require some knowledge of the object that is being rendered to enable differentiation.

However, I hope you all get it figured out. I think it would be great for Factorio to be one of the examples people use on how to do colorblind modes correctly in video games.

Edit: I feel like I should clarify my statement on not realizing that combinators were different colors. While I don't know if the little display they have differs between the versions, I hadn't noticed the bodies were different colors. This is because the little display and the general shape were all that I paid attention to, and I totally ignored color.

Colorblind people, in my experience, tend to often ignore color for classification purposes as it is unreliable. I think this might be a different way of thinking for the devs because they seem to highly value color for classification purposes. This also seems to be a surprise to people who have good color vision, so I wanted to add it just in case it helps with further efforts on colorblind support.

Posted: **Thu Jun 11, 2020 1:05 am**

ixu wrote: ↑
Wed Jun 10, 2020 8:29 pm

Oktokolo wrote: ↑
Wed Jun 10, 2020 8:18 pm
at least from my point of view - wich is that of a player having mainstream color vision
That seems to be the central problem: It is hard to understand how to solve it if you are not involved.

I mentioned clientside-only theming as solution. That would allow for a high-contrast black-and-white theme. Such a theme would solve the entire class of all possible color-blindness variants as there wouldn't be any colors.

Obviously, the high-contrast black-and-white theme would only be the last resort for most color-blind people. But if users could build their own themes, less extreme and more optimized themes would get created by the community.

My non-affectedness does not make me unable to detect the most obvious, most naive, and most complete solution to the problem (and i know, that it probably isn't easy to implement, but it would be a complete solution for some other vision-related accessibility problems as well). It just makes me not wanting to lose item grouping by icon shape to cater for a myriad of different color-blindness variants.

Posted: **Thu Jun 11, 2020 5:55 am**

kirazy wrote: ↑
Wed Jun 10, 2020 8:59 pm
I'm confused about this. What's the motivation to support the deprecated animations property but not also the other deprecated properties needed to have correct fluid behavior using the classic sprites?

Perhaps it's possible to use the new system to setup the old graphics, but the Wiki is not updated, so I don't know. :>

Reason 1) is so that your mod will load, and display something (as opposed to not load or draw nothing), so modders can take their time to update the mods. 2) it allowed to not change base game pumpjack and burner mining drill definitions so mods that expect those to have current format won't break.

Posted: **Fri Jun 12, 2020 12:45 pm**

invisus wrote: ↑
Wed Jun 10, 2020 8:01 pm

Shingen wrote: ↑
Wed Jun 10, 2020 7:20 pm
the point was that despite what you wrote it is NOT redundant now, and will not be made redundant even if they add this indicator to new assemblers.
It will only be redundant if A L L machines get this indicator, and it will be as clearly visible and as configurable as Bottleneck is.

no, it's not just, like, my opinion, man.

redundant
not or no longer needed or useful; superfluous.

if there are any structures that won't have that activity indicator, then Bottleneck remains useful and therefore not redundant by definition.

also seriously, drills are like the LEAST important structures to have an activity indicator on, maybe besides water pumps, and even that i could counter-argue.

Posted: **Fri Jun 12, 2020 6:23 pm**

Regarding the indicator lights on the drills. I'm neutral on that feature.

When checking to see if the drill still had a resource to drill, I would hover the mouse to see the expected amount due from the resource. If it was zero, remove the drill. That technique would also tell me how much of which resource if there was more then one resource under the drill.

Hiladdar

Posted: **Fri Jun 12, 2020 6:59 pm**

Shingen wrote: ↑
Fri Jun 12, 2020 12:45 pm

invisus wrote: ↑
Wed Jun 10, 2020 8:01 pm

Shingen wrote: ↑
Wed Jun 10, 2020 7:20 pm
the point was that despite what you wrote it is NOT redundant now, and will not be made redundant even if they add this indicator to new assemblers.
It will only be redundant if A L L machines get this indicator, and it will be as clearly visible and as configurable as Bottleneck is.

no, it's not just, like, my opinion, man.
redundant
not or no longer needed or useful; superfluous.
if there are any structures that won't have that activity indicator, then Bottleneck remains useful and therefore not redundant by definition.

also seriously, drills are like the LEAST important structures to have an activity indicator on, maybe besides water pumps, and even that i could counter-argue.

Okay, so humor has failed on you as well.

Look, I'm not sure why you're being so pedantic about this. Yes, you're technically correct if you take what I said _out of context_. However, if you realize that my original comment that you seem to take issue with, was in reference to this specific image:

tylere wrote: ↑
Wed Jun 10, 2020 4:05 pm
I really, really dislike the new mining drill model.

It covers up the belt nearly totally and reduces visual clarity.

You'd notice that the bottleneck indicators I was referring to, and the _only_ ones visible in the picture, are ones on the newly redesigned mining drill entity... which as I was pointing out, now comes with it's OWN indicators. Therefor, I was simply stating that _those_ indicators are redundant. I never claimed that bottleneck as a whole is no longer necessary or that all of its indicators are now made redundant by the redesign of just the mining drill. That would be ridiculous.

So please, just take a deep breath and realize I was making a comment in a specific context and not trying to attack the bottleneck mod as a whole.

Posted: **Fri Jun 12, 2020 8:35 pm**

I have to say that I do not like the new drill graphics. It overlaps too much with the belts from both sides. I keep placing belts one tile away from the drills cause visually it looks as if you have to build the belts on the same tile as the drill because of the overlap

Posted: **Sat Jun 13, 2020 9:09 pm**

Problem developed when updating to new version.

I have multiple trains that can drop off at the same location. Think 4 sources for iron plate and 1 requester for iron plate. Requester station turns off when sufficient amount of material is in chests, or a train is already in station.

The problem happens when multiple trains are on the way to the station, one shows up, turns off the station, and all the other trains stop dead on the tracks and need to be manually resent to the loading location. Previously they would automatically route back to the point of origin, refuel, and wait for the requester to need iron plate again. This appears to be a new behavior.

PS: LOVE this game....

Posted: **Sun Jun 14, 2020 5:26 pm**

jeffwa wrote: ↑
Sat Jun 13, 2020 9:09 pm
Problem developed when updating to new version.

I have multiple trains that can drop off at the same location. Think 4 sources for iron plate and 1 requester for iron plate. Requester station turns off when sufficient amount of material is in chests, or a train is already in station.

The problem happens when multiple trains are on the way to the station, one shows up, turns off the station, and all the other trains stop dead on the tracks and need to be manually resent to the loading location. Previously they would automatically route back to the point of origin, refuel, and wait for the requester to need iron plate again. This appears to be a new behavior.

PS: LOVE this game....

I had similar problem. My solution was to decentralize train depo, with a small train stackers right next to the location requesting the resources. When resources are needed, a train with what the outpost or station needs, is signaled, and it move up, unloads it's load, then heads out picks up fresh load of the same item, and returns to the stacker. Refueling can be done at a central refueling station (with assistance of some mods), or delivered to the outpost, and as the load is unloaded, the locomotive is refueled.

This is one of many solutions to your problem. Some of the solutions will involve various levels of circuit network, mine does, but minimal. Some solutions are based on pull logistical requests, others on push. Some solutions can be facilitated by great mods like LTN.

What is key here is you are having fun, figuring this stuff out and tweaking, stuff as it is changed by both Factorio and moddlers. Since we are playing in the pre-1.0 release version of the game, both on experimental and stabe, unfortunately or maybe fortunately, based on your outlook, this may not be the last time you experience such "new undocumented features"

Hiladdar

Factorio Forums

Version 0.18.31

Re: Version 0.18.31

Re: Version 0.18.31

Re: Version 0.18.31

Re: Version 0.18.31

Re: Version 0.18.31

Re: Version 0.18.31

Re: Version 0.18.31

Re: Version 0.18.31

Re: Version 0.18.31

Re: Version 0.18.31

Re: Version 0.18.31

Re: Version 0.18.31

Re: Version 0.18.31

Re: Version 0.18.31

Re: Version 0.18.31

Re: Version 0.18.31

Re: Version 0.18.31

Re: Version 0.18.31

Re: Version 0.18.31

Re: Version 0.18.31