ComputerCraft has always been a rather unbalanced mod: unlike OpenComputers, CC computers don't need energy, the default recipes are fairly cheap... but features like transferring fluids with networking cables makes other, unrelated mods redundant.

It would be cool, if modpack creators could tweak certain "more cheaty" (subjective) features through the config. In my case for example, networking cables make Create's fluid pipes and belts completely redundant.

I like that computers can check fluid tanks, in fact, I'd like to automate a Tinker's Construct smeltery with custom LUA logic and make the computer interact with Create clutches to control the flow of alloys and melted stuff through pipes, but currently, there's no way of me incentivising players to use anything but CC's networking cables as they don't need any power, rotational energy and they transfer the fluids instantly.

In short; I think adding more options to the server config to tweak certain features or disable them entirely would make balancing the mod in modpacks much easier. The only option of balancing CC curently that I can think of is making it an end-game mod through complicated and costly recipes.

"More options" is quite a broad request. Would it be reasonable to say what you're looking for here is the ability to disable certain peripheral methods? We had a system for doing this in Plethora, which would probably make sense in CC:T too.

That does seem like it would largely solve the problem. Being able to blacklist certain methods, modules, etc.

Ideally, I would love if there was also a config option for computers to run off of FE/RF/whatever, but that would probably be asking for a bit too much.

I think implementing something like what Plethora had (first time hearing about it actually) would be a great addition.

Looking further into the issue, I guess I could blacklist methods by overwriting them with a datapack (as explained here https://github.com/cc-tweaked/datapack-example) and just make them do nothing and return nil, no? As long as it doesn't get forcefully overwritten by Java code...

That won't work for peripheral methods, as those aren't ever added to the Lua environment - instead they're dispatched via peripheral.call:

You can't really avoid sandbox that via a datapack, as the debug API makes it quite easy to circumvent that.

Maybe instead of disabling it is better to introduce limits? In general, you can't call pullFluid more then 1 per tick (in general, I guess, frequency even less). So if we will add configurable limits to this peripheral functions (example this should solve problem without disabling anything.

@SirEdvin I would like to be able to force the players to only use CC cables for reading, writing data... communication, not fluid/item/gas/chemical/whatever else transfer.

Ah, if this is the goal, that sure.
But, I guess, if you just allow CC to transfer only 0.1b per tick, they will use this only as a start, but then replace it with more efficient methods.