VanessaE wrote:It's not really just one thing by itself, it's a collection of things
Death by a thousand cuts. Well, that's good though, because it means there wasn't some huge unassailable exploit. So maybe it can get working later.
The biggest issue came from long multi-kilometer runs of cable, dozens and dozens of nuclear reactors ganged together in places, multiple quarries used together to dig larger holes, and so on.
Well, nuclear reactors aren't honestly a huge load are they? There's only one ABM for the reactor core, that doesn't fire too often, and it isn't too expensive to check for nearby blocks at known coordinates. Granted the
use of nuclear reactors to power things like massive furnace arrays could slow things down.
Lots and lots and LOTS of cabling just all over the place causes technic to churn and churn on it, trying to compute its electrical networks.
Okay, so... if I understand right, the switching station follows along all the wires it's connected to, and finds all the producers, receviers, and batteries in the network, not only on construction, but every single second via an ABM? That's so fixable! The ABM should just be iterating over a pre-calculated list of machines. Whenever a technic node is broken, if it has a switching station, then the station traverses the network and updates that list. Whenever a technic node is constructed, it looks for a switching station in the same way, and if it finds one, does the network traversal. If not, it's offline.
Heck, there's a
second ABM that fires once a second, for every machine, that disables it if it hasn't been checked often enough. That's something you should put in on_construct and on_destruct too! When a technic node is broken, you follow the network to see if removing it would disable any machines, then update the list, disable the machines, and no need to check every second if the network hasn't changed.
It might be a bit tricky to traverse the "network" with a broken node, since that could split it in two, but putting that stuff in construct and destruct is what would keep large, complex technic networks from bogging down the server. Traversing an entire network of connections, every second? Yeesh.
I agree with your path idea. I had originally suggested a "move until coordinates foo reached, then stop" approach, but I am not sure if the engine was ever extended to allow for that (or if it was, pipeworks has not been rewritten to use it). Your idea is better.
Well, sending a "follow path" message as an ActiveObjectMessage packet is easy enough, just have to add logic to look up, set and follow the path in content_cao.cpp. But sending the paths... some of them could be very large and complex. Minetest deletes its content downloaders when the game starts, so you can't send any new media or meshes or anything, so I'm not sure what the right way to do it would be. You could add a "AddPath" packet, to add a path into a list of paths on the client, where it can send objects. But if the path was too big to fit in a single packet... should you continue in the spirit of minetest, and stall at the beginning to download all possible paths, like it does with media and meshes? Then only the server operator add paths, which sort of defeats the purpose of players being able to lay pipes.
Or should some sort of path downloader be persisted, that can take large paths broken down into packets, and reassemble them as they come in? You'd have to save any objects following along unknown paths, so that when those paths come in, you could start animating the objects. But otherwise, it's pretty straightforward. Some limit on how fast path packets can be sent in would take care of hideously complex pipe arrangements, and since it's only once when the nodes are first loaded, it'd be a lot less bandwidth intensive than repeatedly sending the path every second as separate "update position" messages.
Switching between "full" and "empty" tubes would destroy the look of the mod though - 90% of that comes from seeing items flowing through them, as it is meant to somewhat mimic similar mods in Minecraft.
Yeah, thus why I said it'd be a hack. Until that path following is done client side, you won't be able to use technic at all, since servers can't handle calculating the position of all those thousands of entities every time someone starts up a quarry.
If the wires are more problematic though, then nerfing how pipes work won't solve the problem. Need to fix how it keeps re-calculating the same network of wires, first. That seems doable entirely on the server side, though.