Factorio Forums

From viewtopic.php?f=6&t=28327

After some mail-correspondence with one of the forum-users, I thought it would be a good idea to have a place, where you can put in all those things that are not worth to mention, but as sum it is some kind of big list.

So I start this as experiment:
Post your little quirks and small issues into this thread!

Simple rules:
- Not too much quirks per post (2 or 3 max).
- Only about existing quirks/issues. No game-logic, no new stuff, no game-play-suggestions.
- Try to describe exactly what you want to have better.
- In doubt: Screenshot it so that all can follow (you know you can upload up to 10 pics per post.
- Please only short discussions.

As said: This is an experiment, I hope that we can create a result, that could be used change those small itchy things, that some people hurt a lot.

From viewtopic.php?f=6&t=33082

Not sure how far this can go with only graphical stuff! Here's a couple though;

With trains there are 2 different window sizes used, these two boxes should be of uniform size, so it's well... uniform for one, and easier to use for two! Such a small box is irritating, it's too fiddly, sure there is a search box there.. But we all scroll windows day in day out, rarely using search boxes.






Please make the add route box bigger.

The other one was to do with blueprints, which wash out the terrain when you have many turrets in one blue print;






As you can see in the second image the water to the left is almost totally obscured. It would be better to be able to see the exact shape of the shoreline, rather than guess from looking at the obstructed objects positioning.

I changed the topic: Not only graphical issues, but any small issues should come into this thread.

This is more related to the webpage than the game. I would recommend swapping the order of the two trailers on the webpage (and also the Steam store page). The one with the narration should be first, so anyone who hasn't seen it before can be told what it is all about. The second one is fun to look at, but doesn't really explain anything. That one would best be seen after the one with narration is seen.

I've read a post from the League of legends gui designer that told they try to keep buttons together that are used together. So what always annoyed me...


here's a possible fix:

I would suggest making the tech-tree and the description collapsible. If someone plays Factorio long enough, they would know what most of the things do, and where in the tech-tree the technology lies, so for beginners, the tech-tree portion and description-portion would both be un-collapsed by default (with a button to collapse them so the tech-screen does not clutter the view). There will be a global UI-setting on whether or not to collapse them by default. More experienced players may still want to take a peek from time to time - so if collapsed by default, they could press a button to un-collapse the view.

I don't understand peoples obsession with clicking "X" to close a window in a game THAT DOESN'T USE X TO CLOSE ANY WINDOW EVER ANYWHERE ON ANYTHING.

You need help people that do that

AntiElite wrote:I've read a post from the League of legends gui designer that told they try to keep buttons together that are used together. So what always annoyed me...

Neither of those work when you don't have a 1080p + sized monitor.

The list of researches could be moved to the right instead? This would also put the scrollbar on the very right of the screen (where it belongs) and won't take up any additional space. And I think the reason players perceive it differently is because it's the only full-screen window in the game. Therefore when anyone wants to close it they automatically see the X in the corner and assume that's to close it. Personally I prefer fullscreen so it's not an issue for me.

Most annoying quirk I can think of right now is the Roboport graphic, it's the only entity that you can't determine the size and boundaries of at a glance, because the "base" of the unit only covers three tiles north/south. Technically speaking, the northmost row of tiles contains nothing but air but is still within the roboport's boundaries. Also because its base is round it doesn't fully take up all four columns either, though the gap is distributed 50/50 between the westmost and eastmost columns. Therefore the visuals for the roboport are 3x3, but it's actually 4x4. It's very disorienting when trying to plan for it. Note in the following image the distance between the robotport and the belts, also compare the visuals of the roboport to the 3x3 electric furnaces above:
Oh, then there's programming my wait conditions for oil unloading, I only have a single oil train that alternates between each outpost and unloading, outpost 1, unload, outpost 2, unload, etc. However the wait conditions for unloading are a little complex (includes a minimum wait time, inactivity, and circuit condition) which is a pain to re-enter every - single - time I add an outpost. A button to copy a destination with conditions to the bottom of the train's route (alternatively, copy wait conditions between stops on a route) would be very much appreciated.

EDIT: WAIT I remembered another one! When detailed view is on can we have an indicator as to which direction a Diesel Locomotive is facing? It can be tricky to determine its direction at a glance, which is especially annoying when placing it.

Rseding91 wrote:I don't understand peoples obsession with clicking "X" to close a window in a game THAT DOESN'T USE X TO CLOSE ANY WINDOW EVER ANYWHERE ON ANYTHING.

You need help people that do that

I know, I know . It's not like it happens frequently, but the 3 times it happend I was just . It's only the tech tree, cause it's fullscreen tho, that makes me want to click the X

Rseding91 wrote:Neither of those work when you don't have a 1080p + sized monitor.

I don't get the point here, can you explain?

I'm unable to take auto-trashed stuff out of the trash-slots into the hand. Auto-trash should not apply to things in your hand.

Robots are annoyingly stupid, improvements could be e.g. not trying to repair stuff that currently goes faster than the robots; factoring charging points into the flight route etc. And they should consider more than one job per tick as it gets annoyingly slow when there are >200 jobs.

An unlocked framerate would be nice (this requires movement prediction as described here: viewtopic.php?f=6&t=33946 ) Most other games have this already.

Oh and +1 for the copy train conditions idea

AntiElite wrote:

Rseding91 wrote:Neither of those work when you don't have a 1080p + sized monitor.

I don't get the point here, can you explain?

That is to say players on lower resolution won't be able to use a reduced size or heavily modified layout.

HL65536 wrote:An unlocked framerate would be nice (this requires movement prediction as described here: viewtopic.php?f=6&t=33946 ) Most other games have this already.

I am for the suggestions to bots but Factorio isn't "most games", it updates and renders differently. Sure, it might be possible, but it would probably require a rewrite of at least half the graphics code and introduce a thousand new bugs and visual problems. Sure, it might look a bit smoother, but personally I can see the refresh rate of fluorescent lights and I don't have a problem with the framerate in this game so would rather they fixed combat or something. Also, this isn't really a "quirk", it's a new feature.

Deadly-Bagel wrote:

AntiElite wrote:

Rseding91 wrote:Neither of those work when you don't have a 1080p + sized monitor.

I don't get the point here, can you explain?

That is to say players on lower resolution won't be able to use a reduced size or heavily modified layout.
I see, thougth the size of the icons scales with the resolution. Still the research button position migth be changed

Maybe it's just me, but one particularly annoying quirk is that inserters can end up holding a resource that they cannot place into the assembler they are pointed at. This can easily shut down production for that assembler accidentally without any clear visual clues as seeing what inserters are holding since they are holding it over the assembler itself. It took me quite a bit of playing to figure out how to debug this behavior for my own factories because it looks like the assembler 'just wont work'.

Edit: This shows up primarily when you remove an assembler and the put another in the same place. The inserter will grab items and try to move them to the empty space, and when you put a new assembler there, unless you're assembling the same item it wont be insertable. This locks up your inserters without a clear indication. I noticed this a lot early game when I did a lot of reassembly, and very late game when, for example, I would take apart a research line to create a low density structures line in the same location.

The solution of this would be that when placing an assembler in a location, not only does it pick up the materials off the ground as it does now, it would also take the materials held by the inserter that is trying to place that material where the new assembler is.

Really? I'm aware that's a problem for any type of storage but assemblers have a "soft cap" for inserting items, most of the time inserters will stop trying to move that resource after 2x the recipe has been added. Additionally the stack size seems to be the usual stack size plus what is required for the recipe. Therefore you shouldn't get this behaviour with assemblers, but again this isn't necessarily a quirk is it?

However this has reminded me of another quirk, when producing almost any resource it stops requesting ingredients when a small number of the product remains in the assembler (I've never found any consistent behaviour with this). This is important to prevent thousands of materials from becoming tied up in optimised layouts where they are produced as fast as they can be used. For example Copper Wire to Green Circuits in a 3-2 ratio can only be consumed at the rate the assembler makes them. So having the full stack size of copper wire in the output slot of their assemblers is wasted. The exceptions are iron/copper plates, because ore basically can't be used for anything else anyway, and sulphur.

Sulphur is an odd one because it is a solid component with an actual stack size, but it is the only one to be created purely from liquids. As Chem Plants don't request liquids, they simply flow into the plant, there is nothing to stop the FULL stack size of sulphur building up in the Chem Plant. When you have an optimised 5-2 ratio of sulphur Chem Plants to sulphuric acid Chem Plants, this adds up, 750 petroleum is permanently tied up in sulphur. It can never be depleted unless the petroleum supply runs out. Anything that can be done about this? I wouldn't be averse to it stacking to 10 globally, it's not used in huge quantities.

As moderator I don't want to stop discussion, I just point to the rules of this topic not to discuss too much.

Inserters are sometimes not quick enough (although they have enough bandwidth) to put items into an assembler with lots of speed modules. The resource buffer size should depend on current crafting speed.

Loading time: Factorio is the only game <1GB that is on my SSD. Lots of small files are slow to load from a HDD + PNG decoding can be slow on lower end cpus (+ png decoding is not multithreaded right now!)

Right when i wanted to post this it said "please log back in" and all my text was gone - this is another quirk.

When building and deconstructing, particularly with personal roboports, it would be nice if the bots would prioritize closer stuff. I mean, I specifically stand in the middle of the ghost blueprint, to give them the shortest possible flight times, and half of them immediately go to place something at the far edge of the blueprint? I swear these bots are unionized...

Mehve wrote:When building and deconstructing, particularly with personal roboports, it would be nice if the bots would prioritize closer stuff. I mean, I specifically stand in the middle of the ghost blueprint, to give them the shortest possible flight times, and half of them immediately go to place something at the far edge of the blueprint? I swear these bots are unionized...

Any change of the order they work in would just waste CPU time trying to find the closest to work on. They're worked on in the order they're requested which is the order they're built.

That's fair I suppose, although I wouldn't have thought that a single pythagorean equation for each item would be that taxing? Or a simply prioritizing any any object who's x/y coordinates are numerically within a certain distance of the player's?

Not a huge deal, granted, and easily accommodated by just deconstructing smaller bits at a time.