Schall Primary Battery


Adds non-rechargeable battery equipment, which can be crafted in the early game, and much cheaper than portable solar panel in short-term. Options on enable grid to early armours. Designed for “Schall Recharging Weapon” mod or as backup power to equipment grid. (Locale: English, Deutsch, 正體中文, 简体中文, Português Brasileiro, Русский)

Content
3 years ago
0.17 - 1.1
2.34K
Armor

i [Responded] "partial incompatibility" with Klonan's Construction Drones (Not my problem)

4 years ago

when using this mod and https://mods.factorio.com/mod/Construction_Drones both mods try adding a grid to the basic armors, resulting in only having the grid from this mod active and thus not being able to insert the bot controller (that the construction drones require and thus don't start working) into light and heavy armor unless i disable the option to have a grid at all in the mod options of this mod.

it would be nice if you could make the two mods compatible, eg by allowing the drone controller (a small 1x1 item) into your grid.

4 years ago

Maybe I will add another option to simply append equipment category to detected grid of the basic armors, without doing any changes to grid size. Is that enough for your purpose?

If simply appending equipment category is not enough, then need to wait for when I have time to properly explore "Construction Drones".
I have never played with "Construction Drones". Just explored into Klonan's code, but from the pile of "spaghetti" code, I am not successful in finding any lines related to equipment grid. Not even name of the grid types or grid size.

4 years ago

New version 0.17.1 provides an additional option to just "append" category of the primary batteries to existing grid, instead of replacing with my 4x2 grid.
If the grid size comes too small, perhaps you should ask Klonan to change the size or provide the "append" option instead.

4 years ago
(updated 4 years ago)

thanks for this attempt, but (having not tested it yet) i can only guess now:

in the old version of this mod, you replaced the gridsize as well as the category and thus we ended up with your larger grid but without the drone controller enabled for it. if the "random" loading order and similar effects still work like before, your grid (when set to "enabled") probably replaces the other smaller grid and appends the category which would make it work almost perfectly (grid could hold four 1x2 batteries, or 3 batteries and one 1x1 controller).

is this assumption correct? (since the "enable" option in the short tooltip only says "enable grid to early armors" and does not mention whether the category is added or replaced or unchanged).

it looks as if the problem should be fixed for now (until someone uses other mods with yet some other sizes and/or categories :-)

AND NOW ALSO TESTED :
"enabled" - enables your grid, but replaces categories :-( thus disables the use of drones
"append" - allows both categories, but uses Klonan's small grid :-( thus can't use batteries
for users it probably would be most useful to have two checkmarks, one to enable/disable your grid (without changing categories), and one to enable/disable appending categories (keeping the gridsize). i don't know about possibilities in the API, but can't the gridsize be read by the API, and/or can't only the gridsize be changed without deleting the old grid (and all its options/categories) ?

4 years ago

First of all, let me explain the definitions in API.
An armor item prototype may or may not have an grid prototype assigned. Modular armor and power amors have been assigned to different grid prototypes. Vanilla light armor and heavy armor do not have this.
My "enabled" option set it to my own defined "Schall-early-equipment-grid". Klonan's mod set it to another prototype. There can be only grid prototype assigned to each armour. That's why the conflict comes.

Next, a grid prototype has 3 properties: name, grid size, and equipment categories.
My grid has name "Schall-early-equipment-grid", size 4x2, equipment categories = {"armor-early"}.
Klonan's mod has different name, size 1x1, equipment categories to the controller only.
My "append" option does not add my grid prototype, but simply detects the existing one (i.e., Klonan's grid prototype) and append category "armor-early" to the existing grid equipment categories.

So it would not be useful to have both options allow enabling at the same time. It would just append "armor-early" to my own grid which already has it. Does totally nothing except for complicating things.

What you want is a grid with size 4x2 and equipment categories set to allow both. (The grid name you probably don't care, but for modders it IS important.) The grid size reflects modder's opinion on the role of armours, so is the core property.
Changing the core property of another mod means I disagree its settings/balance. I feel it is a RUDE thing to do, unless I explicitly stated that this is an adaptation/customized mod, where players do their own fine-tune to large mods like "XXX for Bob's mods". This mod, however, is not this type of adaptation/customized mod.

So the better (and polite) way would be to request changes from Klonan's side, as suggested in my last reply. Or at least have permission from Klonan to change the grid size if done from external mod.

If the grid size comes too small, perhaps you should ask Klonan to change the size or provide the "append" option instead.

4 years ago

thanks a lot for all the details. even when i don't program mods myself, it was really helpful to better understand how grids work, eg in case of conflicts like this or when using other mods that use grids.

i understand your opinion on rude vs polite changes, but since currently your settings seem to override Klonan's (why? because "Schall" is sorted after "Construct" ?), would it help at all when he appends his categories to your not yet added categories? wouldn't that also require his mod to enumerate your mod as optional dependency? and if you would do the change to the gridsize, wouldn't you have to name his mod as optional dependency to be "on the safe side" if mods by default should be sorted differently someday? and isn't it also some kind of "rude" when your mod changes the gridsize and replaces his categories, thus disabling his bots without listing his mod as "incompatible"?
lots of questions which show that planning often is a lot more complicated than programming itself :-) :-(

i think that both of you have the same motivation for your grid sizes: to balance the early armors and not make them overpowered. thus he just adds the minimum size 1x1 that is necessary for his mod to work, just as you add a grid with size 4x2 for only 4 batteries. maybe the best solution would be to have a set of API functions to check the current gridsize, change the current gridsize, or even "somehow" allow to list which items a mod wants to add (and which size they have/need) and then automatically find a new layout for the grid that matches exactly :-)

i think that such an automatic "grid-layouter" will never (at least not before factorio 2.0 or 3.0) be implemented in vanilla, and thus mod authors have to live with the rude/polite problem. btw: aren't there other mods which just add some kind of grid to ALL vehicles so that people can add new functionality to any vehicle? maybe some other mod could do the same for the early armor and then both of your mods could add their categories if a min size of xxx is detected (grid size would have to be set by users in that third external mod)?
of course, that might again add more problems eg with the loading order of all those mods.

4 years ago

Of course, there are many methods to give the same outcome. by changing load order and all those override stuff.
But honestly I think setting load order would be a poor solution, especially when the subsequent mod(s) come in adding/modifying to early armours. For example, player A1 uses mod A and this mod, while player A2 uses mod A and Klonan's mod, player A3 uses all three... So should mod A tries to "line up" in a "proper place" in the load order? When another mod, say mod B, kicks in... Player B1 uses mod B and this mod, player B2 uses mod B and Klonan's mod, player B3 uses these three, player B4 uses these three AND mod A, ... Gosh! There are endless combinations, when more mods kick in. Using load order and override will initiate a vicious chain of "line up" in load order, while what needed in most of these mods are simply:
1. Appending the category to any existing grid. Or
2. Create a grid, since there is no existing grid. (Or allow player to choose which mod creates the grid.)

IMO, using load order is good only for when there are obvious prerequisite chain. (Like my Tank Platoon introduced basic, MK1 and MK2 tanks. Alien Tech introduced MK3 tanks. Obviously Alien Tech needs Tank Platoon in the dependency list.) (Example two would be my Alien Loot and Endgame Evolution: the enemies in the latter mod drops loots if earlier mod is enabled; but still can work without it. So gets the optional dependency.)
But for mods doing similar but different things (like in our case, both can be powered by early armours, but doing irrelevant things), there are no obvious prerequisite relations between the mods.

So still, I think the "most simple" way would be allow setting grid size (say, from 1x1 to 4x2) as an option of Klonan's mod. Such one simple option in Klonan's mod can avoid all those load order and override mess. Have you ever tried such a feature request?

Or even better, should ask Klonan for providing the "append" option as well. Perhaps there will be a third (and fourth, ...) mod that we are unaware, may also try to do something to early armours. Current status of Klonan's mod will not be compatible to them anyway.

4 years ago
(updated 4 years ago)

Klonan's mod only has one item for the early armor, thus he adds a grid of size 1x1 to early armor that has no grid at all. besides the dev bonus of having more important things to do, i don't know why anyone should extend their mod with such additional (not directly related) functionality of setting up grids of any user selectable size, which costs time and effort to do.
if he would simply overwrite an existing grid with a smaller grid and/or replace existing categories, that's what i would consider to be a bug that needs to be fixed.

on the other hand, your mod wants to modify the size of the grid and add categories to it. the part to add categories works perfectly, but you only adjust the grid from non-existing (vanilla, 0x0) to a larger size (4x2) and don't want to touch any other existing gridsize (eg 1x1 grids). thus a request similar to the above sounds equally (un)reasonable to me: you should include an option in your mod to automatically extend the existing grid so that it also fits your items, or even better (🤪😇 :-) where people can select a grid size that they like with mod options and all that stuff.

without an easy vanilla method to create and adjust grids to suit several mods, it can get quite complicated. maybe the best would be (although i don't know whether that would be possible at all) to have a new vanilla option or a mod that is executed first, that sets any gridsize for the early armor, and then any other mod can later add its own categories to such an existing grid. for vehicles i have seen some similar mod, but not yet for (early) armor. if i could use such a mod to set the grid to 4x2 (or maybe 5x2 to allow for four 2x1 items and one 1x1 item), the problem would no longer exist, and whoever changes the grid to a smaller size afterwards has to fix his bug.
i don't know whether Klonan's mod would overwrite (and that would be a bug) grids from other mods like yours or such a new "basic grid" mod since his grid seems to be the first and your mod then acts/appends on the existing grid.

ps: while having this discussion, i played my map for a while and got more and more annoyed by the derpiness of those mini-bots (sometimes even more stupid than biters). they often get stuck in the factory (and i even didn't start yet with oil production and pipes) since they can't fly, and also block the path of other vehicles while trying to repair them, causing even more damage to and by the other vehicle trying to pathfind around them (one minibot even was destroyed by that). the biggest advantage of them is their cuteness :-) but because of their problems i will now replace them with nanobots, and thus I'll be able to fully use your mod without any grid conflicts.

4 years ago

I still think this is Klonan's mod haven't considered compatibility (not just my mod but potentially many other mods as well). I don't understand why you insist not to let him know.
I have clearly made my statements, so not going to repeat them again.

Also, you assumed Klonan has more important things to do, but other modders have plenty of time?
I have already devoted most of my free time on Factorio modding this half a year, but not even start a 0.17 game for trying the new science balance. Plus, I am busy these weeks to apply for new job. So I am not really in mood to do things not really related to me.

New response