Factorio Forums

kovarex wrote:

ratchetfreak wrote:Here is a radical idea, if you changed the grid spacing to something a bit wider than high (even if only in a 1.2 ratio) then the train stretch won't be that noticeable. You can even keep most of the artwork; just let the buildings extend above the 2x2 spot it occupies.

The only problem then is that "high" buildings will block the view of the row of tiles behind them.

That would mean redoing most of the factorio graphics, like rails, transport belts, terrain, most of the buildings, pipes etc.

Not really most buildings that are 2x2 are actually 1.5 in the vertical with the rest being taken up by the height of the building.

belts and rails can probably be scaled and still look good.

Guys, I think pretty much all of us can live with the train issue now. Even though I must admit had a headhache the first time I used blueprints for stations and it took me a while to understand that the problem wasn't mine.

The question is: would Factorio be a better game if dimensions were handled correctly?

I think yes: good thing the devs handle it.

The ideal solution would be to change the perspective or use a true grid and 3d graphics. But this would mean to rewrite the game from scratch and/or tap resources that a small indie studio doesn't have. So I say yes to at least have the train work around (or "pork around", as we call this kind of stuff at my office ).

malecord wrote:The ideal solution would be to change the perspective or use a true grid and 3d graphics. But this would mean to rewrite the game from scratch and/or tap resources that a small indie studio doesn't have. So I say yes to at least have the train work around

That's probably for "Factorio 2: Biters' Revenge" (~_^)

malecord wrote:Guys, I think pretty much all of us can live with the train issue now. Even though I must admit had a headhache the first time I used blueprints for stations and it took me a while to understand that the problem wasn't mine.

That's the reason: we all have passed this headache and devs just want finally to eliminate it, because much more people are involved in playing, so total headache is bigger...

Why we love Wube is because they thoroughly fix even tiniest issues.

malecord wrote:The ideal solution would be to change the perspective or use a true grid and 3d graphics. But this would mean to rewrite the game from scratch

It shouldn't.
Only display part and human input part (like mouse-click).
All game-logic, calculating optimization, data-structure, etc. should remain mostly intact. And that's the best part.

LazyLoneLion wrote:

malecord wrote:The ideal solution would be to change the perspective or use a true grid and 3d graphics. But this would mean to rewrite the game from scratch

It shouldn't.
Only display part and human input part (like mouse-click).
All game-logic, calculating optimization, data-structure, etc. should remain mostly intact. And that's the best part.

When this sort of thing comes up I am reminded of how Dwarf Fortress went from 2d to 3d from one revision to the next. Not in graphics, either, but in the structure of the world itself. Makes me wish I could compare the source code between those versions.

But yes, ideally, in any game project there should be total separation between content and presentation such that making Factorio's graphics fully 3d game should require only recoding the display functions and making the models, and no changes to the game logic at all. In practice, nobody has time for that kind of strictness for the sake of potential future refactoring when there's 100 bugs that need to be squished, not counting the new one's you'll create in doing so.

Hey love the game, truly awesome work!

Got all my buddies to buy it, playing together now, so much fun!

I have a few suggestions to some of the problems above.

With the uneven train lengths because of the isometric view, maybe add a station, like how they unload coal trucks in real live, tipping the cargo over in a container and unload the container. at least then you could maybe even out the structure size.

and the "Heavy Loader" idea isn't bad, but i cant help to think that it messes with the nature of the insertions. i could suggest a Box Belt, a belt type with the capacity of a small chest and the offloading ability sort of like the Spliter where it will drain its over head box on to the belt splitting between the left and the right side. excepting input in the chest and the belt coming from the rear. atleast it's also a upgradable solution.

Just my thoughts

GoliathMrk1 wrote:and the "Heavy Loader" idea isn't bad, but i cant help to think that it messes with the nature of the insertions. i could suggest a Box Belt, a belt type with the capacity of a small chest and the offloading ability sort of like the Spliter where it will drain its over head box on to the belt splitting between the left and the right side. excepting input in the chest and the belt coming from the rear. atleast it's also a upgradable solution.

I like that thought. Instead of adding another inserter variant, add a chest/belt variant. I couldn't follow the exact layout details you were describing, though. I'm imagining a chest with an input on one side, and output on the opposite side, and nothing on the other two sides.

And if for some reason you really need to use a specific chest type (larger steel chest, or one of the logistic chests), then you can use the following chains:

From belt to chest: belt -> belt chest -> fast/smart inserter -> large/logistic chest
From chest to belt: large/logistic chest -> fast/smart inserter -> belt chest -> belt

Since the inserter would be able to take advantage of the stack size upgrade in this case, it benefits in a fashion similar to that of the proposed heavy inserter.

I suppose in the odd case that you have a belt -> belt chest -> belt, it'd essentially act as a normal belt, though perhaps with a small delay, and the ability to inserters on the sides pulling out the items momentarily in the chest, or putting items into the chest, merging with anything passing through.

Edit: Added a more detailed post to the loader poll thread here, with a mockup image.

GoliathMrk1 wrote:"Heavy Loader" idea isn't bad, but i cant help to think that it messes with the nature of the insertions.

Small graphics edit for inserter's hand and it will look great : )
Kinda grabbing tool with multi-layer carrying slot, or magnetic hand like in scrap yard, however there're quite many non-magnetic items in the game.

kovarex wrote:

vedrit wrote:I'm curious to see how the heavy inserter behaves when picking items off the belt. Is it going to wait until it has the maximum items, or a period of time? Will it be able to do an AoE grab, per se? It's nice that it'll grab a bunch of items and put them down real nice and fast like. That's cool.

Yes, there are few ways to do it, it would probably try to grab things from the belt as long as there are more of the same item already in hand until it reaches the stack size limit.

How about having GUI for heavy inserter with a switch:
- grab items until hand is full
- grab only items currently on belt (i.e. if there's, say, 2 items passing by inserter - it'll grab 2, if the belt is full - it'll grab maximum)

the train thing is a useless timesink, no matter what you come up with, it will look wrong.

i would prefer a 4x1 Loader i can slab onto my factorys etc. instead of a heavy inserter tbh.
a better inserter adds no gameplayvalue whatsoever.

as i see it a 4x1 Loader would have 1 tile with lights and antennas(controlstationthing) and 3tiles with a slightly slanted back that fits onto a factory and a exit/input in the forntmiddle(also slanted so that back and front look decent when connected to chests).
actually i would like them in all 3 belt-tiers as high cost alternatives to inserters.
just realized with 3 chests in the back and 1chest infront, there is no way to tell if its supposed to input or output....
maybe need seperate Loaders and Unloaders(just a mirrored Loader).

point is, we have no use for more inserters, more ores, more assamblers, more bots, etc. mods allready get you more of the same if you want it. to expand the core game, a little twist on the new thing is needed.

Venatos wrote:the train thing is a useless timesink, no matter what you come up with, it will look wrong.

i would prefer a 4x1 Loader i can slab onto my factorys etc. instead of a heavy inserter tbh.
a better inserter adds no gameplayvalue whatsoever.

as i see it a 4x1 Loader would have 1 tile with lights and antennas(controlstationthing) and 3tiles with a slightly slanted back that fits onto a factory and a exit/input in the forntmiddle(also slanted so that back and front look decent when connected to chests).
actually i would like them in all 3 belt-tiers as high cost alternatives to inserters.
just realized with 3 chests in the back and 1chest infront, there is no way to tell if its supposed to input or output....
maybe need seperate Loaders and Unloaders(just a mirrored Loader).

point is, we have no use for more inserters, more ores, more assamblers, more bots, etc. mods allready get you more of the same if you want it. to expand the core game, a little twist on the new thing is needed.

There is one solution that won't look wrong: changing the tile sizes

Leaving a gap of half an item between items for the heavy inserters seems like a good balance. Absolutely to preserve interesting optimisation problems and really add to the richness of all the options.

alan2here wrote:Leaving a gap of half an item between items for the heavy inserters seems like a good balance. Absolutely to preserve interesting optimisation problems and really add to the richness of all the options.

No. That is just annoying, stop trying to nerf everything better than your normal inserters.

Zeblote wrote:

alan2here wrote:Leaving a gap of half an item between items for the heavy inserters seems like a good balance. Absolutely to preserve interesting optimisation problems and really add to the richness of all the options.

No. That is just annoying, stop trying to nerf everything better than your normal inserters.

as is you'll need multiple heavy inserters to fill a belt. Making the heavy inserter not output fully compressed is not a big deal. It just means that you need a compressor setup (2 belts merging through a splitter) to get max throughput.

ratchetfreak wrote:

Zeblote wrote:

alan2here wrote:Leaving a gap of half an item between items for the heavy inserters seems like a good balance. Absolutely to preserve interesting optimisation problems and really add to the richness of all the options.

No. That is just annoying, stop trying to nerf everything better than your normal inserters.

as is you'll need multiple heavy inserters to fill a belt. Making the heavy inserter not output fully compressed is not a big deal. It just means that you need a compressor setup (2 belts merging through a splitter) to get max throughput.

Well, it's even easier to compress if your belt is yellow or red - simply unload to blue one.
The fact is any decrease will indeed be just annoying - we will get an entity that doesn't do it's jop to the end and we will have to finish it each time exactly in the same way, thus not providing any challenge or puzzle at all, rather boring buisy work.
And yes, we will need multiple inserters because one will leave gaps while turning back and forth. However if it won't leave gaps - it will feel much smoother.

//I wonder if heavy inserter will be gated by "Inserter stack size" tech? Not that important at the moment, just curiosity : )

The 1 gap vertical/horizontal gap proposed in the blog post is excellent. Might I suggest shrinking the horizontal graphics to have the same one grid space "air" gap as vertical? Then adding train linkage to fill the gap. Finally expand/shrink that linkage to maintain alignment on the grid. This would fix the odd empty space that looks like disconnected rail-cars when they are vertical like the blog shows. While also adding a possible way in the future to make it possible to interact with the linkage to dynamically connect/disconnect rail-cars.

AssaultRaven wrote: When this sort of thing comes up I am reminded of how Dwarf Fortress went from 2d to 3d from one revision to the next. Not in graphics, either, but in the structure of the world itself. Makes me wish I could compare the source code between those versions.

Sorry, I can't help myself:

1) What you call "one revision" in DF takes 1-2 years
2) DF didn't change the graphics, just the maps and co-ordinates, and not much of the simulation logic. The result is a game in which (a) the gameplay is horrible any time that 3d means more than multiple 2d levels; e.g. a battle occurring on a hillside is almost impossible to follow because you only see 1 level at the time, and if an enermy army is approaching on a level you're not looking at your SOL; (b) where hauling a boulder up 1 flight of stairs takes the same time as moving 1 tile horizontally, so optimal design generally means spreading an acitivity over multiple z-levels. I live on the 5th storey without an elevator, and I can safely tell you that this is not realistic . I think the factorio devs are right that everything should happen in a single visible plane (although the old simcity (2?) model with a very limited underground layer was quite acceptable)
3) In theory and given enough resources, team A should be able to work on the graphics engine while team B works on the simulation logic, but as they say the difference between theory and practice is that in theory there is no difference; real-life code is not as neatly separated as you would wish, and enough resources are never avaiable. Civilization went from square 2d to isometric to actual rendered square 3d to actual rendered hex 3d... over a time span of 25 years and 5 major versions which I'm sure were all complete rewrites. As much as I'd love to see factorio switch engines, this will probably mean a year of effort in which nothing much else happens, and I'm sure we all have some other things that we think warrants dev time

</rant>

These changes are fine, but I wonder why they don't take the "low-hanging fruit" first on trains: namely, cargo trains should hold at least as much as a steel chest! That would be a 5 minute change and they've already talked about it. Possibly for compensatory balance, each cargo train could weigh a bit more.

Venatos wrote:the train thing is a useless timesink, no matter what you come up with, it will look wrong.

I must agree strongly with this!

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.

I think you need a poll on this subject.

Something like:
0 - Yes, please waste the devs time on this and make the trains look crap, while pushing back other features
0 - Just get the trains to stop always aligned with the grid
0 - It is fine just as it is
0 - Don't use trains, Don't care!

Yes my opinion is bias, hence the reason why I believe that someone else who isn't bias needs to create the poll.

gilesc wrote:These changes are fine, but I wonder why they don't take the "low-hanging fruit" first on trains: namely, cargo trains should hold at least as much as a steel chest! That would be a 5 minute change and they've already talked about it.

I don't know if this is really "low-hanging fruit"

Maybe an extra row might not be bad, but making the train carriages hold as much as steel chests IMO would be a bad idea,
as it is I don't find too many uses for trains with more than 2 carriages and this would make multiple carriage trains even less viable

gilesc wrote:Possibly for compensatory balance, each cargo train could weigh a bit more.

The lose of speed would just end up as a nerf for trains in the face of robots

Speaking again about train length, please, don't forget to make them also fit in grid diagonally, and probably on turns, because some people just like diagonal stations.

tehroach wrote:I would rather see diagonal train-stations before equal V vs H

has sense, because after implementing diagonal stations trains-out-of-grid issue may reappear