Factorio Forums

At recent FFF Wube have shown how they are planning to deal with well-known train length issue.
Screenshots weren't accepted too warm, and I think it's time to make a small pole, that hopefully will help (but not force in any way) to make right decision how to solve the issue.

UPD: "Ooops" have happened, previous results are nullified (see post #3 for details)

As I had just realized in the FFF thread, it might also work to redesign train components to be square and thus evade the issue entirely. Nothing says that railcars and engines have to be as long as they are now.

AssaultRaven wrote:As I had just realized in the FFF thread, it might also work to redesign train components to be square and thus evade the issue entirely. Nothing says that railcars and engines have to be as long as they are now.

I added an option to the poll but... Goddam, system haven't warned me results will get nullified! O_o (It definitely should)
Sorry guys, this is my first pole, and I've successfully messed it up
So now gotta revote

As I remember, votes were

• Leave - 0
  Stretch - 2
  Gaps - 4
  Grid snap - 2
  Grid snap /w gaps - 1

Honestly I'd rather then fix them so they only need 6 tiles whether vertical or horizontal and DON'T have those ugly gaps.
Failing that, leave them as they are now.

While I'm in favor of trying to fix the issue of length on H vs V, I'm not a huge fan of the methods they proposed. The gap method just doesn't look right to me. It's extremely noticeable going from no gap to ahuge gap between Wagons and loco. If anything I think graphics stretching might better.

I think they should just split the difference and implement both methods....stretch the graphics but use gaps to keep from looking too ridiculous.

katyal wrote:I think they should just split the difference and implement both methods....stretch the graphics but use gaps to keep from looking too ridiculous.

it was my impression the Blog ended on that note as a likely final solution.

These are far from perfect, but with some little adjustments, like a connection rod, and slight stretching , it might actually work, which is a big relief.

taiiat wrote:

katyal wrote:I think they should just split the difference and implement both methods....stretch the graphics but use gaps to keep from looking too ridiculous.

it was my impression the Blog ended on that note as a likely final solution.

These are far from perfect, but with some little adjustments, like a connection rod, and slight stretching , it might actually work, which is a big relief.

Yeah, "hybrid" method should work.
Actually it is the one #3 - I tried to make it clear "gaps... to reduce stretching", not avoid at all - but the fact English isn't my native, still affects despite all my practice...

The reason why I've created the poll is because many people wrote they don't like the idea in general.
It's a huge problem of mankind, not only internet forums - most people who like everything are staying quiet (even if they're in majority), while unsatisfied minority makes noise and situation look like everything is bad.
So, the goal of poll was to find out real attitude despite vocal minority, and I hope more people will vote to increase accuracy, despite result is quite predictable already. There weren't too much people who voted, but dynamics says most people see Wube's decision is reasonable and will work, and about 1/3 people actually like the idea.

part of the problem is using a Poll to collect data - they don't work, and they provide completely inaccurate data.
the only useful statistical data metrics are polls that also require voters explain why they chose what they chose.

without explaining why you choose something, your choice means nothing.

taiiat wrote:part of the problem is using a Poll to collect data - they don't work, and they provide completely inaccurate data.
the only useful statistical data metrics are polls that also require voters explain why they chose what they chose.

without explaining why you choose something, your choice means nothing.

Feel free to explain your choice here or in FFF comment thread. Actually, personally I've changed my mind after few people have shown a couple sides of the problem I didn't realize.

And I'm not agree data provided is "completely inaccurate" - if someone has nothing new to comment - he/she can simply make a "+" to the position.
E.g., there's not much point to write "I agree with all that mr.A have said, and I don't see any downsides, except of those, described by ms.B. However pros are much more significant than cons, so I chose the same options as mr.A". And such keeping-quiet makes regular forum thread completely out of data.
THAT'S WHY this poll is created. It doesn't pretend to be 100% accurate, but it still will provide somewhat positive information.
If you ask EVERYONE to explain their opinion while voting - how much votes will you manage? 10? 15?

I think there needs to be another option on this poll
0 - Leave it as it is, other features are more important than this.

This whole train equalizing V to H is a complete waste of the devs time, they have already pushed back the fluid tankers, how many more features do you want them to push back?

IMO I would rather see diagonal train-stations before equal V vs H

tehroach wrote:I think there needs to be another option on this poll
0 - Leave it as it is, other features are more important than this.

This whole train equalizing V to H is a complete waste of the devs time, they have already pushed back the fluid tankers, how many more features do you want them to push back?

IMO I would rather see diagonal train-stations before equal V vs H

First of all, Wube is doing great. Factorio is the smoothest early access game I've ever played, and that's because they don't implement features that aren't ready, or can't be ready in time. If they think they don't have enough time to implement fluid wagon - it means there's quite many downsides to be solved.
Talking about fluid wagon, I suppose trains-out-of-grid is one of the downside issues. Properly implemented fluid tanker needs a valve to connect with piping network at the station, and if wagons stop wherever they want, like now - the wagon connection will look really ugly. Do you want Wube to start implementing ugly things? I don't think so.

Second, this poll isn't for finding out in what sequence people want to see new features or issue fixes - this is to find out attitude to solving single specific issue. If you want to make a sequence poll - feel free.

And yes, diagonal stations are important. They are also important in solving exactly this issue, because if they implement them after equalizing trains' length is will result in resolving the issue.

tehroach wrote:I couldn't careless about the North/South and East/West train stations being equal sizes.
Keep them different sizes!

The visual hit and time wasted will be too great a price to pay, for the convenience of merging 2 blueprints into 1.
Which IMO is actually just taking a game choices away from the game. because as it is atm, if I wish to pack more trains into a tighter space I can run them North/South, if loading/unloading times are preferable I run them East/West.

Probably #4 - "simply snap to the grid" is best for your taste ; )

Leave it as it is and you will see that that brave move (doing nothing in that very matter) will by a far shot make more people happy (the won't notice the problem in first place) then the few hard core gamer angry - one (99% of the folks here) can get along with that given wobbly state of loader / station / design as it is today very well.
Spend your precious time on more pressing things -please.

I voted for leaving it as it is, but i also came up with this:

LordHater wrote:How about leaving trains as they are (the gap thing doesn't look cool) and instead create a special inserter-like thing that's a much more efficient version of a regular inserter, but can be used only for trains and only one can be used by a train wagon. This "train unloading station" could have as many tiers as inserters and much bigger size, but still smaller than a train wagon waiting in any direction. Of course regular inserters wouldn't be allowed to transfer items from trains anymore for balance.

That does bring up the interesting point that if loaders are implemented then trains being different sizes H vs V is a non-issue

katyal wrote:That does bring up the interesting point that if loaders are implemented then trains being different sizes H vs V is a non-issue

Honestly, the main problem gameplay-wise is trains are out of grid, resulting in different setups for each wagon for quite-many-wagon train. Also I suspect it makes really ugly-looking tanker wagon connection to pipes and that's the reason tanker held back to 0.14.

Game engine-wise the problem is game has to recalculate train length in different positions as it turns, resulting in extra calculations. If all wagons are same sized - then it's only graphics changing during turn (as it does anyway)

Also loader was never said to rapidly load/unload trains - it was said to be a rapid interface between containers and belts. Usually you will want to unload train in chest(s) to make a buffer while train is on it's way, so loader would be a rapid unloader from buffer, not from train itself (quite the same for loading), thus not really making change in train loading/unloading, because still more inserters = less time on station = higher train throughput.

//Personally I think snapping trains to grid would be just enough. Fixing it's size isn't vital, however I'm looking forward to it.

RobertTerwilliger wrote:Personally I think snapping trains to grid would be just enough. Fixing it's size isn't vital

I would strongly agree with this.
As this would solve most of the perceived problems involving trains, without adding more problems.

tehroach wrote:

RobertTerwilliger wrote:Personally I think snapping trains to grid would be just enough. Fixing it's size isn't vital

I would strongly agree with this.
As this would solve most of the perceived problems involving trains, without adding more problems.

But I still would prefer H = V : )
However I'm not too concerned and will accept anything Wube will do with it, even if they leave it as it is, since problem isn't too bothering, just a bit : )

RobertTerwilliger wrote: But I still would prefer H = V : )
However I'm not too concerned and will accept anything Wube will do with it, even if they leave it as it is, since problem isn't too bothering, just a bit : )

I sign this statement - the whole discussion is overblown.
The matter itself is minor and more academical then bringing robust added real world value to the table of joe-sixpack customer like me if (given needed to be tackled in the future sometimes) mended.
More important would be to focus on the announced and really interesting (network capable) spitter enhancement and similar.
That would do more good then wasting time stirring / seasoning endless a pot which sets its set soup to not that much a more tasting one to the average customer if when left on the stove as it was before - only making a few hardcore specialists happy.