after a quick look at the source, i believe that all/most (?) values are not used or modified where the original mod allows to set parameters in mod settings, but the values are somehow hardcoded and need to be changed by digging deeper into this mod. would it be possible to use and change the original mod settings instead, making it easy to adjust fuel capacity, fuel consumption and thus also the range of drones? or is this intentionally not easy to change?
which of the original parameters can still be changed? the original settings are all visible, but at least some (like fuel type) seem to have no function when using this mod.

tubs, could you please make the shown parameters consistent: more easy to adjust, or hidden when not adjustable, or at least post in the description of this mod (or a FAQ etc) what the resulting values are when using this mod, for fuel capacity, used fuel per meter, and thus also (as derived value) what range the drones have before running out of fuel ?

i like that different chemical fuels can be converted to drone-fuel, which then is used by the drones, making it relatively easy to add more resources to make fuel from (eg from other mods). but one of the nice features of factorio is to give full info to users so that they can "theorycraft" setups etc. by hiding some values in this mod (or showing values that are not used when this mod is enabled), we have to do annoying tests to experimentally find these values (like range) or study and reverse engineer the source :-(

I don't think anything is hidden on purpose, I'll try to expose stuff as settings and/or use the og T_D settings.

drone-fuel has exactly the same value as petrogas would do from the transport drones point of view, I worked out the recipes based on the MJ of the incoming product which means I might have accidentally nerfed petrogas :thinking:

I'll expose some modifiers as settings, e.g:

recipe-name Fuel conversion efficiency, which will be a % of how much MJ of incoming stuff -> drone-fuel.

For liquid I am not sure exactly how to do this but I'll investigate.

10 coal -> 100 drone-fuel
5 coal -> 100 drone-fuel (with advanced refining as a fun early game diversion)
20 petrogas -> 100 drone-fuel
1 rocket fuel -> 100 drone-fuel

Oh yeah I normalised everything verus the petrogas -> solidfuel efficiency so I had to buff petrogas -> drone-fuel otherwise it would have taken 5 times as much coal I think, which is way too painful early game.

I didn't touch any of the per meter or range stuff that T_D uses. As far as I know they have unlimited range but will "deduct" any extra fuel they would have used when they get back to their depot.

i had installed T_D first, after a while installed the steam_T_D mod which changed the main mod's settings and made some "hidden". after i finally disabled the steam_T_D mod and enabled your fuel_T_D mod, the game settings were no longer hidden, but still had the old changed values (including "fuel type = steam"), and when i just checked ingame with that map active, those steam values are still shown in the game settings tab (of course, they can't be changed there while in the map) but clearly drone-fuel instead of steam is used now. thus i had assumed that you ignore all those values and use only your own ...

edit / more testing (which confirms what you wrote in the last post) :
- in my map with THIS mod, mod settings showed the old values from steam (100 fuel, used at 0.1/m, and steam), but drones worked with drone-fuel (amounts not checked).
- exited the map and changed values to extreme settings: 10 fuel capacity, used at 1/m, and water(!)
- returned to map and drones still work, using drone-fuel
- in the map, the mod settings now show 10, 1 and water ...
- built a test track, roughly 30 tiles in an open loop (supplier at one end, requester at the other, inserters move items back from requester to supplier)
- drones show really strange behaviour at first sight, but this can probably be explained below ... and still using drone-fuel and not water or steam ...
- several tests, always watching numbers, and the most interesting is probably the following:
- 335 fuel in requester, drone leaves and 10 (tank capacity) immediately is subtracted, showing 325 now. as soon as the drone has taken off, i interrupted the road near the requester and the drone continued to the supplier, took a stack of items, and turned around, but waited a moment, fuel in requester still 325. then the drone noticed the missing road and directly teleported back to the requester, together with its cargo that was also teleported into the requester. fuel in the requester also decreased immediately to 302 which corresponds roughly to the distance traveled (335-33=302).

now we have the answer: on long distances, drones never run out of fuel and continue running on "borrowed" fuel up to their destination (and back), but they need the "fuel capacity" available in the requester to start in the first place, to usually have at least enough fuel, and to be able ordering more from from the fuel depot in time. after they finish their trip (no matter whether really driving back back or teleporting back) the full amount for the roundtrip is calculated (60+ in my test) and either some is given back (if less than fuel capacity was used) or additional fuel is subtracted (corresponding to the distance really traveled, roundtrip 60, or only half the roundtrip if teleporting :-) but if more was used than is available, the fuel in the requester is simply reduced to zero, and you have saved on expenses for fuel.

resulting possible cheat: require the smallest tank and the smallest amount in the depot that is possible, and take off, possibly to a destination far far away, interrupt the road, and you'll pay at most as much fuel as is in the requester, but get the full cargo anyway, even after only half the time when the drone teleports back. disadvantage of the cheat: since the amount of fuel in the requester only drops in the end, new fuel deliveries only start after that and take a while until they arrive, to be able to send the next drone. it also is manual work to always destroy and rebuild the road at the right times. LOL

about the used vanilla fuel to make drone-fuel :
it would be nice if you could add recipes for at least the other vanilla standard fuel types, wood and solid fuel, and (just maybe) also for nuclear fuel. allowing to use wood would be really nice when playing with mods that support wood generation (greenhouses, Arboretum, Bioindustries, robot tree farm, etc), or even in vanilla to get rid of all the forests that one sometimes has to cut down to make space for the factory ...

to make it easily compatible with more mods, maybe on loading a map, you could (additionally) iterate through all items and if they are chemical fuel then get their fuel value to make new recipes for converting them to drone-fuel too? this might allow to use eg all the different kinds of seeds and saplings, or softwood/hardwood (in fantario), many types of charcoal from different mods, and whatever other fuel types mods might have, without the need to manually add compatibility for each fuel type.

of course, there always will be the odd mod that has unexpectedly low or high fuel values, that has no wood or renames wood, or renames other fuel types, etc :-) :-( and which require special treatment like optional dependencies and manually adjusted recipes or to be marked as incompatible.

Yeah I responded on another thread in T_D about the drones borrow fuel and pay back any extra etc. I'm not sure how easy it is to unmangle settings that another mod has touched, is it a big issue (it's only if you start with steam then switch to this right)?

I might be able to hide the vanilla T_D setting that sets the fuel type, since that is not needed and confusing with this mod.

I'll add a setting that basically says "auto-convert fuel stuff to drone-fuel", the reason I didn't do that originally was just to make it a bit more "special" but I don't really mind! :-)

i just read that other post :-) and added the two additional points there, that i had found out and described above (that 1. subtracting fuel to "below zero" will simply reduce fuel in the depot to 0, and 2. how teleporting with cargo works when the road is interrupted)

back to this mod : all these settings are not a big issue, but a bit confusing when there is not a lot of info which mod changes what and what shows unimportant wrong values/names. this problem doesn't only occur when using the steam_T_D mod before, but when having changed any values yourself (eg started a map with very low consumption and with water as fuel :-) and then want to use this mod. in that case, users see the wrong name of fuel and might assume (like i did) that simply all values from the original mod are ignored while in reality the other values are used as normal (including the low consumption) and only the fuel name is ignored.

maybe you could somehow add a checkmark option (as a mod option of your own mod) to "reset and overwrite settings with default values and dronefuel", true as default when the mod is first installed ? (but I'm not sure about interactions of settings and which stages of loading can be performed by which parts of a mod, etc)

and is it really necessary to hardcode the dronefuel everywhere, or can't the fuel name and values simply be taken and used from the original mod so that users still can change everything as they want ? then the fueltype "drone-fuel" would only be hardcoded for the additional buildings and recipes to not make it possible to generate 100 fuel=petrol from 20 petrol :-) but when changing the fuel name yourself and not using dronefuel this also shouldn't hurt and leave users only with some unused/unusable buildings and recipes ?

I'm not sure what you mean about changing the drone fuel name? Do you want it to split out the changing of drone recipes from the fuel system? So you'd have two options like:

:checkbox: Allow early game drones
:checkbox: Drones use drone-fuel (and hide the T_D fuel setting)

?

i was only thinking about the fuel itself (name, fuel capacity, fuel usage) -> set and change in T_D
and about the machines and recipes to make fuel -> always done for drone-fuel only.

these latter machines and recipes then would still be included in the map and do no harm, but simply produce nothing useful if you change the fuel name in T_D, and there would be no need to deinstall the mod (which would cause items, machines and recipes to be deleted automatically) for testing something, or temporarily using different fuel types.

i completely had forgotten the changed recipe for the drones (usage of cylinders) ...

and yes, something along the lines of your two checkboxes looks nice (without having thought too much about it). the first would modify the drone recipe, but please not forbid (deleting them from the map) spare cylinders and assemblers that make them, in case you want to switch that option back and forth for testing.
the second checkmark might better be "drones always use drone-fuel" with a tooltip like "drones will ignore the fuel name that is set in T_D. when this option is off, drone-fuel can still be produced, but the used fuel type depends on settings in T_D" to make it clear which fuel is used and the settings from which mod are used for the drones.
in case you someday decide to have different defaults for the fuel capacity and the amount of fuel used, this could easily be changed by having new settings of your own and a slightly different tooltip like "drones will ignore all fuel parameters like name, capacity and usage that are set in T_D. when this option is off, drone-fuel can still be produced, but all fuel related parameters are taken from settings in T_D"

the difference to your second option would be that you probably can't dynamically change/hide one mod setting by toggling another mod setting; and if it would be possible, users would need to remove the checkmark, restart the game, change the fuel type, and restart yet again. thus better to not hide the option in T_D, but only have the checkmark with a tooltip in your settings (that says it has priority over T_D parameters when enabled).

hehe, a good UI is probably most often more complicated than what the product does
when knowing what T_D does and what your mod does, and how to use them, both mods are fine already ...