Friday Facts #276 - Belt item spacing & Script rendering

[H8UL]

The new sprite rendering is of great interest to me as a modder.

I've sometimes wondered about "total conversion". Factorio's core mechanics are specialized, the api reflects that and is its greatest strength, but it has some downsides if you really want to go wild. I had a go at removing the base "mod" once and I found that the game couldn't function without some very specific things like accumulator prototypes. But, I hold out hope that I will do something far out.

Well, I think that added rendering on entities, along with FFF #262 which lets mods get more flexible with units, really starts to make the API look viable for total conversion. In fact this FFF's example with ordering the biters around is just the sort of thing. I can think of all sorts of games where giving units commands is essential to gameplay.

Hey, I'm thinking that with the moddable panning camera, Herzog Zwei might be possible in 0.17... Hope I'm not the only one old enough to remember that retro classic!

https://youtu.be/2nmfgdwS19I

[Mike5000]

8 pixels could be the norm for medium sized objects, all the way down to 4 or fewer pixels per item for the smallest components like wires, and then much higher, maybe 32+, for things like buildings and trains.

Yes!

[Nova]

Factorio is still an early access game. It's in development. Things should change and many even break as often stuff can only change and improve by breaking others. In my opinion we can't rely on backwards compatibility and retention of etablished configurations as this holds back the overall development of the game. Because of this I regard "That change breaks my construction!" as a weak argument against changes.
It is still nice if we can continue to play a save game and keep our bases, but we are still only playing some kind of test version of a game. We test changes to the gameplay and report feedback to the developers. Most changes are good, some bad. This of course differs for different players.

For me, the change to the number of items on a belt is in the same category as the speed change to inner and outer lane of belt corners, for example. That was some interesting mechanic, but did look more like a bug and was pretty annoying. The current behaviour feels much nicer, at least for me.

[dee-]

"Breaks" in the sense of detecing >4 when on full throughput for as long as the two splitted belts have not been emptied, so for about 2 seconds, after that the normal full belt throughput will again be split into 2* 1/2 full belt and detected as 2* 4 items on the belt

Those bits can't empty as long as the input is saturated. There's not enough output capacity.

Aaaah, guys, you were right! Sorry, somehow I lost my brain somewhere.

As Nidan pointed out, stopping the input belt to give boths intermediade belts time to empty themselves again down to 4 items could help here.

Damn, I really should find more time to try these things out and not have to reply to forum posts in the middle of the night (5 am) because I woke up and understood what you all meant

[dee-]

Factorio is still an early access game. It's in development. Things should change and many even break as often stuff can only change and improve by breaking others. In my opinion we can't rely on backwards compatibility and retention of etablished configurations as this holds back the overall development of the game. Because of this I regard "That change breaks my construction!" as a weak argument against changes.
It is still nice if we can continue to play a save game and keep our bases, but we are still only playing some kind of test version of a game. We test changes to the gameplay and report feedback to the developers. Most changes are good, some bad. This of course differs for different players.

For me, the change to the number of items on a belt is in the same category as the speed change to inner and outer lane of belt corners, for example. That was some interesting mechanic, but did look more like a bug and was pretty annoying. The current behaviour feels much nicer, at least for me.

I keep the old stable versionss of Factorio around so I can boot them up when I feel the need to check out again how things were in the gray past, like items being individual entities (three lane belts anyone?) or, like you mentioned, different speeds of the inner and outer lane so you had to use higher speed belts in the corners to not stall and uncompress items on the inner lane (and split every blue belt in every corner to maintain blue belt compression) or how trains had different lengths depending on if they were vertically or horizontally oriented, meaning different blueprints and number of inserters for stations. Fun times.

Regardless of these unique quirks I prefer the most recent versions and also think constant 8 items per belt entity is better than a fluctuating number of items you have to average out over three belt entities. I just fear if everything is "2^x" and too symmetric and all the factors add nicely up it could become too easy.

(No, I don't miss the quirks mentioned above)

[DaveMcW]

Here is a 45 items/s throughput detector.
If the belt is running at full speed, it outputs negative numbers (or zero).
If the belt has gaps or stutters, it outputs positive numbers equal to the size of the gap in pixels.

0eNqlVduumzAQ/JXIjxW0hFyL+tLvqI6QwZvDSmAje4lOFPHvXUOTkJPQQPsCwqxndmZ8OYusbKC2qEkkZ4G50U4kv87C4buWpR+jUw0iEUhQiUBoWfkv+KgtOBeSldrVxlKYQUmiDQRqBR8iWbbBSxBpkYoKCPMwN1WGWpKxA4y4fQsEaEJC6LvqPk6pbqoMLJNcoSpQ2FQhlJCTZbzalMBEtXE82WjfAgOGPOHErxVzsFLNxdgJPoulf1hQQxpUXQ9t67V8oo6v1N4ykpqGGh6YoztisqZMMyjkEbmYKw5YEtgR549oqeGRK2NfEf4UHVrjo9sOjH+brm45UOa/VzwTbd4g/VX86tqKghwV2Cnal183I+r/gKT8T+G15wNaR+lcN/osOlLuqZa26ykRP3iCaahu5kPWp7RzOT1YU6WoGUMkZBtopxv9YOy97+tH3wMRT8P6nOFYaOsX+24kt2g0thvM/yUHMi+80w48THrLMNxzZjVwhF1T4su/ZTgjpu08458bvXl1So6dS7wqhELb93m/SC7Y29nY0VPo54le1IGWWQmpQuffIjnI0sFNvAWp0kL2WRF36Pr9cKu4jPellVEMEk2PYT3N6N1sM0Z85mumu5mSwW0YiFIyCI+tNwv/131zCyqsad4LXoELBcQA3b458tHdIW33uzjeL79Hu7htfwNnMIm0

Copy blueprint

throughput.jpg (119.49 KiB) Viewed 7718 times

[weaknespase]

Nice, though output is pulsed and it doesn't show any difference between full belt and and single side full belt. Perfect to detect gaps or if the belt backs up.

[FasterJump]

The belt change is pure genius. Integers for speed AND spacing AND throughput. Sometimes best ideas are the most simple ones.

About the possible furnace buff, whatever you do please don't forget to test beaconed setups. But...

With the possible exception of direct insertion, exact ratios are way overhyped. Exact ratios take forever to saturate belts. And unsaturated belts cost UPS. It's much better to always have a little overproduction and back-pressure.

This makes sense too. Which is better, back pressured belts for compression, or exact furnace ratios, for easier math?

Can I also propose modifying the heat exchanger to heat steam to 515 C? So that it makes 100 steam per second instead of 103.whatever, and turbines can still consume 60 steam per second, but produce 6 MW instead of 5.82, and also make nice 5:3 ratios with exchangers instead of 97:60?

Rounder steam ratios sounds appealing.

I'm curious what effect this will have to the behavior of inserters grabbing things from belts when they are "too spaced out" for the inserter to grab.
Will this possibly make the issue more common now that we have more spacing, or could it perhaps reduce this issue?

I'd like to also have a clarification about this concern: will this reduce the ability of inserters to grab items on fast belts? Like long handed on blue belt, burner inserter on red belt.

[Avezo]

Loaders - is it finally time for them in vanilla with faster belts? Could be only one type only for blue belt, requiring lot of power, etc.

[Zavian]

Train signals also need fixing.

What are you talking about? Signals work perfectly fine. What needs fixing?

"No Path" does not help locate where a problem is along a thousand-unit track with fifteen signal pairs. It takes a lot of guesswork and trial-and-error to fix "No Path." Very new/moderate player unfriendly. I am on my 25th factory and still struggle with this to the point where I had to ditch a nice organized "main bus" rail system for a bunch of parallel in and out lines.
See discussion here:
viewtopic.php?f=5&t=63414

I disagree with some of what you are saying. Whilst the tutorial could do with lots of improvement, the fact that you are struggling to build and properly signal what you want, does not mean that "Train signals also need fixing". I strongly suggest reading https://www.reddit.com/r/factorio/comme ... ts_23_and/ . Not just part 1, but also parts 2 and 3 which are linked in the top comment. If necessary also build and play around with the examples. Youtube should also have some tutorials.

"No Path" does not help locate where a problem is along a thousand-unit track with fifteen signal pairs.

Whilst you are right that "No path" doesn't tell you where the problem with your layout is, don't forget that Factorio isn't sentient, it does not understand what you intended, only what you built. It can't point to somewhere and say, "Hey you stuffed up here. What you built won't work the way you intended." Since there is no way for the game to know what the problem is, you need to locate the error yourself. But "No path" can help you find that error.

90% of the time that I get a "no path error" it is because I haven't actually built a rail-line that goes where I want (eg a junction for an outpost might initially only need to support turning left. That might be fine for whatever route it was built for, but when I add a new station somewhere else, the new route might need also need right turns at that same junction. Instant "no path", which has nothing to do with signals).

Driving the train manually will help you find errors like that and will help spot signal errors as well. Jump in the train and drive it manually in the direction you think it should go. Leave the train gui open. Pay attention to the signals that you pass. Are they on the right hand side? Every few 100 tiles try to send the train to its destination in automatic mode. If it suddenly starts working, you know that you have just passed the area where the signals are wrong. Once you know where to look go back and check that those signals. You can mouse over every signal to check which way trains are allowed to move. If necessary you can test automatic mode just before and just after every signal to help with narrowing down which signal is the problem.

It is possible to build rails that look fine, but aren't possible to use in automatic mode. eg the following picture has trains approaching from the right, merging onto a rail with trains heading south. If I connect the rails first, the game will prevent me placing the problematic signal. But if I build and signal the horizontal section before attaching it to the north-south line, Factorio doesn't interpret this as an error. That junction is perfectly useable by trains in manual mode, just not usable by trains in automatic mode.

Signal.png (1.25 MiB) Viewed 7672 times

[Koub]

Train signals also need fixing.

What are you talking about? Signals work perfectly fine. What needs fixing?

"No Path" does not help locate where a problem is along a thousand-unit track with fifteen signal pairs. It takes a lot of guesswork and trial-and-error to fix "No Path." Very new/moderate player unfriendly. I am on my 25th factory and still struggle with this to the point where I had to ditch a nice organized "main bus" rail system for a bunch of parallel in and out lines.
See discussion here:
viewtopic.php?f=5&t=63414

I disagree with some of what you are saying. Whilst the tutorial could do with lots of improvement, the fact that you are struggling to build and properly signal what you want, does not mean that "Train signals also need fixing". I strongly suggest reading https://www.reddit.com/r/factorio/comme ... ts_23_and/ . Not just part 1, but also parts 2 and 3 which are linked in the top comment. If necessary also build and play around with the examples. Youtube should also have some tutorials.
[...]

[Koub] This subdiscussion is interesting, but totally off topic. If you want to discuss it, please do it in a dedicated thread (there are existing topics about fixing the "No Path" issues)

[lacika2000]

As the smelting recipe change, I am proposing the following:
- Iron plate, copper plate, stone brick: 3.2
- Steel: 16

That would mean exactly 48 stone furnaces per yellow belt, which is the number that people already build, but some of the last ones flicker with inactivity in 0.16, now all of them would work nonstop.

Please don't... Let me have more smelters per belt, I don't consider 48 a holy number.

[lacika2000]

Express belt being faster (4x yellow belt) becomes visually too fast. We have already tried to do that earlier.

Is there a chance you can capture it and share the video here? Elon Musk is claiming that the batteries in a Gigafactory are going down the belts faster than the bullet... I would love to say the same about my Factorio complex as well.

[DaveMcW]

With items 8 pixels wide, moving at 4 pixels/tick, it is impossible to tell what direction they are going. They just oscillate back and forth.

At even faster speeds the belt appears to go backwards.

[weaknespase]

Moderate amount of motion blur can salvage situation in case of 4-5x belts, but how fast inserters then should be?

Personally, i found even blue belts redundant and almost useless if you're not trying to build a beaconed setup.

[VuiMuich]

With items 8 pixels wide, moving at 4 pixels/tick, it is impossible to tell what direction they are going. They just oscillate back and forth.

At even faster speeds the belt appears to go backwards.

since belts can't go backwards, the way items overlap helps to avoid this optical misconception I think.

[Serenity]

Adjusting the furnace recipe isn't essential, but it's not just an OCD thing. It's also about balance. Furnaces already take up a huge amount of space. Making them require even more at 54 is a bit too much IMO. And building all these huge smelters by hand at the beginning is not fun. 48 though is a decent length for a furnace column.

[Wiking]

Love it how everyone is hyped about belt speed changes and theory crafting around that change, while all I can think about is:



I just can't stop thinking of optional RTS game mode they mentioned they would like to do and keep imagining my engineer landing down on the planet Supreme Commander style and building my base with RTS camera/controls :3

[ThaPear]

Another throughput measurement setup. (Read-mode)
Outputs 0 if it has full throughput, negative if it's starving, positive if it's saturated.
The feedback loop empties due to the splitter priorities.
This setup only works properly due to the changes in 0.17.

0eNrNls1uozAQx99lzrDCtGkSbn2OVYUMTMpIYCPbRI0i3n3HsKXsAmrgsnsB2R7/mP982Nwhq1psDCkHyR0o18pC8vMOlt6VrPycuzUICZDDGgJQsvYj/GgMWhs6I5VttHFhhpWDLgBSBX5AIrq3AFA5coQDsR/cUtXWGRo2+I4VQKMtb9fKe8HIMA7gxi/BXynIYD6sPXfBDB6P8BoLausQKzY3lIeNrnABLQZ0zGgOgRrY1q8K/zBYTDUQjw5sSSZvyfXDuHvrugVPnrbLFIsyX3rPnNFVmmEpr6SN3/DpAyqZVZgWZP0bkousLH65aFAWaSlVkXoI+8janGknFp/zg2mtC/RJXFD0vFlRtCxogX0Y2dKQK2t0nLJc1xkp6VjwDP07VtGPQ7ccny+OV1jQmNcLGevSWZlfybiWZ0ZHBosQZV768rboMZ5lnfRNcwpAN2jk4BSEvFO3rmk3sF/Bl86jhXfmSgsgXlldq8OXve0W/Zm1eIF93MsW37NP29lPj7LPOys56v5JL+49msREej8WKzUiollAbFORc2hWj6mh86aBHuufbxXN3cdGYOi99OEk9ddChRd/a8xdETtzI2be/M+ZOq9lIt4s/+GOEtuvJLHM5hu+/ytIJj8RAVzR2OGAPx3j+CTO0THuul9k8exV

Copy blueprint

Throughput.png (367.87 KiB) Viewed 7576 times

EDIT: I just realized this still needs gaps in the input to empty the loop.

[Oktokolo]

Regarding belts too fast to see the items move: I would like to have a belt tier, wich is too fast to be directly inserted or picked up from by inserters. That tier would be an expressway for items to be used in buses only. You would have to merge/split from/to lower belt tiers to add/remove items to/from it.
Could even be the blue belt with speed increased to double that of red belts. And it would be fine if it would be hard or impossible to follow items on that express belts visually when zoomed in.