Factorio Forums

I don't see this as ever happening. Electric poles don't have a saved direction and there's zero gameplay benefit to make them have one. It would increase memory usage, save file size, save time, and load time. All for a purely cosmetic reason.

Rseding91 wrote: Fri Feb 21, 2020 12:53 pm I don't see this as ever happening. Electric poles don't have a saved direction and there's zero gameplay benefit to make them have one. It would increase memory usage, save file size, save time, and load time. All for a purely cosmetic reason.

I am so happy, that decoratives are already in the game as they exactly match that description.

Rseding91 wrote: Fri Feb 21, 2020 12:53 pm Electric poles don't have a saved direction

So give them a saved direction. Or give me an NDA and source access and I'll do it then send you an invoice.

and there's zero gameplay benefit to make them have one. ... a purely cosmetic reason.

Yeah... that's true, but, and I only speak for myself, that kind of cosmetic stuff is an enjoyable part of the game for me. When I look at reddit and these forums I see a lot of players putting a lot of effort into things that are, for the most part, cosmetic, especially in the way factories and belts are arranged, and I think fixing this particular thing (electric pole orientation) has a lot of value in that respect. But I get that it's not of high importance.

Would be nice, though.

Rseding91 wrote: Fri Feb 21, 2020 12:53 pmIt would increase memory usage, save file size, save time, and load time

Could the impact here be reduced to acceptable levels by only saving orientation state for poles whose orientation has been manually set by the user?

JasonC wrote: Fri Feb 21, 2020 3:50 pm

Rseding91 wrote: Fri Feb 21, 2020 12:53 pmIt would increase memory usage, save file size, save time, and load time

Could the impact here be reduced to acceptable levels by only saving orientation state for poles whose orientation has been manually set by the user?

Serialization doesn't work that way. You can't conditionally not load something without having something to load that says if you should or shouldn't load more.

Rseding91 wrote: Fri Feb 21, 2020 12:53 pm I don't see this as ever happening. Electric poles don't have a saved direction and there's zero gameplay benefit to make them have one. It would increase memory usage, save file size, save time, and load time. All for a purely cosmetic reason.

From looking at this thread from afar... isn't this simply about the prototype wire connection points? If for all directions the red connection point is on the "left" and the green on the "right" the wires should never cross should they?

Rseding91 wrote: Fri Feb 21, 2020 3:55 pm

JasonC wrote: Fri Feb 21, 2020 3:50 pm

Rseding91 wrote: Fri Feb 21, 2020 12:53 pmIt would increase memory usage, save file size, save time, and load time

Could the impact here be reduced to acceptable levels by only saving orientation state for poles whose orientation has been manually set by the user?

Serialization doesn't work that way. You can't conditionally not load something without having something to load that says if you should or shouldn't load more.

I know; but I can also conceive of logic that treats user-rotated poles almost like separate entities, so you don't have to mix them in with automatic poles - [de]serializing manual ones as a separate collection from non-manual ones. But I also understand that the game might not have the architecture to do something like that, or that the effort to add it outweighs the benefit, or that it could add a whole host of possible new bugs.

Is something like that a possibility, though?

eradicator wrote: Fri Feb 21, 2020 3:55 pm

Rseding91 wrote: Fri Feb 21, 2020 12:53 pm I don't see this as ever happening. Electric poles don't have a saved direction and there's zero gameplay benefit to make them have one. It would increase memory usage, save file size, save time, and load time. All for a purely cosmetic reason.

From looking at this thread from afar... isn't this simply about the prototype wire connection points? If for all directions the red connection point is on the "left" and the green on the "right" the wires should never cross should they?

By your own definition Rseding, poles should only have one predefined way of connecting wires. e.g. bottom left green, center copper, top right red
The current way of somewhat randomly rotating connections is only cosmetic, requires additional sprites to be loaded and therefore should be removed.

eradicator wrote: Fri Feb 21, 2020 3:55 pm

Rseding91 wrote: Fri Feb 21, 2020 12:53 pm I don't see this as ever happening. Electric poles don't have a saved direction and there's zero gameplay benefit to make them have one. It would increase memory usage, save file size, save time, and load time. All for a purely cosmetic reason.

From looking at this thread from afar... isn't this simply about the prototype wire connection points? If for all directions the red connection point is on the "left" and the green on the "right" the wires should never cross should they?

Well, "bottom left" and "top right" (or whatever) for thoroughness; but for something like that I can always imagine edge cases where wires, while not necessarily crossing, obscure eachother because they're all on the same line; especially in setups that mix diagonal and orthogonal wires.

PS, Fwiw, regarding performance impacts, I personally don't mind increases in save file size. They're already not that big and storage space is virtually a non-issue these days. Same with memory usage, within reason. Save/load times, though, is something I care about (although right now they're more than acceptable but I also have a brand new machine with a pair of RAID-1 NVMe SSDs, 16 i9s, and a ton of PCIe bandwidth, and I'm pretty sure I/O and file size aren't the bottleneck in save/load, but I don't know about the [un]zipping).

eradicator wrote: Fri Feb 21, 2020 3:55 pm From looking at this thread from afar... isn't this simply about the prototype wire connection points? If for all directions the red connection point is on the "left" and the green on the "right" the wires should never cross should they?

So, i did my homework now and noticed that the existance of two different diagonal variants seems to make this impossible. (Disclaimer: I really don't want to take sides in another "OCD" vs "a bit of chaos looks nice" discussion so i'm posting this simply "as is".)

After fixing some errors it looks like swapping the attachment rules for only one of the diagonal variants seems to work.

Wait … these are only for two poles placed horizontally. How about placing poles vertically? This problem should not have full rotational symmetry.

valneq wrote: Fri Feb 21, 2020 5:12 pm Wait … these are only for two poles placed horizontally. How about placing poles vertically? This problem should not have full rotational symmetry.

Yep. Exactly. *sigh*. That was my first thought, then i did some half-assed testing and it seemed it worked. Now i did some more testing and back to: "For any pair of poles with non-identical rotation there exists two positions A,B for which the wires will cross each other." Which is basically the point of overlapping for identically rotates poles. And i also noticed that what i proposed as "fix" is exactly how the game already does it. These moments when you notice you were right saying nothing all along and shouldn't have stopped doing that...

Oh, btw, substations actually violate the scheme for three of four rotations:

eradicator wrote: Fri Feb 21, 2020 5:42 pm Oh, btw, substations actually violate the scheme for three of four rotations:

That probably is a (minor) bug.