What would make the game easier to mod?

Started by Tynan, June 10, 2016, 04:01:27 PM

Previous topic - Next topic

Jaxxa

Quote from: sirgzu on June 12, 2016, 06:47:51 AM
Quote from: SmartererThanYou on June 11, 2016, 04:50:07 AM
Quote from: sirgzu on June 11, 2016, 04:04:49 AM
The ability to re-order mods by load order or manually in the mods page.
The ability to save a mod list presets.
I could be reading this wrong, but wouldn't  the ability to save a mod list be in the ModsConfig?

I'm not sure what you are referring to. Here is the sample use case:

- I'm playing a game with 15mods loaded
- New shiny mod appears
- Add new shiny mod to existing savegame
- The light bulbs suddendly explode
- The walls start shaking
- Silence
- I start a new game(s) with different mod subset for testing/reporting
- Have to manually reset my ordered mod list before continuing my save is tedious

Sounds like the existing functionality of overriding the savedatafolder folder would be helpful for situations like this. that lets you change the folder / have different profiles for Save games and what mods are enabled. Read the Readme.txt for details on how to set it up.

sirgzu

#16
Quote from: Jaxxa on June 12, 2016, 07:47:59 AM
Quote from: sirgzu on June 12, 2016, 06:47:51 AM
Quote from: SmartererThanYou on June 11, 2016, 04:50:07 AM
Quote from: sirgzu on June 11, 2016, 04:04:49 AM
The ability to re-order mods by load order or manually in the mods page.
The ability to save a mod list presets.
I could be reading this wrong, but wouldn't  the ability to save a mod list be in the ModsConfig?

I'm not sure what you are referring to. Here is the sample use case:

- I'm playing a game with 15mods loaded
- New shiny mod appears
- Add new shiny mod to existing savegame
- The light bulbs suddendly explode
- The walls start shaking
- Silence
- I start a new game(s) with different mod subset for testing/reporting
- Have to manually reset my ordered mod list before continuing my save is tedious

Sounds like the existing functionality of overriding the savedatafolder folder would be helpful for situations like this. that lets you change the folder / have different profiles for Save games and what mods are enabled. Read the Readme.txt for details on how to set it up.

I don't understand how changing save folder will have any impact on what mods get loaded.

EDIT it turns out the so called "savedatafolder" actually holds all sorts of other configuration files, including mod list. I guess the name is misleading.
Thanks for the pointer though :)

milon

Documentation and organization are my biggest wants, but that's already been said (and far more eloquently).

palandus

#18
Additional things that could make modding easier:

1] Create more "parent" classes of existing assets to make adding new assets easier. A good example of this is walls. Currently, a wall is just a "child" of BuildingBase. So, if a modder wants to add in a new wall, they have to figure out what should be included in the "parent" for their wall and what should be included in their "child". If a wall, in Core, had an additional level of inheritance, then adding in new walls would be significantly less difficult to perform (so ... BuildingBase->WallBase->Wall ... rather than ... BuildingBase->Wall).

Other assets that could benefit from this is = Personal Shields (Having a ShieldBase would make adding in new variants of shields a lot easier such as ones that could allow ranged firing from), Flowers (Having a FlowerBase would make adding in new flowers to be grown in flower pots a lot easier), Grenades (Having a GrenadeBase would make adding in new grenade-like projectiles or even grenade launchers to be a lot easier to be done), Beds, Animal Sleeping Spots, Chairs, Tables, Equipment Racks, Joy Objects (Having a JoyObjectBase would make adding in new Joy Objects to be much easier), Sun Lamps (These could inherit the LampBase, or could have their own Base, but either way adding in new kinds of Sun Lamps can be a chore without a better Parent Class), Attachment Things (ie ToolCabinet, VitalsMonitor, MultiAnalyzer, having a base parent for these would make adding in additional Attachment Things a lot easier), Power Generators (Having a base parent for power generation, would allow new types of power to be more easily added), Production (ie Butchers Table, Having a base parent for production tables, would allow new types of production tables to be more easily added), Sandbag (Having a base parent for sandbag-like defensive structures would make adding in new ones with a similar theme in mind to be much easier, ie like adding in obstacles that would slow an advance but provide almost no cover), Turrets, Traps, Ship Components (Having a parent class for things that can only be added to a ship, would allow adding new things for just the ship a lot easier), Temperature (having a base class for Temperature objects would allow adding in new forms of temperature creation/removal, without forcing modders to replace existing assets), Horns (ie ThrumboHorn, ElephantTusk, etc), Implants (Being able to specify slots that implants take up would be very useful and thus having an ImplantBase would be very useful; other interesting implants could be things like dermal plating, cochlar implants, etc), Luxury Foods (ie Chocolate, would make adding in new types of luxury meals a lot easier such as Coffee or Smoked Salmon), and Weather (being able to have a parent for weather could make adding in new kinds of weather to be a lot easier, such as Razorhail (ie Gears of War), or Raining Flaming Dogs (ie Oblivion Daedric Quest for Wabbajack).       

2] Allowing editing of specific "thing" objects that are currently not available to be modded. As an example, allow editing of natural stone walls or natural stone floors. Being able to modify their beauty would be very useful, or their hitpoints to make mining easier/harder would also be very useful.

3] Allowing editing of special effects produced by items. An example are "Neurotrainers". The base object is editable in Items_Exotic but, the effect produced by using a "Neurotrainer" cannot be edited. Being able to edit the effects produced by items, and by proxy, be able to create our own custom effects would be very useful. This is also useful for things like Implants, Drugs, and One-Use items (ie Psychic Lances).

4] Keep all parent classes important for a file in that file. An example is PersonalShields, inheriting from ApparelBase that isn't in Apparel_Shields.xml ... It makes modding a lot easier when all the information needed is found in the same file, rather than having to hunt for the base parent class in some other file. Alternatively, it might be better to include PersonalShields in Apparel_Various.xml, rather than have its own file to itself.

All I can think of at the moment.

milon

+1 to everything palandus has said.

I'd also love a simple way to tweak existing Defs without needing to completely overwrite them (XML approach - I don't do C#).

palandus

Other ways of making modding easier for modders:

1] Create "framework" classes that could be adapted by modders without writing any C# code. To illustrate what I mean by "framework" classes, I'll give an example. Have a framework class that could be adapted to allow modders to add in things like Animal Mounted Combat, Mobile Vehicles, or Stationary/Fixed but Movable Structures (ie a Construction Crane). Any of these would likely take a lot of time to create in C# code, but if there was a framework class that could be used to make these possible, then modders could add in these kinds of things. By having framework classes, it would allow a greater variety of different kinds of mods that could all share from a basic framework class without requiring C# knowledge. Currently, if you want to add in something that doesn't have some kind of code already existing, you need to do it in C#. By having different kinds of framework classes though, would allow more modders to be able to create interesting mods without ever needing a single line of C# code to do it.

So the above example could be a "mounted or piloting" framework class. Other kinds of framework classes could be: "incident" framework class, "animal armor or barding" framework class, or "starship component" framework class, that I can think off of the top of my head.

2] Provide an effective way of disabling or removing a gameplay feature. An example is for traits. Setting a trait to 0.0 probability, doesn't actually mean 0.0 probability; it can still show up its just super rare. So, if we wanted to disable a trait currently, we'd have to make other traits have much higher probability (generally above 1.0, though higher is better) to prevent traits from appearing. Its an inelegant approach but it works. Merely deleting things from a file also doesn't necessarily prevent the feature from occurring. But, if we had an easier way of disabling or removing a gameplay feature, that would be very useful for modding. Unless of course those things I mentioned are bugs, and setting to 0.0 is supposed to disable it.

3] Explain how to properly create comments in a file and how we should comment out code temporarily that we don't want. In C++, you can comment something by either using // or /* and */. However, I'm not entirely sure how to comment things in C# or XML, and thus knowing how to do this would be very useful, at least for me.

4] Provide code hooks for assisting in debugging purposes. In C++, you can in console-based programs use "cout" to display a message when that line of code is implemented. It could help us in finding specific logic errors in our xml, which may not be detected by the ingame debugger that generally only detects runtime errors.

Again, all for now.

cuproPanda

Quote from: palandus on June 13, 2016, 03:44:15 AM
Other ways of making modding easier for modders:

1] Create "framework" classes that could be adapted by modders without writing any C# code. To illustrate what I mean by "framework" classes, I'll give an example. Have a framework class that could be adapted to allow modders to add in things like Animal Mounted Combat, Mobile Vehicles, or Stationary/Fixed but Movable Structures (ie a Construction Crane). Any of these would likely take a lot of time to create in C# code, but if there was a framework class that could be used to make these possible, then modders could add in these kinds of things. By having framework classes, it would allow a greater variety of different kinds of mods that could all share from a basic framework class without requiring C# knowledge. Currently, if you want to add in something that doesn't have some kind of code already existing, you need to do it in C#. By having different kinds of framework classes though, would allow more modders to be able to create interesting mods without ever needing a single line of C# code to do it.

So the above example could be a "mounted or piloting" framework class. Other kinds of framework classes could be: "incident" framework class, "animal armor or barding" framework class, or "starship component" framework class, that I can think off of the top of my head.

2] Provide an effective way of disabling or removing a gameplay feature. An example is for traits. Setting a trait to 0.0 probability, doesn't actually mean 0.0 probability; it can still show up its just super rare. So, if we wanted to disable a trait currently, we'd have to make other traits have much higher probability (generally above 1.0, though higher is better) to prevent traits from appearing. Its an inelegant approach but it works. Merely deleting things from a file also doesn't necessarily prevent the feature from occurring. But, if we had an easier way of disabling or removing a gameplay feature, that would be very useful for modding. Unless of course those things I mentioned are bugs, and setting to 0.0 is supposed to disable it.

3] Explain how to properly create comments in a file and how we should comment out code temporarily that we don't want. In C++, you can comment something by either using // or /* and */. However, I'm not entirely sure how to comment things in C# or XML, and thus knowing how to do this would be very useful, at least for me.

4] Provide code hooks for assisting in debugging purposes. In C++, you can in console-based programs use "cout" to display a message when that line of code is implemented. It could help us in finding specific logic errors in our xml, which may not be detected by the ingame debugger that generally only detects runtime errors.

Again, all for now.

For 3: XML uses <!-- for opening and --> for closing, C# uses // for single-line and /* for opening and */ for closing

For 4: Log.Message, Log.Error, Log.Warning, etc. all work, depending on your need.
cuproPanda's Mods: Survivalist's Additions, Additional Joy Objects, Cupro's Drinks, Quarry, Cupro's Stones, Zen Garden, Cupro's Alloys, Preset Filtered Zones, & more!

palandus

#22
Thank you Cupro, didn't know that. Appreciate knowing that now though :)

Other things I can think of:

1] Create new systems that allow for different kinds of mods that currently are impossible to do (AFAIK).

For example, have a system that allows us to create "Room Prefabs" as illustrated by this process = 1) Create a room, with furnishings, 2) Save the layout of that room, 3) Be able to then place that room anywhere we want as if we had manually placed down each tile, 4) Allow us to then export that layout and upload it as a "Room Prefab", and 5) Allow users to download these "Room Prefabs", import them into their games, and then build these "Room Prefabs". So, then this would open up a new form of creative modding where people could make interesting rooms or kill boxes or interesting base layouts, and then share those things as "Room Prefabs". Also, it would allow players who frequently build their bases the same way everytime to save time by just placing a "Room Prefab". An example for me is that I like to have simple 5x5 bedrooms for colonists, and if I didn't have to manually place all the various furnishings, walls, etc... it would allow me to figure out room placement faster. This would also allow users who aren't very creative themselves and would love to have interesting looking bases but don't know how to do it themselves.

2] Include all the game textures with Core for easy access for modders. It would be simpler than making requests for them. If you don't desire to release all the textures for legal reasons, then how about just release the commonly used textures such as weapons, furnishings, and other things you might be willing to include.

3] Allow multiple objects to be keyed to a keybinding. When you hit this keybinding, it could bring up a smaller menu, which would allow you to choose which object you intended to build. As an example, in some mods it adds a lot of turrets. So, if all turrets were bound to the same keybinding, hitting that keybinding would bring up all the turrets assigned to that keybinding, allowing you to quickly place the desired turret without going through the Architect Menus. Basically, by doing this it adds an additional layer of compatibility as currently only a single object can be keyed to a single keybinding.

4] Explain in very clear terms what each AltitudeLayer can or cannot have in it, and which layers are available. If modders understood the AltitudeLayer(s) better we might be able to create interesting mods utilizing this to make a quasi 3D gameplay with limited "z" direction modding. An example, would be having a helicopter like gunship being on a different layer, than the ground layer, to allow it to bypass obstacles like walls, but not mountains. Another example could be where you could build special "high walls" that prevent mortars from passing through and instead the mortar collides with the wall instead; this would mean likely having a hole punched in your wall, but it would prevent shelling of your structures/colonists on the other side of that wall. Assuming of course that this is what Altitude layers does of course :)

5] Create a framework class that allows randomized destruction of terrain, within a set radius. This could be then adapted to create Earthquakes, Large Meteor Impact, Meteor Showers, Long-Range Mortar Bombardment, among other things.

6] Create a framework class that allows randomized creation of terrain, within a set radius. This could be then adapted to create Landslides, Avalanches, Spontaneous Growths of Plants, Underground Spring Explodes Creating a Lake, among other things.

Hmm, all for now.

=====
EDIT: More stuff; rather than double posting! These may or may not be things that are "general" at making modder's lives easier, but in the grand scheme of things (I think) it would make it easier on modders.
=====
7] Implement code for new damage types that do things that current damage types do not. This will allow modders more "tools" for creating interesting new weapons and effects. As it isn't currently possible (AFAIK) to add in completely new DamageTypes (can make modifications of existing DamageTypes or combine existing DamageTypes to make a new DamageType, but not make uniquely new DamageTypes), that's why I'm mentioning it here. A lot of these would also make defending a mountain fortress very hard as their intent is to "flush out" defenders from an entrenched position. Example new damage types:
- Blind = Temporarily causes complete blindness and applies a thought-based debuff "I'm Blind!". Would make a Flashbang quite possible.
- Concussed = Temporarily causes deafness and temporarily reduces action speed. Could be caused as an after-effect of being too close to an explosion, or say a Concussion Grenade.
- Fear = A damage type that is used to not deal damage, but to cause "Thought"-based debuffs instead. Could make for an interesting alternative to damage-dealing attacks to deal with Raiders.
- Mind Control = A temporary effect that causes the target to become friendly to your faction (ie if the raiders used it the target would be friendly to raiders), and suffers a large debuff to thoughts after the mind control wears off.
- Sickened = A damage type that is based on smell that causes targets to have an uncontrollable urge to vomit. And as well, you can't fire or do other actions while vomiting, it can be a potentially devastating damage type if used properly.
- Suppressed = A damage type that causes targets hit by automatic weapons to move slower, but also gain passive "cover". This damage type would be useful for users using Miniguns or LMGs to prevent melee attackers from closing the distance, and adding a new level of strategy to gameplay.
- Smoked = Produces a cloud of smoke that makes breathing difficult and obscures vision. Great for providing some concealment from snipers, or to "smoke out" defenders in tightly confined spaces.
- Gassed = Produces a cloud of harmless gas that causes targets not wearing protective headgear to fall into unconsciousness. Makes for a great way for clearing out defenders.
- Hallucinogenic = Makes a target hallucinate, causing temporary mental breakdown until the effects wear off, when the target acts as if nothing happened.

8] Implementing damage to Bionic Limbs and colonists use Repair Skill to "heal" the damage. This would help modders as balancing new prosthetics is difficult as a Bionic Limb is either fully healed or destroyed and thus the modder must figure out what is the right balance of crafting limbs or distributing limbs via traders. If Bionic Limbs could be repaired, then it could help by making investing in Bionic Limbs very useful especially if you have a character with high Repair skill. It would also help as natural limbs already have HP, and it would make sense that Bionic Limbs would have greater HP as they are built sturdier as well.

9] Making each slot on the body separate from eachother. This would allow for Shoulder bionics that don't fully replace the Arm (ie a Shoulder Mounted Railgun like in Quake 4), or Torso Bionics that don't fully replace the entire body. Thus by doing it like this, it allows modders much more flexibility in creating Bionics, as in this situation, a Colonist could have a Bionic Hand, Bionic Arm, and Bionic Shoulder, that each could provide different benefits or penalties. As it currently stands, it limits the modder's creativity and the amount of different kinds of Bionics.

10] Make modifications to the "Combat System" (this is more a request rather than helps modders; well it does, by unlocking a variety of new possibilities, but also adds more complexity to the game as well). I'd love modifications to the "Combat System" to add more strategic gameplay to Rimworld; a lot of the previous patches has focused on the simulation gameplay, and I hope either you, Tynan make changes to the "Combat System" or make it possible for us modders to do it. So the suggestions are:
- Add a Stance Option; Sniping or Standard or Spraying = When sniping, your rate of fire is decreased but your accuracy is greatly increased. When spraying, your rate of fire is increased but your accuracy is greatly decreased. Standard is a balance of rate of fire and accuracy, and is the default stance to choose from. This would allow a new strategic level to gameplay where in close quarters you could set colonists to Spray, and in long-sniping battles, set to Snipe, and somewhere in between, stay in Standard. It would allow modders a new system to tinker with and when creating new weapons it would help us in determining weapon stats.
- Implement a "Clear the Room" mechanic for anyone wielding a "Grenade" type weapon = Anyone with a grenade equipped can approach a door, squeeze it slightly ajar, and toss a grenade into the room. This would make battles in tight confined spaces very dangerous and make defending your mountain fortresses a lot more difficult, while at the same time, colonists can use the same tactic to toss grenades out onto targets on the other side of the door as well. It would help modders by making grenade type weapons very useful, from deadly Frags/Molotovs, to possibly nonlethal Flashbangs/Concussions. This tactic would only work on doors or non-powered auto doors for enemy grenadiers, and work would no matter what for colonists. It would encourage modders to take Grenadiers in mind when designing defenses, doors, walls, turrets, etc... as Grenadiers could pose a dangerous threat to colonists hiding behind a door, but in a confined space.
- Implement a "Breaching Charge" carried by "Raider Sappers". These can be placed on Walls or Doors, and have a 10 second fuse, can be disabled by colonists and if not disabled will often destroy the Wall or Door in a single blast (maybe not Blast Doors from GlitterTech mod, but I digress). Thus, it can provide an alternative way for sappers to get into your base by blowing up your main door, making defending a mountain fortress that much more difficult.
- Implement a system that causes explosions from grenades or rockets to cause the roof to collapse in the square that is the center of the explosion. This then would make explosive type weapons extremely dangerous to use in Mountain Fortresses or even within buildings. If the roof collapses in a Mountain, it creates Collapsed Rocks in that square, and can be cleared away as long as there is sufficient supports nearby as normal. If its a building, it just opens up the building to the outside, forcing a colonist to repair it when they have a chance. If opening the roof up for a building is too difficult then skip that. This would help modders in designing mods for helping defenders survive in Mountain Fortresses, such as creating new mods like Ceiling Supports that prevent cave-ins within the area, while in general making Mountain Fortresses that much harder to defend.

11] Implement a plastic/cosmetic surgery set of recipes that allows the removal of scars, old wounds, and other such "damage" to limbs/organs/body parts. I know there is a C# mod that does this, but it would be so much more elegant if implemented directly into the game; especially as then it could be adapted to work on removing the same kinds of "problems" from animals too!

======
EDIT: More stuff!
======

12] Break "death thoughts" into how the target died rather than just "saw friend die" or "saw enemy die". So, by doing this, a modder could set up a special death thought for if the target bled to death, was disemboweled by a chainsaw, eaten alive by an animal, or blew up with a grenade. This would be useful as different "deaths" could affect others in more or less demoralizing ways. Seeing your friend disemboweled by a chainsaw is sure to be more traumatic than seeing your friend shot in the head with a rifle and dying instantly.

13] Provide code to allow "ranged" weapon bionics, in addition to "melee" weapon bionics. So right now, we have a Scyther Claw as a "melee" bionic. If "ranged" weapon bionics were possible, then something like a "wrist laser" like those androids had in Star Wars 1/2 would be possible. A target thus "equipped" with a "ranged" weapon bionic would have this attack in addition to whatever weapon carried by them, thus allowing for multiple "ranged" weapon bionics being equipped. Currently the code doesn't allow "ranged" weapon bionics.

14] Create code that allows a colonist or raider to have two equipped weapons that can be swapped between eachother, depending on the situation. So, what this would allow is to have say a long-range weapon equipped with a short-range weapon or melee weapon for close quarters. In order to swap to the other weapon, it takes them a short period of time to perform the switch (not instantaneous to allow melee attackers a few hits before the target could switch to their melee weapon). This would open up many opportunities for interesting weapons and as many weapon packs introduce tons of new weapons but yet, colonists/raiders can only equip one item, it might lead to interesting weapon combinations resulting from this change.

All for now!

Tynan

Thanks for all the suggestions. I am applying some of these now.

Palandus - a lot of your basic organization suggestions could be solved with a grep tool on your end. E.g. if you want to find a Def parent, just grep Name="WantedParentName" and you'll have it in a moment.
Tynan Sylvester - @TynanSylvester - Tynan's Blog

mrofa

Palandus this stuff is  already in, all you need is to look
1. fluffy prapobly relesed it already.
2. is on help forum sticked topic along with a way to extract them from game files
3. dat is interesting material for a mod <-- fluffy get your ass to work :D
4. all you need is to ask on forum, becouse many moders do understand the  altitude system :)
5. this an be easily moded, ask on forum
6. same as above
7. can be done via xml only, use hediffs
8. current system is better, you have to use a set of items to boost your chance for various outcomes.
9. alredy exist in vanilia if i remmber correctly.

Dat is not for discoragment, since you always can find something helpfull in wall of text.

Tynan this is more of theory request which i dont know if its possible or logical in sane brain :D

Altitudes would have another variable setting, using cell horizontal rows on map cell grid, counting it from vertical bottom to top.
Each row would represent a number so the most bottom cell row would start from 0 and so one up to max vertical map size.
If this could be use for Draw() as priority draw, this would work well with already implemented <drawSize>, allowing textures with lower priority and lower altitude to be actually draw on textures with higher priority and higher altitude like walls.

Also something more possible is to add additional altitude layer between waist and wall, and wall and pawn, if you feel generouse more in general :D



All i do is clutter all around.

Tynan

Just to be clear here, I'm not going to implement entire big new game systems for this.

I'm asking for simple changes that would make your lives easier - not "whatever would be best, regardless of the cost". Please suggest things that are simple to change. Like, "make this method virtual". Or "don't hardcode this interaction".
Tynan Sylvester - @TynanSylvester - Tynan's Blog

palandus

#26
Ahhh. Okay, then I'll provide a list later on simple changes (currently on iPad so typing too slow for me).

Never heard of grep tools. Can you suggest a good one?

1. Make turrets target animals trying to eat colonists or pets. Really irritating having a hungry warg come in, attack a colonist, when there are turrets within range but don't target it. Unless that is a bug.

2. Make all experience gains from performing activities (ie mining rock) and in performing joy activities editable.

3. Make all factors that determine a hit or not (ie range, light level, double cover, and fog) including existing factors (ie skill or weapon accuracy) editable.

4. Allow attack speed to change based on skill level. Could default to 1.0 for base game for each skill level.

5. Make flash freeze and heat wave max/min temperatures editable.

6. Make biome temperatures editable as well as being able to edit temperature modifiers caused by height, rainfall and distance to North pole.

7. Make the variables that control plant spreading/seeding new plants to new squares editable, as well as have unique values for different plants (ie grass should spread faster than trees), and make ideal growing temperatures editable.

8. Make the variables controlling the fire spreading formula be editable, able to edit how quickly fire grows or dies, the amount of heat produced per tick or 100 ticks by each stage of fire growth, maximum temperature reached and how quickly rooms cool off when fire goes out.

9. Make the distance from walls/doors to support ceilings be editable.

10. Make the amount of fire put out by beating it be editable.

11. Make the variables that control how a pawn acts when on fire, including movement speed and actions performed when on fire to be editable.

12. Make it so that when prisoners break out we can modify what they can or can't do in a breakout. Such as controlling how many doors they can open up so that breakouts are a bit harder or easier, and thus may have to physically destroy doors to escape.

13. Make the variables that controls raid size, raid unit composition and waiting time before attacking editable.

14. Make it so that crafted item quality ranges are directly affected by skill level only, such that a modder can choose that at 20 skill it is always legendary rather than a range of values, as an example.

15. Allow moddders to finely tune relationship code so that we can choose to have say a nymphomanic colony where anyone will bed anyone regardless of relationship or perhaps a colony of religious fundamentalists that only bed each other after being married. Having full control over variables controlling relationships would be useful.

16. Make it possible to remove mountain roofs particularly for mountains that can be fully dug out.

17. Allow editing roof collapses to either make them more severe or less severe.

18. Allow editing of ancient ruin contents so that modders can decide how many caskets inside, how many artifacts inside how often mechanics spawn inside and how large they can be.

19. Allow modders to decide if they want old wounds/scars to spawn on new pawns or be created at all, or perhaps to make them more severe.

20. Allow modders to control incapping defaults for races and incapping chances when suffering different kinds of wounds. Ie a shot to the eye would cause greater incap chances that being shot in the leg)

Will add more when I think of them.

cuproPanda

The new animals remind me, it would be useful to be able to define custom SpecialProductTypes. Currently there isn't a way to add in bones being given via butchering, and depending on the usage, a custom SpecialProductType would allow for greater flexibility with recipes. I know there are a few variables to consider, but I'm hoping that fits into the category of a simple change.
cuproPanda's Mods: Survivalist's Additions, Additional Joy Objects, Cupro's Drinks, Quarry, Cupro's Stones, Zen Garden, Cupro's Alloys, Preset Filtered Zones, & more!

Lupin III

More from the players perspective (as I'm not really a modder):
1. Show an indication, which mod added (or changed) a certain item. With many mods installed it can become difficult to know where a certain order, recipe, item, aso. is coming from and makes it harder to debug problems. The game "factorio" does that quite well.
2. I don't know if it's just bad mod design or just not possible currently, but mods should be able to add orders/commands/items/UI items without completely overwriting anything that a mod loaded before that already added.

palandus

I agree with Cupro, having a special product type definable by modders during animal butchering, or even mechanoid butchering would be very useful. A potential application for human butchering would be able to take out all the still fully functioning organs and reuse them (organ donor style).

I agree with Lupin III, for both 1 and 2. It would be very useful for debugging purposes to know which mod or mods modify which entries in the game. It would also be useful if instead of replacing existing orders, recipes, etc... it would add to the bottom of the list, as long as the old recipes aren't touched in the file... so in C++ terms, have those orders, recipes, etc... "append" to the end of the file, rather than replace the entire contents of the file. That way multiple modders could add recipes without having to make a brand new workbench to have those recipes.

Other simple changes I can think of:

1] I'm not entirely sure if this is currently possible in the current system so mentioning it here. Being able to dictate what kinds of filth are produced by people/animals as a result of performing some kind of activity. Personally, I'd love to see "sticky white stuff" left behind after a couple does their thing. Or "water puddle" after an animal pregnancy. Or angry prisoners flinging "brown stuff" at the walls. That kind of thing to help boost immersion. If that currently isn't possible, could you make it possible.

2] Allow modders to modify behaviours of manhunter animals, and give unique behaviours to different animals when in manhunter mode. As an example, modders could make wargs focus on corpses already on the ground first tearing all flesh from them before moving on, while elephants will try to break down doors to get at the humans inside.

3] Allow modders to modify behaviours of drop pods. Allow modders to decide if they can drop inside a mountain fortress or burst through roofs in general, and other properties of drop pods such as drop pod "movement speed" and other characteristics.

4] Allow modders to modify behaviours of orbital beacons. Allow modders to decide if they can receive resources inside a mountain fortress or burst through roofs in general, and other properties of resource pods such as resource pod "movement speed" and other characteristics.

5] Allow modders to add or remove roofs based on a structure placement. For example, have the equivalent of missile silo blast doors that open up, and thus expose that area to the outside when open and when closed, it is closed. Being able to remove or add ceiling in this manner could make underground fortresses viable for even orbital beacons.

----
Other Suggestions = Probably not simple to implement, but mentioning them anyway.
----

1) Give the player the option of refusing to allow wanderers to join the colony. Its really irritating having a wanderer with cataracts, bad back, non-violent, and can't perform most skills anyway joining the colony. It would be better if we could look at their skills tab, much like when buying slaves or choosing your first 3 colonists and decide if we want them or not. If we don't then they wander in and wander out after a period of time. If we do want them, they stay with the colony.

2) Give the player the option of seeing what this "fleeing" pawn from raiders, what their skills are like. Getting a cataracts, bad back, non-violent, and can't perform most skills anyway to get a raider group as well, makes me usually ignore most requests as I don't want the double risk of bad colonist and bad raid. If we could see their skills before we accept their request, it would make it easier to weigh the risk of letting them join or not.