At least for the Mark 2 Roboport, the Internal Buffer Recharge Rate needs to be increased to accomodate not only the inceased roboport recharge rate, but the increased number of ports.

First and foremost, thank you for your comment!

Let me take a look at the numbers a second time, now that this mod has been out for a while. One thing I am accessing is to add a recharging station, with a very small range logistical and construction range, but with about 12 - 24 recharging ports to recharge robots, specifically addressing the issue of logistic network with a larger number of lower tier robots. I can see where someone may want to have a large number of cheap vanilla robots, especially on repairing perimeter defense. That might be a good time to add that in.

Part of this issue is addressed by the lower energy requirement on the mk5 robots, and their speed. For the robots themselves, once you start transitioning from the vanilla robots, the energy consumption numbers drop. The drop is not linear, but where the vanilla robots were 3.0 kW + 5kJ/m the mk5s are down to 2.4kW + .5kJ/m. Along the way different tiers improve different aspects of the robots.

In summery, mk2 have better batteries, so they can operate longer then the vanilla. The improvement in mk3 is that they are much lighter then the mk2, that gives them significant energy consumption reduction as compared to the mk2. Mk4 utilize rocket fuel for propulsion, for a sizable speed increase, at the cost of increased weight and energy reduction. Finally the mk5 adds in nuclear fuel for a small speed increase and massive energy reduction.

In testing, I found that my main base with 2000 mk4 robots with 9 mk3 roboports outperformed the same base with 10000 vanilla robots with 81 vanilla roboports. When I added in lower tier robots to that same logistical network with 2000 mk5 robots, the performance of that logistical network declined, since the lower tier robots are not as energy efficient. In testing, I found that 5-10 vanilla robots can be replaced with one mk5 robot.

I'm using this mod for my current playthrough. I have unpacked the zip, and I have made some changes to the MK2 and MK3 roboport (locally) to provide more charging locations, a higher recharge rate, and better internal buffer charging.

I'm pretty sure the increased recharge rate I put in is ridiculous as far as balance is concerned, but the recharging locations might be helpful for you. I wrote a python script to generate the locations.

local robo2 = table.deepcopy(data.raw['roboport']['roboport']);
robo2.name = "hsmd-roboport-mk2";
robo2.icon = "Hiladdar_Robots/graphics/icons/hsmd-roboport-mk2.png";
robo2.minable.result = "hsmd-roboport-mk2";
robo2.energy_source.input_flow_limit = "15.0MW";
robo2.energy_source.buffer_capacity = "300MJ";
robo2.recharge_minimum = "60MJ";
robo2.energy_usage = "75kW";
robo2.charging_energy = "2000kW";
robo2.logistics_radius = 50;
robo2.construction_radius = 110;
robo2.robot_slots_count = 12;
robo2.charging_offsets = { {-1.5, -0.5}, {1.5, -0.5}, {1.5, 1.5}, {-1.5, 1.5}, {1.5, 1.5}, {-1.5, 1.5} };
robo2.base_animation.filename = "Hiladdar_Robots/graphics/entity/roboport/hsmd-roboport-base-animation-mk2.png";
robo2.base_animation.hr_version.filename = "Hiladdar_Robots/graphics/entity/roboport/hsmd-hr-roboport-base-animation-mk2.png";
robo2.fast_replaceable_group = "roboport";

local robo3 = table.deepcopy(data.raw['roboport']['roboport']);
robo3.name = "hsmd-roboport-mk3";
robo3.icon = "Hiladdar_Robots/graphics/icons/hsmd-roboport-mk3.png";
robo3.minable.result = "hsmd-roboport-mk3";
robo3.energy_source.input_flow_limit = "600MW";
robo3.energy_source.buffer_capacity = "500MJ";
robo3.recharge_minimum = "10000MJ";
robo3.energy_usage = "100kW";
robo3.charging_energy = "16MW";
robo3.logistics_radius = 75;
robo3.construction_radius = 165;
robo3.robot_slots_count = 12;
robo3.charging_offsets = {{ 1.5, 0.0},{ 1.4711779206048456, 0.2926354830241924},{ 1.38581929876693, 0.5740251485476346},{ 1.2472044184538178, 0.8333553495294033},{ 1.0606601717798214, 1.0606601717798214},{ 0.8333553495294035, 1.2472044184538178},{ 0.5740251485476348, 1.38581929876693},{ 0.2926354830241925, 1.4711779206048456},{ 9.184850993605148e-17, 1.5},{ -0.2926354830241923, 1.4711779206048456},{ -0.5740251485476346, 1.38581929876693},{ -0.8333553495294029, 1.247204418453818},{ -1.0606601717798212, 1.0606601717798214},{ -1.247204418453818, 0.8333553495294033},{ -1.38581929876693, 0.5740251485476349},{ -1.4711779206048456, 0.2926354830241929},{ -1.5, 1.8369701987210297e-16},{ -1.4711779206048456, -0.2926354830241925},{ -1.3858192987669302, -0.5740251485476345},{ -1.2472044184538182, -0.8333553495294029},{ -1.0606601717798214, -1.0606601717798212},{ -0.8333553495294033, -1.2472044184538178},{ -0.5740251485476355, -1.3858192987669298},{ -0.292635483024193, -1.4711779206048454},{ -2.755455298081545e-16, -1.5},{ 0.29263548302419246, -1.4711779206048456},{ 0.574025148547635, -1.38581929876693},{ 0.8333553495294028, -1.2472044184538182},{ 1.060660171779821, -1.0606601717798214},{ 1.2472044184538178, -0.8333553495294033},{ 1.3858192987669298, -0.5740251485476355},{ 1.4711779206048454, -0.29263548302419307}};
robo3.base_animation.filename = "Hiladdar_Robots/graphics/entity/roboport/hsmd-roboport-base-animation-mk3.png";
robo3.base_animation.hr_version.filename = "Hiladdar_Robots/graphics/entity/roboport/hsmd-hr-roboport-base-animation-mk3.png";
robo3.fast_replaceable_group = "roboport";

But, basically, the internal buffer recharge rate needs to be higher than (number of recharge stations) * (recharge rate), or else the internal buffer will never fill, and the recharging will only be as fast as he buffer recharge rate once the buffer drains.

I had some time to think about what to do. My solution will be to set up a mk2r roboport, with 12 or 18 recharge ports respectively, while retaining or slightly reducing the coverage of the vanilla roboport. I plan on increasing the attributes associated to recharging appropriately on the base roboports. I think in the long run this will be better providing both advantages and disadvantages in using the different types of roboports. There will be nothing to prevent someone from placing a mk2 and mk2r next to each other. With the introduction of the mk2r and mk3r, one of the things I am looking at is reducing the number of that can be recharged at one time back down to 4 on the mk2 and mk3.

I like your recommendation for increasing the internal buffer recharge rate for the mk2 and mk3 roboports that are out there right now. If I choose to keep the number of rechargeable robots the same for the mk2 and mk3 robports, I'll implement your recommendation for increasing the internal buffer recharge rates.

The second option I am looking at is having an mk4 and mk5 roboports. In this option the mk2 gets the upgrade and ability to recharge 12 robots, mk3 gets the range of the current mk2, mk4 gets the range of the mk2 and about twice the number of robots to recharge, while mk5 gets twice the number of robots of the mk3-4 and the range of the current mk3.

The third option, I am looking at, for the user to define how they want the roboports to be via the settings file, and have lua script determine the stats based of the user's settings similar to what I did for within the electrical mod which touched on solar panels / accumulators, or similar to how I implemented my manufacturing and mining mod.

Option 4 will be to just cut and paste your recommendation, and extrapolate to the mk3 from the new mk2. The advantage is that programmatically this is the fast and easy solution, but the disadvantage is that it does not bring into the game "advantages vs disadvantages"

I am currently leaning against option 2, since it may break existing bases until the player puts in new roboports. From play testing, I found that option 3 works great, unless Factorio crashes with the mod-settings.dat file is trashed. For me that can happen on a map which has over 300 hours played. Although that is annoying it is not a critical issue, since it is an easy fix, by resetting the mod-settings if the mod settings ware not set to default. Option 1 has the advantage not being affected by this issue, but the disadvantage of not being user configurable. In keeping the roboports in synchronization of how I implemented the robots and the personal roboport, I am currently leaning to option 3.

It looks like you have put considerable effort into this. What are your thoughts on the options?

I have several rather serious family obligations which will take me out of town. Although I will have access to an internet and forms, I will not have access to system configured to be able to what I do on my personal system for development or testing. I am currently finishing up a module which mostly focuses on research affecting the player, as well as moving all items from all my mods into a separate tab.

Thanks to your initial comments and post, I did put "doing something with roboports" on my short term to-do list. It got me to start thinking about what to do with this mod. My intent is to do something that makes sense, and in some aspects makes mega-base design and implementation easier, while giving the players an interesting choice similar to what I did in the mines where the research cost for the final tier miner scales between about 1k and 1m based on how big of an improve the player wants between the different tiers of miners and pump-jacks.