 Not sure when I'll get around to using it again myself, KSP has been eating most of my freetime (and then some
 Not sure when I'll get around to using it again myself, KSP has been eating most of my freetime (and then some   )
 )
 Not sure when I'll get around to using it again myself, KSP has been eating most of my freetime (and then some
 Not sure when I'll get around to using it again myself, KSP has been eating most of my freetime (and then some   )
 )

I tried to chain the boxes to make smth like conveyor belt, but after putting about 400 of them it started to affect performance :pssilk wrote:Moved thread to convenience, I think this has a deeper game-changing effect. But I left a link.


 You could probably reduce the load a bit by reducing the frequency at which the chests are checked. That would of course reduce the transfer speed, so not sure what the impact gameplay would be. To do this, play with the ticks variable in line 21 of control.lua. By default it checks every 60 ticks (I believe this is 1 second), so you could increase this to 119 for every other second. (ignore the ticks variable in line 7, this is just the initialization for the very first cycle, doesn't affect performance)
 You could probably reduce the load a bit by reducing the frequency at which the chests are checked. That would of course reduce the transfer speed, so not sure what the impact gameplay would be. To do this, play with the ticks variable in line 21 of control.lua. By default it checks every 60 ticks (I believe this is 1 second), so you could increase this to 119 for every other second. (ignore the ticks variable in line 7, this is just the initialization for the very first cycle, doesn't affect performance)Code: Select all
function ticker()
	if global.eqChests ~= nil then
		if ticks == 0 then
			ticks = 59
			processEqChests()
		else
			ticks = ticks - 1
		end
	else
		game.on_event(defines.events.on_tick, nil)
	end
end !
!
 I suppose what I could do (which would be easiest to implement, otherwise the added complexity might negate the gains for average usage) would be to just have a global counter that increments on each tick and processes that chest number. With <60 chests, that would cause them to get updated more frequently than now, but having more chests wouldn't have an effect on game performance at all, it would only mean that chests don't get processed as often (but for that 400 chests example earlier, still once every ~6 seconds).. Or even have a counter of the number of chests in total, divide that by 60 and process that many chests each tick. Yeah, I guess that could work. I'll have to brood on that some more, and find a quiet time at work next week to implement it
 I suppose what I could do (which would be easiest to implement, otherwise the added complexity might negate the gains for average usage) would be to just have a global counter that increments on each tick and processes that chest number. With <60 chests, that would cause them to get updated more frequently than now, but having more chests wouldn't have an effect on game performance at all, it would only mean that chests don't get processed as often (but for that 400 chests example earlier, still once every ~6 seconds).. Or even have a counter of the number of chests in total, divide that by 60 and process that many chests each tick. Yeah, I guess that could work. I'll have to brood on that some more, and find a quiet time at work next week to implement it 


I agree, The mod is still beneficial, I'm just saying there WAS a solution to the problem :pBoogieman14 wrote:For the specific case I presented, yes. But I've been using these things in many more places where it's useful to have stuff spread out over all chests
I also agree here, I never actually use this configuration, BUT I do use the rail carts in other areas, as I will upload shortly....Boogieman14 wrote: Besides, I think those wagons look kinda silly when used like that

Yeah, I noticed that too when I was trying some stresstesting the other day. I clearly hadn't considered situations where more than 100 of these would ever exist in a gameJohnyDL wrote:I've tested this extensively and I think that there's a few slight bugs
First I have a problem placing chests without major lag spikes, I have over 3k in one game and it's noticeable to the point of when I build them I have to in short stints giving myself a headache before I have to stop for a while
 I know what the issue is, I'll need to look into fixing it properly.
 I know what the issue is, I'll need to look into fixing it properly.If you don't have the inventory space, just open the chest and mark all slots red. Stuff won't be added anymore, it will still slowly empty into neighbouring chests as contents balance out or you can manually move stuff over and mine it once it's empty. That should work well enough. Removing a chest using bots is still an interesting way of turning construction bots into logistics bots, so I'll probably still see if I can add something to do the disabling automatically.Second if you have a huge number of items in the system (I use them instead of conveyers for ore mining, providing me a huge ore reserve) removing the chests is tedious, you try to delete it only to have it empty into your inventory and refil before you can, I eventually learned to hot swap to steel or mark it as unusable and then delete the chest but there should be a better way to handle it.
I'll have to think about a way to work around this without adding all kinds of complicated calculations.Third if you try to use the chests to move things over a distance, the difference of 10 to initate movement is kinda anoying, it means that you're limited in distance unless every so often you put in inserters as valves which adds it's own set of problems, so moving iron ore for example is limited to a trickle after 240 chests, I know the difference of 1 means stuff bouncing so is there a different way to handle it? perhapse spreading over the entire network rather than neighbouring chests.

Well, as of version 1.1.2 this should now not be an issue anymore. Placement of the 10,000th chest should now take the same amount of time as placing the second did.JohnyDL wrote:I've tested this extensively and I think that there's a few slight bugs
First I have a problem placing chests without major lag spikes, I have over 3k in one game and it's noticeable to the point of when I build them I have to in short stints giving myself a headache before I have to stop for a while

 )
 )
I've given that some more though, and I actually disagree with it being a bugJohnyDL wrote:As for the the third bug
 I suppose, tuning that threshold down a bit would alleviate your problem, but in the end these chests do what it says on the tin: they transfer stuff between their neighbours so each holds roughly the same amount. From your description and suggestion, it appears you think they're considered part of a bigger network, but this isn't the case: they only know about their direct neighbours and will only communicate with those.
 I suppose, tuning that threshold down a bit would alleviate your problem, but in the end these chests do what it says on the tin: they transfer stuff between their neighbours so each holds roughly the same amount. From your description and suggestion, it appears you think they're considered part of a bigger network, but this isn't the case: they only know about their direct neighbours and will only communicate with those.Ah yes, I suppose the map editor doesn't execute the placement scripts. Fixing that may not be trivial though, I suspect I'll have to scan the entire map for all instances and initialize them. Depending on the number of chests, that could cause a rather significant delay at load time.one more bug, if you place the equaliser chests using the map editor they don't act like equaliser chests during the game, could use a one off routine to check for those on game launch

I've had this issue too, when I've tried to play my savegame with my son. Often repeated syncs. I have about 400 EqChests - it's my way to provide smelters with ore.roy7 wrote:Had anyone else had issues with Equalizer Chests in multiplayer? On one of the US public MP servers we were having issues we eventually determined was Equalizer related and removed the mod which cleared it up. Some observations are that placing/removing them was safe, and using them would only rarely cause a desync, so it was hard to isolate at first. But if we have an active train unloading station and replace 10-12 chests in-place with Eqaulizers that inserters are busy loading/unloading ore to, it was much more likely to cause an immediate desync.