Video of a PoC showing speed changing belts new video (2021.02.01)

[ss_Baum]

In the attachments you can find the first version of the speed changing belts. Excuse the quality, it's because the server didn't recognize it first.
I want to thank you all for the help, you gave me.

You are a great community, that I love <3 more every day.
(of course love to work with )

edit: In this topic I will now post updates regulary, for people, who are interested.

There are the new videos.

Showing speed edit:

showing the process of handling many belts (3,4k)

Of course there is still much to do, I see I forgot to show the splitters and underground-belts.
To the Performance:

At the moment I can't get over 1000 entities/sec without lags, In a mega base with more stuff the number will probable go down.
However, you can adjust the updates and turn the electricity dependent speed of.
I added this, because the most Bases don't have any electricity-problems later, so this could save performance, if turned of. You will, of course still be able to edit the speed and the belts will still use power, but don't slow down if they have no power, after they started.

There are also still many bugs to fix (electricity don't reduces right by splitting a line, Crashs, some belt's don't stop by power loss, overwriting belts are always handled as new line, ...)

So it will still need a while, but it goes forward.

If anyone has further suggestions or want's to help in the development process, leave a comment ore message me directly.

[ss_Baum]

oh and the belt's from ultimate belts are of course just place holders.

[Koub]

[Koub] I changed the title of the thread because clickbait titles are cancer.

[ss_Baum]

[Koub] I changed the title of the thread because clickbait titles are cancer.

Well, because it wasn't intended for this forum, the people who helped me, would have probably known what I mean, but thank you anyways.

[ptx0]

I know, it doesn't belong here, but I want to show it everyone, who helped me on this hard way.

In the attachments you can find the first version of the speed changing belts. Excuse the quality, it's because the server didn't recognize it first.
I want to thank you all for the help, you gave me.

You are a great community, that I love <3 more every day.
(of course love to work with )

impressive work. one thing to note, if you're using many electric-energy-interface entities you're going to have a bad time when your UPS starts dropping due to active chunks.

[ss_Baum]

I know, it doesn't belong here, but I want to show it everyone, who helped me on this hard way.

In the attachments you can find the first version of the speed changing belts. Excuse the quality, it's because the server didn't recognize it first.
I want to thank you all for the help, you gave me.

You are a great community, that I love <3 more every day.
(of course love to work with )

impressive work. one thing to note, if you're using many electric-energy-interface entities you're going to have a bad time when your UPS starts dropping due to active chunks.

It's of course very far from done, but it's a first step for a concept, I couldn't find in the mod portal.
I will probably create one electric-energy-interface entities for one belt line.

[Koub]

Well, because it wasn't intended for this forum, the people who helped me, would have probably known what I mean, but thank you anyways.

Don't be so modest, your work interests probably a lot more people than the few you have interacted with on this subforum

[eradicator]

I can hear the screaming of the entities being murdered. It's a nice PoC, but it's never gonna scale. I don't even want to know how large the lag spike would be in an actual base with just a single electic network and 50k+ belts. Unless your goal is to prevent brownouts by fear-of-death-by-lag. Unless every assumption i just made about the implementation is wrong, but i doubt that. For the record: I'm assuming that you fast replace all belts with one of 5-ish pregenerated speed scaled prototype variants.

[ss_Baum]

I can hear the screaming of the entities being murdered. I don't even want to know how large the lag spike would be in an actual base with just a single electic network and 50k+ belts. (Unless your goal is to prevent brownouts by fear-of-death-by-lag.) It's a nice PoC, but it's never gonna scale. (Unless every assumption i just made about the implementation is wrong, but i doubt that.)

Well I think you have to start somewhere, there is no way a mod won't effect anything. But for lag spike prevention I, of course, will do something like limit the number of entities changed per cycle, maybe also depending on the UPS of the game.

But that's far away, first I need to do this for splitters and underground belts and create a basic GUI.

[eradicator]

Well I think you have to start somewhere,

Oh sure. And if you do it for your own fun who's to stop you. But knowing the general factorio community's craving for high performance i hope you've adjusted your expectations accordingly.

there is no way a mod won't effect anything. But for lag spike prevention I, of course, will do something like limit the number of entities changed per cycle

Welp sure, but in a large base with a fluctuating brown-out the behaviour would be entirely erratic, and the user would probably fix the power issues before all belts are "updated". And in the much more likely case that a sufficiently large base always has a completely oversized energy supply...the mod would presumably simply add an energy-checking overhead without ever actually doing anything.

maybe also depending on the UPS of the game.

UPS is not known to mods.

But that's far away, first I need to do this for splitters and underground belts and create a basic GUI.

Have fun! And don't mind my grumpy old self. I just couldn't resist doing a thought-experiment target-audience/usecase check ;). If this had a zero performance cost during normal operations i'd totally use it myself. But I've started numerous small mod projects myself that i'd had to ultimately abandon due to API limitations... so i'm not getting my hopes up.

[ss_Baum]

Well I think you have to start somewhere,

Oh sure. And if you do it for your own fun who's to stop you. But knowing the general factorio community's craving for high performance i hope you've adjusted your expectations accordingly.

there is no way a mod won't effect anything. But for lag spike prevention I, of course, will do something like limit the number of entities changed per cycle

Welp sure, but in a large base with a fluctuating brown-out the behaviour would be entirely erratic, and the user would probably fix the power issues before all belts are "updated". And in the much more likely case that a sufficiently large base always has a completely oversized energy supply...the mod would presumably simply add an energy-checking overhead without ever actually doing anything.

maybe also depending on the UPS of the game.

UPS is not known to mods.

But that's far away, first I need to do this for splitters and underground belts and create a basic GUI.

Have fun! And don't mind my grumpy old self. I just couldn't resist doing a thought-experiment target-audience/usecase check . If this had a zero performance cost during normal operations i'd totally use it myself. But I've started numerous small mod projects myself that i'd had to ultimately abandon due to API limitations... so i'm not getting my hopes up.

I actually think, that your thoughts are very usefull, they actually brought up the idea to create something like an network detector, while there is noc change, there are no updates, what means better performance. That's how I find problems, I didn't see on my own.

So thanks for sharing your thoughts.

Oh and that's just the basic concept. my Idea for later was something like smart belts, which can get faster ore slower due network inputs, but that means more checks...

[ptx0]

you can just wire up every piece of belt to an accumulator to have them shut off when the accumulator is empty.

[ss_Baum]

Ok, I have decided now, how I will do it.

I create an electric-energy-interface for every network, totally seperat from the belts.
The belts have no buffer so every change in the network will effect every belt in the same way, of course in percentage, because all electric entities of the same priority get effected in the same, relative way to there normal energy consumption.

If the network supply get's to low, it will fire an Event, that starts slowing the belt lines down.
For this it isn't important, that the every belt get's slower at the same time. Let's say 5 per line in the first 10 to 60 ticks, after the event fired.
That means by 50.000 belts in lets say 1000 lines max 500 belts per tick. I have to figure out, if this is already to much, then I will stretch the time.

After this the items on all lines should start slowing down, because there are some slower belts. So after this the rest also start's slowing down, but here is the performance the most important part.

I will test on my PC, how much goes per Tick, and than I take the halve ore quarter of this, to realize it for the mod.
I also won't do this with an onTick event, that would probably lead to too high lag spikes. I will probably need a custom Event, that can go over multiple ticks, without slowing down the game.

Maybe it's also possible to use the os.time (lua offers this, but I don't know, if it works in control.lua) to define the ups and slow down the changes, if necessary.
But because I am at work at the moment, I can't test it jet.


So what do you think?
Could this be a good way to set this up?
Did I miss something completely?

[eradicator]

I create an electric-energy-interface for every network, totally seperat from the belts.

That sounds like a more sane approach and would also reduce entity spam. But you have to deal with network splits/merges. Update the network polygon every time a pole is placed/removed, handle overlapping and out-of-network belts. Network splits/merges. Circuit controlled electric energy switches. I'm not sure if there even is an event for shift-left-click removing cables, but there certainly isn't one for manually connecting poles with copper wire.

So it sounds nice on paper, but you might be replacing a constant overhead with frequently occuring large lagspikes (network updates) and heaps of annoying and bug-prone detection code.

That means by 50.000 belts in lets say 1000 lines max 500 belts per tick. I have to figure out, if this is already to much, then I will stretch the time.

That's like spamming a 30k entity blueprint every second. Aka, sounds too large to me.

For this it isn't important, that the every belt get's slower at the same time. Let's say 5 per line in the first 10 to 60 ticks, after the event fired.

Technically true, but the visual effect of 1% of the belts "randomly" being slowed down on a compressed belt will probably look ugly and/or confusing.

That means by 50.000 belts in lets say 1000 lines max 500 belts per tick. I have to figure out, if this is already to much, then I will stretch the time.

Do you intend to manually detect "lines"? As factorio now uses internal "belt groups" for optimizations it might be worth asking for them to be exposed in the API.

Years ago I've seen another "powered belts" mod was conceptually designed with a "belt motor" that powered the "line" that it was directly attached too. Kind of a compromise between "every belt has an eei" and "only one eei but you have to deal with networks". Depending on how annoying it is to detect and deal with actual network-coverage-polygons there's tons of possible compromises you could chose from. From "one eei per chunk", to player built "belt power supply boxes" that cover a fixed area, etcpp.

Imho a good first approximation would be to have a single (manually built?) "belt controller" for each surface. As factorio encourages the use of as few networks as possible this isn't too unrealistic either. And that way you can optimize the belt slowdown mechanic first, and once that works well enough in a large enough factory you can start thinking of how/if you want to deal with networks/forces.

Maybe it's also possible to use the os.time

Nope. Access to data outside the sandbox is not available. That's why many mods have an mod setting for "updates per tick" to allow players to adjust it to their computer specs.

So what do you think?
Could this be a good way to set this up?

I think first you have to decide on what scale you want the mod to work at. For example my "50k belts" number is from my current experimental belt-only-no-trains map that barely scratches 100SPM (not 1k). So if you care about megafactories you should look at some of the public maps to get realistic numbers, but i doubt the number gets any smaller ;). Thus imho it'd probably be easiest to only consider <500SPM factories in the design of the mod and completely ignore "mega".

Did I miss something completely?

Dunno. It generally seems like the usual factorio modding problem: Polishing it up to work nice while also looking nice will be about 10 times more work than you expect it to be ;).

[NotRexButCaesar]

Here is the video for everyone who doesn't want to actually download it:

video

[ss_Baum]

So it sounds nice on paper, but you might be replacing a constant overhead with frequently occuring large lagspikes (network updates) and heaps of annoying and bug-prone detection code.

Well, I did realize this now too. I also realized, that I have to check if at least one Belt has power. So I will do this with one ElectricEnergyInterface per line.

That's like spamming a 30k entity blueprint every second. Aka, sounds too large to me.

Yeah, it was too much. I will turn it down to 100, that could my game at least handle. There will be an Option of course to make it higher ore lower.

Technically true, but the visual effect of 1% of the belts "randomly" being slowed down on a compressed belt will probably look ugly and/or confusing.

I will think about this. Maybe there will be an option where you can choose line by line ore Random belt actualization.
One would effect your complete production faster, the other one looks nicer.

Do you intend to manually detect "lines"? As factorio now uses internal "belt groups" for optimizations it might be worth asking for them to be exposed in the API.

I will ask them, but probably, at least I would do it like this, they store just the position and speed data they need.
And it would probably impact the performance, if they throw this large tables with that many entities in the API.
The line detection I have in mind would be done by building the belts with belt_neighbour. Destroying them would lead to a split, where I would need to get all the belt's in the old line and create two new ones. so that could be more of a problem.

I think first you have to decide on what scale you want the mod to work at. For example my "50k belts" number is from my current experimental belt-only-no-trains map that barely scratches 100SPM (not 1k). So if you care about megafactories you should look at some of the public maps to get realistic numbers, but i doubt the number gets any smaller . Thus imho it'd probably be easiest to only consider <500SPM factories in the design of the mod and completely ignore "mega".

I would really like it to get it working for mega factories. I have also an Idea for the energy usage of the Belt's so they won't all run on full power. (Something like (items/sec)^2/10 for kW. That would mean 1 MW per belt by "just" 100 IPS.

With the belt's that energy-expensive I want to encourage the player to built the efficient.
The only problem with this is just that two belts with 50 IPS just need 500kW, So they would probably just built more, slower belts what would mean longer update-times.

Well first I will create the Line-detection and the EEI-Event, so that it doesn't run on tick, than I will see, how it Performs and go on from this point.

[ss_Baum]

I want to give you a short update, how my mod Development goes.

Since opening this topic and showing the video, I implemented a few major new features.

• You can now edit the Belt speed with a gui, before placing it

• The energy-consumption depends on the speed (at the moment (items/sec)^2/100, but only for testing)

• I added splitter and underground belts

• I added belt_line detection, so new built belts on an existing line wont get a new eei (not for underground belts)

• I added a system, to update the belt's step by step, to prevent ups lags.

What I need to add/fix:

• The editable belt_speed with clicking on an existing belt.

• cloning, because the entity changes, it doesn't work at the moment.

• Blueprinting, the same as above.

• Mining the energy-source of a line crashes the game. I fix this at the moment

What I want to add:

• Speed control with circuit's for lines, but this will turn off on low voltage

• Powerbelts which can Power the area around them, maybe thy will cost more energy (and crafting resources)

So as you can see, I make pretty good progress, A Video will also follow soon.
But before I can publish the first alpha, there is of course still much to do.

Do you have any Ideas ore wishes, What I should add?

[ptx0]

does it work for modded belts from ExpressBus?

[ss_Baum]

does it work for modded belts from ExpressBus?

This mod will bring in a complete new type of belt, it won't make all belt's editable in this way. So it shouldn't collide, but I will test it.

[ss_Baum]

There are the new videos.

Showing speed edit:

showing the process of handling many belts (3,4k)

Of course there is still much to do, I see I forgot to show the splitters and underground-belts.
To the Performance:

At the moment I can't get over 1000 entities/sec without lags, In a mega base with more stuff the number will probable go down.
However, you can adjust the updates and turn the electricity dependent speed of.
I added this, because the most Bases don't have any electricity-problems later, so this could save performance, if turned of. You will, of course still be able to edit the speed and the belts will still use power, but don't slow down if they have no power, after they started.

There are also still many bugs to fix (electricity don't reduces right by splitting a line, Crashs, some belt's don't stop by power loss, overwriting belts are always handled as new line, ...)

So it will still need a while, but it goes forward.

If anyone has further suggestions or want's to help in the development process, leave a comment ore message me directly.