Friday Facts #133 - The train struggle
Re: Friday Facts #133 - The train struggle
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.
Last edited by LordHater on Wed Apr 13, 2016 8:56 am, edited 1 time in total.
-
- Long Handed Inserter
- Posts: 79
- Joined: Sat Mar 05, 2016 2:29 pm
- Contact:
Re: Friday Facts #133 - The train struggle
I personnaly think that both solutions are by far uglier than having different-sized stations.
Re: Friday Facts #133 - The train struggle
While I might consider that to be true, I don't personally mind ugly nearly as much as (mechanically) inconsistent. If I want a shorter station, I'll use a one-cargo-wagon train rather than two, which works for both horizontal and vertical stations. If that's not enough, I might advocate for a shorter cargo wagon variant and/or locomotive so that I could have an even shorter train than is currently possible. Those are mechanically consistent ways of having shorter train stations, and they rightly depend on the train being shorter everywhere, not just magically when traveling vertically.TN_Creator wrote:I personally think that both solutions are by far uglier than having different-sized stations.
But the current method of having shorter vertical and longer horizontal stations breaks my immersion due to being nonsensical in a way that appearance-only imperfections never could. But I know that each person's immersion-breaking or frustration-inducing line is drawn in different places. One way or another, it seems that a lot of people are gonna be at least mildly dissatisfied with whatever solution is implemented. It's only natural that each of us hopes it's not ourselves that land in the dissatisfied camp.
-
- Long Handed Inserter
- Posts: 91
- Joined: Thu Oct 22, 2015 5:08 am
- Contact:
Re: Friday Facts #133 - The train struggle
I want version 13.x (mostly to lay tracks more easily).
Re: Friday Facts #133 - The train struggle
While this is a subjective POV, I would really really like some one to prove it wrong, because I don't think it will ever be proven wrong.TN_Creator wrote:I personally think that both solutions are by far uglier than having different-sized stations.
Because even at its most optimistic outcome it will still be a "Once you see it, it can never be unseen" solution
But as it stands currently it is not mechanically inconsistent, as I can always get 5 inserters a side on a vertical carriage and 7 inserters on a horizontal, hence mechanically the game is sound.againey wrote:While I might consider that to be true, I don't personally mind ugly nearly as much as (mechanically) inconsistent.
-Horizontal is always mechanically consistent with Horizontal
-Vertical is always mechanically consistent with Vertical
You could also say that the purposed change will introduce a mechanical inconsistency, because I have never once seen a train, its carriages or its draw bar grow or shrink while driving around a bend.
I would have to agree with you, that game immersion is in the eye of the beholder.TN_Creator wrote:But the current method of having shorter vertical and longer horizontal stations breaks my immersion due to being nonsensical in a way that appearance-only imperfections never could. But I know that each person's immersion-breaking or frustration-inducing line is drawn in different places. One way or another, it seems that a lot of people are gonna be at least mildly dissatisfied with whatever solution is implemented. It's only natural that each of us hopes it's not ourselves that land in the dissatisfied camp.
For me your problem extends from a legacy choice and as a budding computer scientist I have to deal with legacy problems on a daily basis.
Hence they simply don't bother me and I learn to use them to my advantage.
However when I was learning OpenGL and I had to view mine and my peers projects,
there would often be shrinking and stretching, which is quite a common N008 mistake, because the maths related to perspective is quite daunting at first.
This n008 mistake while functional (sometime nauseating), it simply cheapens the overall feel of the product and hence these projects often scored a lower mark than other projects; even when the underlying structure was vastly superior.
It simply doesn't make sense to mathematically implement this n008 mistake intentionally, especially when the perceived problem could and would be written off as just a simple early design choice.
IMO the only true way to "fix" your problem and at the same time NOT introduce a completely new and just as bad a problem (probably worse because we live in the age of graphics, NOT the 80's),
is for the Devs to walk two paths at the same time and create the "fix" (and just introduction a different problem) and implement it as a map start-up option so each individual player can decide, which "evil" they want to play with either;
0 - Different sized V vs H train-stations. /w natural looking graphics, or
0 - Equal V vs H train-stations /w N008 looking graphics
Re: Friday Facts #133 - The train struggle
Although in general I welcome the freedom of choice I don't really think that having two slightly less different Factorio games being supported and developed at the same time is a good idea. It would just split up the community. You would have mods working on one version and not the other, you would have project books working on one version and not the other, you would have 2 multiplayer portal working on one of the versions, etc etc...tehroach wrote: is for the Devs to walk two paths at the same time and create the "fix" (and just introduction a different problem) and implement it as a map start-up option so each individual player can decide, which "evil" they want to play with either;
0 - Different sized V vs H train-stations. /w natural looking graphics, or
0 - Equal V vs H train-stations /w N008 looking graphics
Re: Friday Facts #133 - The train struggle
Hi
I'm pretty new to Factorio, so this is my perspective on this as a new player.
The train fix is much better then what we have now!
I wasted a few hours understanding WTF is wrong with my train stations as I was rotating my blueprint.
And even before I encountered the vertical/horizontal problem I got confused by the different wagons lengths and figuring out to which wagon the loader I put "in front of the gap" is loading to...
That said the vertical/horizontal problem is pretty annoying regardless of trains, I took me a good while to realize that the rectangular Assembling machines are actually "square"
I'm pretty new to Factorio, so this is my perspective on this as a new player.
The train fix is much better then what we have now!
I wasted a few hours understanding WTF is wrong with my train stations as I was rotating my blueprint.
And even before I encountered the vertical/horizontal problem I got confused by the different wagons lengths and figuring out to which wagon the loader I put "in front of the gap" is loading to...
That said the vertical/horizontal problem is pretty annoying regardless of trains, I took me a good while to realize that the rectangular Assembling machines are actually "square"
Re: Friday Facts #133 - The train struggle
In what ways would it affect mods?malecord wrote:Although in general I welcome the freedom of choice I don't really think that having two slightly less different Factorio games being supported and developed at the same time is a good idea. It would just split up the community. You would have mods working on one version and not the other, you would have project books working on one version and not the other, you would have 2 multiplayer portal working on one of the versions, etc etc...tehroach wrote: is for the Devs to walk two paths at the same time and create the "fix" (and just introduction a different problem) and implement it as a map start-up option so each individual player can decide, which "evil" they want to play with either;
0 - Different sized V vs H train-stations. /w natural looking graphics, or
0 - Equal V vs H train-stations /w N008 looking graphics
Project books are as big a deal as blueprints, simply state its intended orientation.
Why would you need 2 multiplayer portals if it was a map option?
If these are such big issues, then the simplest option is to just scrap the change.
or
Instead of equalizing V to H and trying to squeeze extra space into the V stations why not simply reduce the hit box size and reduce the number of inserters allowed on the Horizontal station, as this too would solve all the OCD problems and all stations would be equal.
-
- Fast Inserter
- Posts: 196
- Joined: Wed Nov 18, 2015 10:12 am
- Contact:
Re: Friday Facts #133 - The train struggle
Agree, the issue with those sizes hits me every new game - after using blueprints for a while you may forget how to do it manually, before having blueprint.ili wrote:Hi
I'm pretty new to Factorio, so this is my perspective on this as a new player.
The train fix is much better then what we have now!
I wasted a few hours understanding WTF is wrong with my train stations as I was rotating my blueprint.
And even before I encountered the vertical/horizontal problem I got confused by the different wagons lengths and figuring out to which wagon the loader I put "in front of the gap" is loading to...
That said the vertical/horizontal problem is pretty annoying regardless of trains, I took me a good while to realize that the rectangular Assembling machines are actually "square"
But with all other entities (including assemblers) it's much easier, because they have a border highlighted when you hover them (a proper one, not like trains have))
Holding formation further and further,
Millions of lamb stay in embrace of Judas.
They just need some bread and faith in themselves,
BUT THE TSAR IS GIVEN TO THEM IN EXCHANGE!
Original: 5diez - "Ищу, теряя" (rus, 2013)
Millions of lamb stay in embrace of Judas.
They just need some bread and faith in themselves,
BUT THE TSAR IS GIVEN TO THEM IN EXCHANGE!
Original: 5diez - "Ищу, теряя" (rus, 2013)
Re: Friday Facts #133 - The train struggle
I too have a similar problem to this in a new game, but I don't see how equalizing the train stations will help any,RobertTerwilliger wrote:Agree, the issue with those sizes hits me every new game - after using blueprints for a while you may forget how to do it manually, before having blueprint.ili wrote:Hi
I'm pretty new to Factorio, so this is my perspective on this as a new player.
The train fix is much better then what we have now!
I wasted a few hours understanding WTF is wrong with my train stations as I was rotating my blueprint.
And even before I encountered the vertical/horizontal problem I got confused by the different wagons lengths and figuring out to which wagon the loader I put "in front of the gap" is loading to...
That said the vertical/horizontal problem is pretty annoying regardless of trains, I took me a good while to realize that the rectangular Assembling machines are actually "square"
But with all other entities (including assemblers) it's much easier, because they have a border highlighted when you hover them (a proper one, not like trains have))
Usually I just bring a train (in my pocket) when ever I am setting up a station and this solves any uncertainty issues with inserter placement.
However I do see your point and agree that something could be done to make things easier,
but maybe the solution lies in equalizing the lengths of the train car and the wagons, then if you moused over the station it could highlight the positions next to the track that would correspond to where each component of a train would be that stopped there.
Re: Friday Facts #133 - The train struggle
Well what your propose is to have 2 separated games where one has "stretched graphics" but "realistic object positioning" and the other with "good graphics" but nonsensical object positioning (current one). Playing on one or another significantly changes your experience: both visually and on how the game plays (how you organize your factory).tehroach wrote:In what ways would it affect mods?malecord wrote:Although in general I welcome the freedom of choice I don't really think that having two slightly less different Factorio games being supported and developed at the same time is a good idea. It would just split up the community. You would have mods working on one version and not the other, you would have project books working on one version and not the other, you would have 2 multiplayer portal working on one of the versions, etc etc...tehroach wrote: is for the Devs to walk two paths at the same time and create the "fix" (and just introduction a different problem) and implement it as a map start-up option so each individual player can decide, which "evil" they want to play with either;
0 - Different sized V vs H train-stations. /w natural looking graphics, or
0 - Equal V vs H train-stations /w N008 looking graphics
Project books are as big a deal as blueprints, simply state its intended orientation.
Why would you need 2 multiplayer portals if it was a map option?
If these are such big issues, then the simplest option is to just scrap the change.
or
Instead of equalizing V to H and trying to squeeze extra space into the V stations why not simply reduce the hit box size and reduce the number of inserters allowed on the Horizontal station, as this too would solve all the OCD problems and all stations would be equal.
People would necessarily choose a flag and then fanboy wars would likely start ("the true factorio purist is the one playing with bad graphics and realistic grid!" "no, the true purist is the one plying the orthodoxical version with the vertical/horizontal nonsense!"). It doesn't matter if the portal is the same the community would inevitably split even without starting a feud on the purity.
As for blueprints books and mods it's the same principle. Instead of having a single rich pool of stuff you would have 2 lesser pools which would likely be less than the sum of the two. Why bothering creating a book for the version I don't play? Why create an airplane for the version I don't play? Etc etc.
-
- Inserter
- Posts: 40
- Joined: Fri Apr 15, 2016 11:09 am
- Contact:
Re: Friday Facts #133 - The train struggle
To solve the train struggle, the game logic should consider logical tile in 1:1 format, while the graphic engine should consider graphical tile 1:1.41. Juste draw from top to bottom so taht the 0.41 part is drawn on top of the northern tile! (and blit from low left corner of tile to up right corner, the low left corner of the graphical tile is always on the lower left corner of the logical tile!)
Re: Friday Facts #133 - The train struggle
after trying to find my own solution (which would be snapping train size to grids and have a specified loading hitbox which can accommodate the same number of inserters in h and v orientation), and reading all the other ideas and opinions on the train length problem, i also came to the conclusion, that it is better not to sink time in the train length problem at all. leave it as it is, except for redoing the game engine completely and use proper perspective and tile size, everything else will look wrong, depending on the viewers idea of how it should look. yes, it is a design flaw. swallow your pride and live with it. (no offense, it is something i tell myself a lot at times when i see i made a mistake)
i know you cant hear it anymore from me:
imo invest more time to vastly extend the possibilities of the modding api, and you will get all sort of cool shit into the game by happy modders. - to stress a bit more on the modding issue: imo invest a lot more time on making generic features accessible through the modding api. eg, the stack belt inserter/heavy loader would have long be done by a modder, if you had provided the generic features to make it possible. while we are at this particular thing, the stack belt inserter/heavy loader, i want to show you what i mean by extending the modding api with generic features: now you created some sort of new entity, but most of its functionality will - i assume - be not accessible via the modding api. mods can place that entity into the game world, yes, but the functionality of grabbing a stack of size X with a modded entity, dropping off Y units of that stack some where, using an interval of S ticks between drops will not be accessible through the modding api - i assume.
my approach to implementing all the game features would be - improve the modding api by adding generic(NOT specific features) so far, that you (the devs) can implement this new game entity by just using the modding api. banzai! that would open possibilities unknown!
anyways, it is a great game. keep it up! i do not need a new logistics game for the next 10 years. except for something a bit more challenging and exciting in the long run. ... i played this game for some 10 hours, then i understood the game concepts. then i worked with the circuit network. then i had a look at the modding api, which was a bit frustrating, because it is very limited. now i miss the challenge. optimization, the next/bigger train staition layout and biters and spitters attacking laser turrets is not enough.
i got it - you need a new core game concept: the shifting challenge. - it is perfect for the audience of this game. mostly players who want to figure good or perfect solution to problems. lets talk about this on the other forum.
i know you cant hear it anymore from me:
imo invest more time to vastly extend the possibilities of the modding api, and you will get all sort of cool shit into the game by happy modders. - to stress a bit more on the modding issue: imo invest a lot more time on making generic features accessible through the modding api. eg, the stack belt inserter/heavy loader would have long be done by a modder, if you had provided the generic features to make it possible. while we are at this particular thing, the stack belt inserter/heavy loader, i want to show you what i mean by extending the modding api with generic features: now you created some sort of new entity, but most of its functionality will - i assume - be not accessible via the modding api. mods can place that entity into the game world, yes, but the functionality of grabbing a stack of size X with a modded entity, dropping off Y units of that stack some where, using an interval of S ticks between drops will not be accessible through the modding api - i assume.
my approach to implementing all the game features would be - improve the modding api by adding generic(NOT specific features) so far, that you (the devs) can implement this new game entity by just using the modding api. banzai! that would open possibilities unknown!
anyways, it is a great game. keep it up! i do not need a new logistics game for the next 10 years. except for something a bit more challenging and exciting in the long run. ... i played this game for some 10 hours, then i understood the game concepts. then i worked with the circuit network. then i had a look at the modding api, which was a bit frustrating, because it is very limited. now i miss the challenge. optimization, the next/bigger train staition layout and biters and spitters attacking laser turrets is not enough.
i got it - you need a new core game concept: the shifting challenge. - it is perfect for the audience of this game. mostly players who want to figure good or perfect solution to problems. lets talk about this on the other forum.
-
- Filter Inserter
- Posts: 952
- Joined: Sat May 23, 2015 12:10 pm
- Contact:
Re: Friday Facts #133 - The train struggle
I've made that exact argument before: viewtopic.php?f=28&t=15257Impatient wrote: i know you cant hear it anymore from me:
imo invest more time to vastly extend the possibilities of the modding api, and you will get all sort of cool shit into the game by happy modders. - to stress a bit more on the modding issue: imo invest a lot more time on making generic features accessible through the modding api. eg, the stack belt inserter/heavy loader would have long be done by a modder, if you had provided the generic features to make it possible. while we are at this particular thing, the stack belt inserter/heavy loader, i want to show you what i mean by extending the modding api with generic features: now you created some sort of new entity, but most of its functionality will - i assume - be not accessible via the modding api. mods can place that entity into the game world, yes, but the functionality of grabbing a stack of size X with a modded entity, dropping off Y units of that stack some where, using an interval of S ticks between drops will not be accessible through the modding api - i assume.
my approach to implementing all the game features would be - improve the modding api by adding generic(NOT specific features) so far, that you (the devs) can implement this new game entity by just using the modding api. banzai! that would open possibilities unknown!
Re: Friday Facts #133 - The train struggle
viewtopic.php?f=25&t=23211&p=145537#p145511 That's just not how any of this works in the real world.ratchetfreak wrote:I've made that exact argument before: viewtopic.php?f=28&t=15257Impatient wrote: i know you cant hear it anymore from me:
imo invest more time to vastly extend the possibilities of the modding api, and you will get all sort of cool shit into the game by happy modders. - to stress a bit more on the modding issue: imo invest a lot more time on making generic features accessible through the modding api. eg, the stack belt inserter/heavy loader would have long be done by a modder, if you had provided the generic features to make it possible. while we are at this particular thing, the stack belt inserter/heavy loader, i want to show you what i mean by extending the modding api with generic features: now you created some sort of new entity, but most of its functionality will - i assume - be not accessible via the modding api. mods can place that entity into the game world, yes, but the functionality of grabbing a stack of size X with a modded entity, dropping off Y units of that stack some where, using an interval of S ticks between drops will not be accessible through the modding api - i assume.
my approach to implementing all the game features would be - improve the modding api by adding generic(NOT specific features) so far, that you (the devs) can implement this new game entity by just using the modding api. banzai! that would open possibilities unknown!
If you want to get ahold of me I'm almost always on Discord.
-
- Filter Inserter
- Posts: 952
- Joined: Sat May 23, 2015 12:10 pm
- Contact:
Re: Friday Facts #133 - The train struggle
You mean it's not how it works in factorio.Rseding91 wrote:
viewtopic.php?f=25&t=23211&p=145537#p145511 That's just not how any of this works in the real world.
There should be nothing stopping you from adding support for it to the modding api, even if you do the true heavy lifting of the vanilla entity in C++.
For example by creating a "modded_entity" prototype that is highly flexible with what it can do while keeping the less flexible existing entities for performance.
There are also several niceties that are simply missing, like luaEntity::get_circuit_input(connector) and luaEntity::set_circuit_output(connector,ConstantCombinatorParameters). The last one would only be accessible when the connector is defined to be a moddable output.
Re: Friday Facts #133 - The train struggle
@Rseding91: I see. (I did not see your answer before). Ok, i am a bit sad now.Rseding91 wrote: viewtopic.php?f=25&t=23211&p=145537#p145511 That's just not how any of this works in the real world.
Last edited by Impatient on Fri Apr 15, 2016 4:37 pm, edited 1 time in total.
Re: Friday Facts #133 - The train struggle
This really only answers one of my above three questions and with speculation at best.malecord wrote:Well what your propose is to have 2 separated games where one has "stretched graphics" but "realistic object positioning" and the other with "good graphics" but nonsensical object positioning (current one). Playing on one or another significantly changes your experience: both visually and on how the game plays (how you organize your factory).tehroach wrote:In what ways would it affect mods?malecord wrote:Although in general I welcome the freedom of choice I don't really think that having two slightly less different Factorio games being supported and developed at the same time is a good idea. It would just split up the community. You would have mods working on one version and not the other, you would have project books working on one version and not the other, you would have 2 multiplayer portal working on one of the versions, etc etc...tehroach wrote: is for the Devs to walk two paths at the same time and create the "fix" (and just introduction a different problem) and implement it as a map start-up option so each individual player can decide, which "evil" they want to play with either;
0 - Different sized V vs H train-stations. /w natural looking graphics, or
0 - Equal V vs H train-stations /w N008 looking graphics
Project books are as big a deal as blueprints, simply state its intended orientation.
Why would you need 2 multiplayer portals if it was a map option?
If these are such big issues, then the simplest option is to just scrap the change.
or
Instead of equalizing V to H and trying to squeeze extra space into the V stations why not simply reduce the hit box size and reduce the number of inserters allowed on the Horizontal station, as this too would solve all the OCD problems and all stations would be equal.
People would necessarily choose a flag and then fanboy wars would likely start ("the true factorio purist is the one playing with bad graphics and realistic grid!" "no, the true purist is the one plying the orthodoxical version with the vertical/horizontal nonsense!"). It doesn't matter if the portal is the same the community would inevitably split even without starting a feud on the purity.
As for blueprints books and mods it's the same principle. Instead of having a single rich pool of stuff you would have 2 lesser pools which would likely be less than the sum of the two. Why bothering creating a book for the version I don't play? Why create an airplane for the version I don't play? Etc etc.
Where do you get the idea that it would create two separate games from?
Is someone who plays Factorio with a mod installed, NOT playing Factorio?
How would the two parts magically become lesser?
Why would the book and the Airplane need to be different?
How solid is the community to begin with, I already can not play with my friends if they are in a different country to me, due to network lag, so would this "split" you mention really make a difference?
Re: Friday Facts #133 - The train struggle
I think the multiple item on inserter thing should be like the stack size upgrade, or a seperate belt stack size upgrade, and when picking up items, have options like:
pick up extra item if time to do so < x
pick x items per time(x would obviousely have a max)
sorry for the bad english
pick up extra item if time to do so < x
pick x items per time(x would obviousely have a max)
sorry for the bad english
Re: Friday Facts #133 - The train struggle
Part of the problem we are having in visualizing the train problem is because the cars overlap their squares when horizontal, but not vertical. No entity should overlap to the left or right, but anything with height should overlap what's behind (above) it. This is currently done for some objects but not most. Train stops and power poles come to mind. Looking at the images in the OP, you can tell that the vertical car fits exactly within the 2x6 area, but the horizontal one is bigger. If the vertical car was drawn so that it overlapped the square above it, the huge gap would disappear.
The other part of the problem is that when rotating an object, our brains expect it to appear shorter when it's pointing away from us. So the car is not stretching at all, rather, it only appears to be. And I don't think there's any way to fix that, other than changing the game engine to isometric or true 3d. But we've already said that would be impossible.
The other part of the problem is that when rotating an object, our brains expect it to appear shorter when it's pointing away from us. So the car is not stretching at all, rather, it only appears to be. And I don't think there's any way to fix that, other than changing the game engine to isometric or true 3d. But we've already said that would be impossible.