I'd like to make the game easier to mod, but it's hard to tell, from my perspective, what would be the most useful changes to make to make this happen.
So I'm soliciting requests.
Just try to think of the most important things you'd want that would make modding easier for you. I'll aggregate the suggestions and try to implement the most cost-effective and popular ones.
Thanks all!
-----------
Edit: The difficulty here seems to be that there are a ton of requests - everyone has their own little thing they want changed. Unfortunately we can't cover all these; I really want to make the changes that will have a big impact on a lot of modders. Bang for your buck, so to speak.
So it would be really great if modders could discuss and come up with a top-3 list of things that would help a lot of people at once. Consider this an invitation to discuss with each other what would help you all together.
Easier access to vanilla textures, as well as something akin to bethesda's creation kit
It would be nice to have a common injection point for code, similar to [StaticConstructorOnStartup] but more of [MyDLLEntryPointHere] which would happen before the xml is loaded.
I know it is a far call, but in case of changes, a sort of converter from old XML parameters to new ones would be a nice thing to have. Of course it is not something necessary, only very handy. Would save a lot of time in mod updates during alpha transitions, if such a program existed.
Quote from: 1000101 on June 10, 2016, 05:13:00 PM
It would be nice to have a common injection point for code, similar to [StaticConstructorOnStartup] but more of [MyDLLEntryPointHere] which would happen before the xml is loaded.
Can you be more specific?
Quote from: Plymouth on June 10, 2016, 05:13:37 PM
I know it is a far call, but in case of changes, a sort of converter from old XML parameters to new ones would be a nice thing to have. Of course it is not something necessary, only very handy. Would save a lot of time in mod updates during alpha transitions, if such a program existed.
That would be a massive and ongoing project, so I'm afraid it's a bit out of the cards. I'm really looking for simple things that'd be useful forever.
Quote from: Tynan on June 10, 2016, 06:12:31 PM
Quote from: 1000101 on June 10, 2016, 05:13:00 PM
It would be nice to have a common injection point for code, similar to [StaticConstructorOnStartup] but more of [MyDLLEntryPointHere] which would happen before the xml is loaded.
Can you be more specific?
Currently, StaticConstructorOnStartup is called for generic classes at the end of PlayDataLoader.DoPlayLoad(). It would be useful to have a similar attribute which could be applied to a static constructor to be called as the first step in sequence.
The ability to re-order mods by load order or manually in the mods page.
The ability to save a mod list presets.
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?
The Detours from CCL are quite handy, although I don't know if you will want to officially support that.
----------------------------
I have written up my ideas for the mod manager in the suggestions forum.
https://ludeon.com/forums/index.php?topic=20662.0
The main ideas are being able to Reorder mods, and have XML tags in mods listing what other mods they depend on. Then warn if those mods are Not Installed / Are Disabled / Are Later in the Load order. I think this would make more complex mods with dependencies easier for new players to work with.
Feel free to ask if you want me to explain how I think it could work in greater detail.
----------------------------
A minor thing that would be nice, In C# code I would like to see the Protected and Virtual modifiers be used more often instead of the Private modifier as I find these make creating derived classes easier.
When I was initially modding the Plant Class I wanted to change the Growing Times. I inherited from the base class, then ideally I could have just overridden the Resting Property, but it was not Virtual so I had to override the Tick function. That then references a Number of Private Properties / Functions that I had to reimplement in my derived class, if they were protected I would have been able to call the ones in the Base class.
I ended up finding a better way to do this using CCL Detours.
Quote from: Tynan on June 10, 2016, 06:12:31 PM
Quote from: Plymouth on June 10, 2016, 05:13:37 PM
I know it is a far call, but in case of changes, a sort of converter from old XML parameters to new ones would be a nice thing to have. Of course it is not something necessary, only very handy. Would save a lot of time in mod updates during alpha transitions, if such a program existed.
That would be a massive and ongoing project, so I'm afraid it's a bit out of the cards. I'm really looking for simple things that'd be useful forever.
Yeah, fair enough. It would be indeed a big project and not very viable at that, for it would only be useful as long as the game is in alpha and changes structure regularly.
Not very important, maybe something for a slow day:
I would like to see something similar to the Minecraft Forge OreDictionary. This would be useful for modders who want to add resources that already exist without requiring other mods as a dependency or conflicting with those mods. Take for example eatKenny's Industrialisation (https://ludeon.com/forums/index.php?topic=8902.0) and my CorePanda (https://ludeon.com/forums/index.php?topic=13400#msg129437) - both add copper, but the two kinds of copper can only be used to make things from their respective mod (unless they are both named the same thing, but then one gets overridden). With something like <thingType>Copper</thingType> both mods' copper could be used for the same purposes without conflicting.
This would also have a benefit to the vanilla game, allowing the different kinds of trees to drop different kinds of wood, but still be able to be used in the same way for fuel/building/etc. without taking up stuffCategories. It would also give players a reason to grow different types of trees, but not require them to. Maybe they like the look of teak walls with birch beds and oak doors, for example.
Quote from: cuproPanda on June 11, 2016, 03:19:41 PM
Not very important, maybe something for a slow day:
I would like to see something similar to the Minecraft Forge OreDictionary. This would be useful for modders who want to add resources that already exist without requiring other mods as a dependency or conflicting with those mods. Take for example eatKenny's Industrialisation (https://ludeon.com/forums/index.php?topic=8902.0) and my CorePanda (https://ludeon.com/forums/index.php?topic=13400#msg129437) - both add copper, but the two kinds of copper can only be used to make things from their respective mod (unless they are both named the same thing, but then one gets overridden). With something like <thingType>Copper</thingType> both mods' copper could be used for the same purposes without conflicting.
This would also have a benefit to the vanilla game, allowing the different kinds of trees to drop different kinds of wood, but still be able to be used in the same way for fuel/building/etc. without taking up stuffCategories. It would also give players a reason to grow different types of trees, but not require them to. Maybe they like the look of teak walls with birch beds and oak doors, for example.
Wish I'd thought of that :D it's a great idea.
@Tynan;
An interesting question. Having modded several different kinds of games from simple text-editor edits, to more complicated modding with toolsets, I'd like to weigh in on this discussion. I hope the stuff hasn't been already discussed by someone else, but I don't generally have tons of time on my hands these days to read tons of forum posts. Anywho...
1] Keep all "parent" classes at the top of each XML file. This way, a modder can easily figure out which groups of code are the "parent" and which are the "children". In some files, I can find "parent" code groups in the middle of the file.
2] Provide a list of all possible code that can be used in a parent or child. As an example, if you want to create a new trait, and want to restrict it so that only those who can do all kinds of skills, then you would need to know what are the names of the code lines that would be needed to allow cleaning, hauling, firefighting, etc...
This could be done in a "template" file that is a common occurrence in modding for older titles, with comments next to each code line explaining what they do, expected value ranges for numbers (ie Flammability is 0 to 1.0, and shouldn't be - values) and any specific order in placement within a code group (ie the StatBases might have to precede Costs; not sure on that but that is an example). Having a "template" would help to ease users into modding.
3] Provide documentation on how to add in sample items. So, as an example, have documentation on how to add a surgery option to add in a bionic brain. List of all the files that would need to be modified to do this. List off all the code needed to be added and to which files. Having documentation on how to add in sample items, would make modding a lot easier. That way a modder could have a "checklist" of what files they need to address to add in their item.
Sample items that really could use documentation (that I found hard to learn) are: Add a new Surgery, Add a new Storyteller, Add a new recipe, Add a new Joy Activity, Add a new Resource, Add a new Plant, and Add a new Animal. There is obviously more, but those are a few things that documentation could be really helpful for.
4] Make sure XML files are all "orderly" and neat. I don't know if the problem is just on my end, but editing some files, it seems like all the code is bunched up and nearly impossible to read without formatting it correctly with line breaks, spacing, and tabbing. When it is bunched up its hard to tell where one code group starts and another ends.
5] Give a list of all the "hidden" "parent" classes. What I mean by this is that in some files I see code using a parent class that isn't defined in any of the XML files. Knowing what is or isn't in these "hidden" "parent" classes, for inheritance purposes, would be very useful to modders. Then again, I may be completely wrong and there aren't any "hidden" "parent" classes, and if that is the case, my apologies.
6] If you wanted to do the documentation approach (not many check documentation so may be waste of time) the best things that could be in documentation would be:
- Samples on how to create specific items
- Templates on what code can be in a class and what cannot
- A list of things not exposed to modding and why
- A list of suggested books/online tutorials teaching C#
7] A conflicts checker in the mod loading interface, that could highlight which files have conflicts with eachother to help troubleshooting of mods.
8] Add in sample resources that are present in the game, but could be used by modders to avoid resource conflicts. As an example, add in Copper for modders to use, but isn't present in the base game as a resource that can be found. But, by having these sample resources available, it might cut down on conflicts as they'd use this resource rather than create their own. Common materials that might interest modders as resources are: Copper, Silicon, and Sand Piles.
9] Expose more of the code base to modders, providing more "hooks" for mods, requiring less C# to perform tasks. It may seem that making more code available would make things more confusing, and in some ways it might, but at the same time it reduces the amount of game modding knowledge that is required to accomplish something. The other benefit to exposing more code is that it will allow, you Tynan, to have more time in larger system creation and allow modders to add in the content. Code that I personally would love access to (that others may like as well) is:
- Shooting Mechanics = having access to the calculation that controls the hit/miss for colonists with weapons and enemies with weapons. If this isn't something you'd want to do, then you could indirectly provide access to the calculation by exposing the variables that control hit/miss chances for light levels, hit/miss chances for range, and allowing players to add in an increase firing speed based on skill level; a skilled shooter in theory should be more accurate and know how to reload their weapon faster.
- Experience Mechanics = being able to control how much experience each activity provides would be useful to modders. Yes, we can modify how much of an effect a high skill level provides, but we don't control how much experience a colonist or enemy gains for mining, growing, or shooting. Finally, being able to control how fast experience is lost per second based on skill level.
- Skill System = being able to add in new skills and add them to the skill interface (I'm not sure if this is possible right now, as I've never tried to add in new skills myself). Additionally, being able to break existing skills into sub-skills. So instead of having just "Shooting" skill, a modder could have a Neolithic Skill, a Small Arms Skill, and a Heavy Weapons skill, with different benefits/penalties based on skill level, and covers a specific set of items. Thus, you could have highly skilled gunslingers, that aren't good at rifles, but deadly with pistols.
- Extensive Surgery System = there is already an extensive health system, but there isn't an extensive system for addressing those various maladies. I've seen some modders add in animal surgeries, I've seen some do C# based scar removal surgeries, and I've seen some offer full bionic organs. However, it would be more ideal if the game itself allowed these kinds of things out of box rather than have modders "fix" the lack of these things for the game. The big problem is that it requires a lot of effort to add in a single surgery, and if you miss one of the files for it, the surgery doesn't work, and often the game won't tell you why it isn't working, unlike other forms of modding. If doing a full surgery system isn't ideal, then provide example samples that shows how to add bone repair, how to add in organ surgery/replacement, how to add in implants, how to repair scars or old wounds, and how to do all these things on animals as well. My biggest complaint with modding is that trying to do any of these things is extremely hard, extremely confusing, and many things require C# knowledge to achieve.
- Raid Mechanics = controlling how soon raiders arrive, how many raiders come, if they come with/without war beasts (ie Wargs), how many come with heavy weapons, small arms, or melee weapons, controlling how often you get raids, controlling which factions can arrive, what conditions they will start raiding at and controlling how different raid factions interact with eachother when two raids occur at the same time. Often times raids feel unfair, and being able to control how raids work at a fundamental level will allow for many interesting mods. A big problem with adding in new factions is the inability to control when they start raiding your settlement; ie in GlitterTech you are just as likely to be hit by a regular faction as you are to be hit by the Commando faction and getting the Commando faction early game is generally an instant kill.
- Map Generation Options = being able to control land generation such as mountains, hills, ruins, insect hives, and more would be very useful. Being able to litter the planet with tons of ruins or no ruins. Being able to control how many insect hives there are, or if you will find any. Being able to control if you have a single huge mountain range, or several smaller ones or a giant caveworld type level. The options available to users to do map generation is very sparse, and having greater access to map generation would be incredibly useful.
- Incident Controls = being able to add in your own custom incidents and edit the existing incidents. Being able to control what items can or can't be found in a resource pod drop would be useful. Being able to control what animals a psychic event affects would be useful.
- Item Slot System = being able to carry weapons, tools, and accessories on pawns would be very useful. Have a "hand" system where you can equip an item (if small enough) in each hand and use both items. This could allow for dual-wielding of weapons, using physical shields (ie shield blocks), or two-handing a one-handed object for a better bonus.
- Expose Stuff System = as an example, all animals will produce meat and fur/skin of some kind. However, one cannot control the various stats of each type of meat, fur or skin. Some fur/skin isn't flammable, while others are. Being able to control the stats of each stuff item produced by things that are currently not available to editing would be useful. The most obvious ones are the animal byproducts of butchering. Other examples are = smelting weapons (say you wanted less metal to be produced from swords and more from maces) or salvaging clothing (something that currently isn't available).
I'd still love to see the game be the best it can be, and looking forward to Steam Release. However, making modding easier, more accessible to new users, and exposing more of the codebase will allow more and better mods to be released giving you Tynan, more time to spend interacting with fans, bug fixing, and creating entire new systems while modders work on adding more content to the game. I hope that some of the above suggestions might get implemented, and will check back later for any replies.
Jaxxa beat me to the punch :D
It would be nice for .dds support same as vanilia assets have.
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
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.
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 :)
Documentation and organization are my biggest wants, but that's already been said (and far more eloquently).
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.
+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#).
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.
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.
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!
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.
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
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".
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.
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.
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.
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.
palandus, I hate to criticize your ideas, because they are good ideas, but they don't seem to be in the scope of this topic. My own suggestion isn't above this, either, and I shouldn't have posted it here because it is more of a reworking of the way recipes are handled. A lot of suggestions being given would probably be better put into a general suggestions thread.
That being said, while I can't think of any simple changes that would be useful, I will be noting things I come across as I work on updating to A14, and I'll post them in a similar thread for A15 changes if one is made. There are certainly some specific private fields and static classes I was frustrated by, but for my purposes there weren't any that I couldn't get around.
The problem with any suggestion is what is defined as simple or cheap to implement; always depends on multiple factors from coding style, how much refactoring is necessary, personal view on what should be allowed to be modded and if the suggestion is something one feels like doing. Without knowing precisely how Tynan defines simple, I'm kind of using the "shotgun approach", and firing off multiple possible areas that I'd love to see made more open, but not necessarily having any expectation that any of them will be implemented.
Something I might see as complicated to implement, Tynan might see it as simple to implement and some things I think are simple to implement are in fact extremely hard to implement. So, I don't mind the criticism, Cupro, but I still intend to fire off more possibles that may or may not get implemented, till Tynan tells me to stop.
palandus please stop. Many of your suggestions are just ideas for game features. The rest are mostly things modders can and should do themselves.
If you want to make another suggestion, make it very specific, with references to specific pieces of code, classes, and interfaces. And make sure it's simple please.
Fine I'll stop.
Again, simple is relative. But, I digress. In the future, Tynan, clarify exactly what you are looking for and you'll get a lot less garbage to sift through and a lot fewer crushed spirits. We don't know what you are looking for and thus cannot provide responses that you want.
Now that we know that you only want specific C# code changes for just C# modders, I'm sure that is the only responses you will get from now on in, now that we know you don't want XML changes. Thank you for the clarification.
XML change ideas are fine. Some of yours were worthwhile, but a some of them could be solved if you just used a grep tool.
Replacing TypeOf(class) with some xml identificator, stuff like .typeof(Building_Door)
Quote from: mrofa on June 16, 2016, 03:09:37 PM
Replacing TypeOf(class) with some xml identificator, stuff like .typeof(Building_Door)
Type is a part of C#, I can't change how that works. You can compare defs if you want.
What i mean is, insted of search for .typeOf, search for xml identificator.
Thrugh in my case i could only give a Buidling_door as a example, where typeOf in i think base.spawnsetup or pather prevent becoming a room barrier any custom class that uses Building_door as parent.
Well, it is good to hear that you still will take XMLs suggestions, but I got none. The only really good suggestion is thus:
Keep a list of contact email addresses of prominent modders that have been burnt out by the current modding scene, with the constant changing code base, and contact them when the game is close to final stable release telling them that the code isn't likely to change as much anymore, so that updating their mods isn't torturous to do anymore. As mods keep the game interesting with extra content, having modders get burned out is a huge loss for the community and game. Most quit after being unable to update their mod to the next alpha, thus if the code is relatively final, they might be encouraged to come back.
All I got though. Cheers!
Quote from: palandus on June 16, 2016, 04:00:29 PM
Well, it is good to hear that you still will take XMLs suggestions, but I got none. The only really good suggestion is thus:
Keep a list of contact email addresses of prominent modders that have been burnt out by the current modding scene, with the constant changing code base, and contact them when the game is close to final stable release telling them that the code isn't likely to change as much anymore, so that updating their mods isn't torturous to do anymore. As mods keep the game interesting with extra content, having modders get burned out is a huge loss for the community and game. Most quit after being unable to update their mod to the next alpha, thus if the code is relatively final, they might be encouraged to come back.
All I got though. Cheers!
That's a bit off topic (since it's a community management idea and doesn't make the game easier to mod), but a good idea.
Well, if there was a specific XML request, it would be to have editable files in each of the folders in Core. Several folders have nothing in them like, BrokenStateDefs and PawnKindsDefs. That or remove the empty folders to avoid confusion.
Quote from: palandus on June 17, 2016, 12:52:11 AM
Well, if there was a specific XML request, it would be to have editable files in each of the folders in Core. Several folders have nothing in them like, BrokenStateDefs and PawnKindsDefs. That or remove the empty folders to avoid confusion.
Lol I didn't even know there were empty folders there. They don't show up in VS. I'll get rid of them.
Can we have the source of some/all of the stuff decompilers like ilspy cannot touch. Anything with an iterator block in basically.
Specific C# Changes:
Most important to me:
Assembly # -> Rimworld -> LearnRates
Could you please make each of these variables XML moddable.
------
Other areas I'd love access to, but less so than above:
Assembly # -> Rimworld -> InfestationCellFinder
private const float MinRequiredScore = 6f;
private const int MountainousnessScoreRadialPatternIdx = 700;
private const int MountainousnessScoreRadialPatternSkip = 10;
private const float MountainousnessScorePerRock = 1f;
private const float MountainousnessScorePerThickRoof = 0.5f;
private const float MinCellTempToSpawnHive = -17f;
Can you make these all public (or make them XML moddable), so that modders can modify how insect hives behave, and how quickly they can multiply, etc...
Assembly # -> Rimworld -> InteractionWorker_RecruitAttempt
private const float MinMoodToRecruit = 0.35f;
private const float MinRecruitChance = 0.005f;
private const float BondRelationChanceFactor = 1.5f;
I like having fine-tuned control over recruitment, sometimes making it easier other times harder. Would love to have access to this stuff in either public or xml.
I second the recruit attempts. To me, recruitment is too easy and so I tend to only have low skilled wardens on purpose. It would help modding, too, since the rates could be changed on the fly dependent on [event].
Hey guys,
don't know if this is actually possible now, but personally I don't like the idea of working with XML to define stuff and do some background work with C#. Is it possible to make the whole mod except textures as part of the assembly?
Meaning defining buildings, floors, pawns etc.
If this is the case, then I would like to ask for advice in this matter. Only found XML/C# tuts :(
I just started getting into the modding and might not have the right to make such a call but I'm interested in creating some mods.
Only thing demotivating me a bit is the XML part of the modding :o)
Not quite sure precisely where to find it in the Assembly, but:
Being able to mod the time-scale "buttons". What I mean by this is that there are currently three buttons: Normal, Fast and Faster. It would be great for modders to have these accessible for modding purposes.
Personally, I think "Normal" is too fast, and "Faster" is too slow, and would love to be able to modify these to personal preferences. "Normal" is the speed I play at only when it is "Combat" and that is because it is forced upon me, however I find that the progress of Combat goes too fast for me to create effective strategies, especially with large numbers of colonists and raiders having a pitched firefight. Thus, personally, I'd mod it to be slower than current game speed to make the creation and maintaining of strategies viable... but that is a personal preference. Similiarly, I'd want to make "Faster" go much faster than it currently is (probably about the same "sped up pace" that is shown in the Trailers) so that I can progress the base faster once I've decided upon layouts with "Faster". And then probably set "Fast" to the current "Normal" speed.
I'd specify the exact code to change but as I don't have a clue where to look in the Assembly file, I can't provide them. If someone does know what they are, could you point me to the file so that I can list of the specific variables I'd like to be Public/XML moddable?
As i pointed out on one of the progression based conversations on here after seeing a heated discussion over the starting equipment, make starting items xml moddable, give the people the choice to make the game harder or easier as they see fit, some people view the survival rifle as a VERY good starting weapon.
Perhaps this is already very easy and I missed the obvious solution, or there's an existing implementation in the CCL, however while recently getting stuck into some more serious c# modding I've found a few things I'd love to see made easier or changed:
public enum TerrainAffordance : byte
{
Any,
Light,
Heavy,
GrowSoil,
Diggable,
SmoothHard,
SmoothableStone
}
It seemed to me that this could be a TerrainAffordances.xml with a terrainAffordanceDef class, which could allow modders to add new custom affordances for terrain such as DiggableMineralRich for a mining building. This might be easy to extend with derived classes, but it stood out to me as a feature that could be made easier. Otherwise, if we could get a WaterDeep and WaterShallow affordance added to the respectable terrainDefs that would allow modders to add water buildings, rather then buildings with no affordances that can be placed on water AND everything else, which can make jetties and boats a silly prospect.
Another thing I found while adding my own type of geothermal generator was lines of code in the GenSpawn.cs
if (blue.def.entityDefToBuild == ThingDefOf.GeothermalGenerator && t.def == ThingDefOf.SteamGeyser)
{
return false;
}
Again I could have missed the obvious reason for this code, but it seems like this was out of place and works redundantly with the PlaceWorker_OnSteamGeyser class, restricting the blueprint placement on the geyser unless it was a vanilla geothermal Generator only. Other placeworkers, including my own custom assemblies worked as expected but everything related to placement on a geyser is restrict by this and a few other methods in GenSpawn. My easy solution was just a custom geyser or "hole in the ground" with it's own placeworker, but I thought this was worth a mention.
I've only just started exploring the assembly and modding it so I might find more points to add later.
The latter issue is addressed in CCL it was one of first things 1000101 detoured.
Quote from: skullywag on June 20, 2016, 07:18:46 AM
As i pointed out on one of the progression based conversations on here after seeing a heated discussion over the starting equipment, make starting items xml moddable, give the people the choice to make the game harder or easier as they see fit, some people view the survival rifle as a VERY good starting weapon.
There will be. There's going to be a StartingThing_Defined introduced which allows you to add a ThingDef and count to spawn with.
Is this in A14? I should know this lol. I need to catch up. Why must life be so busy.
Given that the API isn't being kept stable and compatible between different versions anyway, there really shouldn't be any reason to define anything as private.
Sure, modders will start messing around with things you might change in the future, but that's already the cases as the public (and protected) methods and types aren't kept stable either, so not much loss here.
Well, the simplest suggestion is to change your coding best practices to a style that supports modding.
What I mean by this is that when I took the time to learn C++ on my own, every tutorial and book I read always suggested making member variables of classes private with specific mutator functions to modify them or accessor functions to access them. However, all of these tutorials assume that no one else will be touching the code and assumes that users cannot modify the code; everything should be hard-coded and only touchable by the programmer(s). This is the style of "best programming practice" that is also taught in textbooks (I took a class in introductory C++ in College) and schools. However, as Rimworld is being designed as a game that supports and encourages modding, this implies that the common "best programming practices" do not necessarily apply fully to Rimworld (some still apply such as good variable names, good formatting, comments when necessary, etc)
So my suggestion is this:
1) Change all current Private Variables to Public Variables. Any variable that a user may want to modify, particularly pertaining to specific gameplay mechanics, should be made Public.
2) Only use Private Variables for Variables that should not be user edited at all. These are Variables that if incorrectly modified could cause severe Runtime Errors or Memory Leaks (or is a Memory Leak a form of Runtime Error; I ask because some say its a logic error due to improper usage of calls to delete and others call it a runtime error as it kills the program when the memory leak gets too big) that would be difficult to debug. Or variables that are used as intermediary temporary variables that would serve no real purpose for a modder anyway.
By keeping most of the gameplay mechanics public variables, and only specific variables that should never be user modifiable private, it would make modding easier and would hopefully make updating old mods to new mods a lot easier as well.
The simplest way to do the conversion is to use the Find and Replace tool; that would be the quickest way, and then go through it and change the few variables that should never be edited back to private.
To illustrate this point I'll refer to Assembly # -> Rimworld -> IntermittentSteamSprayer:
NOTE: Using this as an example, even though I doubt anyway would change this, but this class helps to illustrate my point so that is why I'm using it.
private const int MinTicksBetweenSprays = 500;
private const int MaxTicksBetweenSprays = 2000;
private const int MinSprayDuration = 200;
private const int MaxSprayDuration = 500;
private const float SprayThickness = 0.6f;
These should be made public variables. However:
private int sprayTicksLeft;
Should be left as private. It doesn't appear to be something modders should have access to as it looks like an intermediary temporary variable.
Hope that explains things better. I'm definitely not asking for everything to be made public. However, things that directly control gameplay should be available to modders while things that should never be touched by modders should remain private.
"when I took the time to learn C++ on my own, every tutorial and book I read always suggested making member variables of classes private with specific mutator functions to modify them or accessor functions to access them. However, all of these tutorials assume that no one else will be touching the code"
No, these tutorials don't assume 'no one else will be touching the code'. In fact, they assume the opposite. The whole point of having a defined interface separate from internal implementation is because other people will be touching the code.
Non-public members are used for a variety of reasons.
1. You want to be able to give consumers of the code an easy-to-understand interface, instead of exposing a bunch of hard-to-understand implementation details.
2. You want to avoid bugs and problems that occur because users of the code don't know the assumptions on which the code is based. So you design an external interface with few, simple assumptions, and you can make more optimized internal code with lots of assumptions (that only you have to respect).
3. You want the interface to stay the same even if you change the implementation.
Even if it was a one-person project, I'd make public/private interfaces because I know future me wouldn't understand the complex internal interface later. Public/private interfaces reduce cognitive load.
Simply making everything public is a very bad idea. It would make life much harder for me, for members of my team, and for you. What you really want is good, powerful interfaces. I'd be happy to hear specific suggestions on how to create that.
Beat me to the punch before I finished editing my post above yours. Sorry about that; forgot some things I wanted to say.
No, I'm not advocating for all variables to be public. I am advocating for making variables that directly control gameplay to be made public. While intermediary variables or variables that shouldn't be touched at all as modifying them may cause runtime errors, should be kept private.
EDIT:
A rule of thumb I'd use is if I can read a variable and instantly understand what it would do, then it should be made public. If I can't understand what it does without understanding how that variable is implemented or what are specific conditions that must remain "true" to have that variable perform as expected, then it should be private.
So, taking from Assembly # -> Rimworld -> InteractionWorker_RecruitAttempt:
private const float MinMoodToRecruit = 0.35f;
I can read the above variable and instantly know what this variable will do. It makes it so that any pawn with a mood score of 34 or less, cannot be recruited or stating it another way, a pawn needs 35+ to even have a chance at recruition.
However, something like (Assembly # -> Rimworld -> ITab_Pawn_Health):
private const int HideBloodLossTicksThreshold = 60000;
Looking at that variable above it is very hard to know what it does by simply looking at it. I'd need to understand how it is implemented to be able to use it, and thus, should be left private.
So, I'd suggest that to have powerful interfaces, that any variable that can be easily understood to what it does or doesn't do, should be make public, while variables that would require understanding what it does and what conditions are required to keep it working as intended, should be left private.
If you "want" I can take the time to go through the various files and make a list (including which class I found them in) of variables that I can instantly figure out their purpose and thus should be made public. I'd of course put it into a text file to avoid a super long post of details, and then upload the text file as an attachment. But only if you want me to.
I'd think it would be simpler to have me provide a list of variables that should be made public to make it easier on you in making the changes but it will take me a lot of work to do it and if you don't want it down, no point in doing it... right? So, if you do want me to look through the entire assembly and build you a list of variables that could be made public, then I'll do it.
This is pretty off topic, but when it comes to complex assemblies and collaborations with code, making everything public is the worst possible thing you can do. You create each object and instance of each class as a set of input and outputs, the workings are hidden, like a kind of black box with external switches. Even if you access those objects you think you understand with a simple function like getMinMoodToRecruit which seems like an extra step over simply making it public you have to realise that the public keyword should be used as minimal as possible. Only use it with the interface, EVERYTHING else is private or protected. Otherwise controlling which parts of the program touches what would be impossible to debug.
A simple analogy that I was given when I was doing c++ in uni was a front door analogy. If you had an external door to every room in your house (every room was public), you would still know which was the front door, and would use that to enter the house and use the other doors with much added convenience to accessing the house. However visitors would accidentally or unknowingly enter from the wrong doors all the time, not knowing which was the front door. Trying to find the pathway visitors used to enter your house in order to plan your interior would be confusing and potentially a breach of personal privacy. So you only have one front door with a entry room beyond as the interface between private space and the public.
In OO design the best possible solution to accessing the things you need (aside from the defined interface) is to make them virtual or protected and then inherit from that object in a new class. You still maintain encapsulation while keeping vital variables private even from the derived classes. Perhaps instead of asking the dev team to break the assembly wide open for us to rip apart (as it were) you could look through the assembly and make a note of where you could derive new classes from and access the things you need in the correct abstract fashion. Compile a list of those notes and ask nicely for them to be made virtual or protected. For example InteractionWorker_RecruitAttempt could have the derived class of InteractionWorker_RecruitAttemptGlitterTech where I could do the things I want with the virtual variables.
Due to persistence of hooks, there are no real limits.
Nothing prevent developer from hooking classes that affect database and mod loading and forcing reload.
Still, this require skill that not need anywhere else and will consume time, doubling loading time of game.
We need early injection point, before database load.
Target type is "ModAssemblyHandler"
Target method is "ReloadAll"
code:
Assembly asm = null;
try
{
byte[] rawAssembly = File.ReadAllBytes(info2.FullName);
FileInfo info3 = new FileInfo(Path.Combine(info2.DirectoryName, Path.GetFileNameWithoutExtension(info2.FullName)) + ".pdb");
if (info3.Exists)
{
byte[] rawSymbolStore = File.ReadAllBytes(info3.FullName);
asm = AppDomain.CurrentDomain.Load(rawAssembly, rawSymbolStore);
}
else
{
asm = AppDomain.CurrentDomain.Load(rawAssembly);
}
}
After this lines, game should unconditionally and inside main thread invoke something like this:
foreach (Type t in asm.GetTypes())
{
if (t.HasAttribute<StaticConstructorPreInit>())
RuntimeHelpers.RunClassConstructor(t.TypeHandle);
}
This will lift all possible limits and allow developers to do absolutely anything without major side effects.
p.s.
Protection levels is not issue and "good coding practices" just joke if we take in account assembler level hacks used for some things.
Yeah, pawn graphics are a very old system and not 100% modularized (yet). We may move in that direction, though, when it's time to show packs or armor on animals, etc).
Could you please give modders uptodate access to the latest source files where IEnumerator methods are being used?
While they can be decompiled, they are hell to read, especially for beginners.
You sent me some classes in the past (JobDrivers I think), but now they are of course outdated again. Try and decompile those and you'll see what I mean.
It is a little too generic I suppose, but reducing the overall amount of hard coded settings on the game world, pawns, animals, and the like is a step in the right direction. I have not messed around much with modding, mostly because I don't want to commit effort where I would be redoing the effort upon next release, I've experienced it, and I just don't have the creative drive to reinvent.
I think the ability to modify startup order (like clickable up and down arrows to increase or decrease priority) in the interface would make it easier to use mods from a user standpoint, and perhaps for some of the larger mods with extra dependencies.
Don't get me wrong, the current way isn't terrible for a handful of mods, but the higher amount of mods the more difficult the current way is to modify. I once made the mistake of trying to use 20 some mods, and gave up in frustration as I just could not figure out the necessary load order.
It would equally be nice to have a semi-autonomous system in place for dependencies - mostly for mod pack creators - to kind of look for potential mis-ordered mod dependencies - but perhaps this is beyond the scope of a simple tweak. (I was thinking a debug mode - with a search call that scans the mods in order on error looking for a missing function that might be in a mod that was put further down, a sort of dumb way to tell the user which mod is out of order, and the possible fixed order.)
Perhaps I'll add more later tonight, but I wanted to get these out while fresh on my mind.
Well, I did it anyway, and compiled a list of currently "private" variables that could be made "public". These are variables that are understandable to their purpose by just reading the variable OR by understanding the class and thus the variable logically then means "that" (whatever "that" may be). I put it all in a text file for perusal; the structure of it is as follows: Assembly C# -> "namespace" -> "class" -> "variables". The class name and variable name are taken verbatim from ILSpy of Assembly C# for Rimworld. You'll note that I didn't take "all" private variables and suggest turning them into public; instead I only chose the ones that appear logically understandable that could be made public.
While doing it I also noticed that there is A LOT of already made Public Variables, but are not currently moddable by XML, that people (including myself) would love access to.
My personal suggestion for making modding less difficult for us and less costly for you, Tynan, is to teach us how to create XML files of public classes and public variables to create the mods that we want to make. If we knew how to create the XML files (I checked the wiki and elsewhere and couldn't find any tutorials mentioning how to do, so sorry if this is already common knowledge), then we could do a lot of the work that you'd normally have to do to create the XML files yourself.
File attached is again all the possible currently private variables that could logically be made public and be understandable of their purpose to modders. I hope the information is useful in some way, as I did spend about 4 hours putting it together (lots of classes to look through).
[attachment deleted by admin - too old]
Here are my requests Tynan:
- In Building_NutrientPasteDispenser, make TryDispenseFood overridable (so we can change the required food amount and the type of dispensed meal).
- Handle map GenSteps from different mods (add an index to order them? or a system similar to the hook points in the thinkTree?). It is currently tedious to make patch for any other mod adding a GenStep :P (Haplo's ruins, prepare carefully, crash landing, outpost generator, ...).
- In Verse.PawnRenderer.RenderPawnAt function, it would be cool to be able to use the wiggler as we want (so we can override the pawn rotation. My initial idea was to create a sniper foxhole in which the pawn is laying down to get better accuracy and protection. :) ).
- In CompGlower.ShouldBeLitNow, add a public boolean parameter than can be easily toggled by modder. I currently have to spawn/despawn invisble glowers building as a workaround. :-\
ooh biomes, we should be able to add our own biomes, this wasnt possible in A13.
Quote from: Rikiki on June 22, 2016, 07:56:07 AM
Here are my requests Tynan:
- In Building_NutrientPasteDispenser, make TryDispenseFood overridable (so we can change the required food amount and the type of dispensed meal).
- Handle map GenSteps from different mods (add an index to order them? or a system similar to the hook points in the thinkTree?). It is currently tedious to make patch for any other mod adding a GenStep :P (Haplo's ruins, prepare carefully, crash landing, outpost generator, ...).
- In Verse.PawnRenderer.RenderPawnAt function, it would be cool to be able to use the wiggler as we want (so we can override the pawn rotation. My initial idea was to create a sniper foxhole in which the pawn is laying down to get better accuracy and protection. :) ).
- In CompGlower.ShouldBeLitNow, add a public boolean parameter than can be easily toggled by modder. I currently have to spawn/despawn invisble glowers building as a workaround. :-\
1 and 4 have been in CCL for a bit now. ;)
Quote from: palandus on June 22, 2016, 01:14:47 AM
Well, I did it anyway, and compiled a list of currently "private" variables that could be made "public"...I put it all in a text file for perusal.
Just so you know, they are refered to a "fields" because they are a part of a class or struct. Variables are defined locally in code, fields are defined in structs or classes. The difference is, a variable is a memory address and a field is a memory address offset from the start of the class/struct.
Second, most of those are named constants (const). They don't actually exist after the code is compiled. Any place a named constant is used, the compiler replaces the name with the value of the constant. Making constants public won't allow you to change their values but it would be convenient to not have to duplicate them.
Quote from: palandus on June 22, 2016, 01:14:47 AMMy personal suggestion for making modding less difficult for us and less costly for you, Tynan, is to teach us how to create XML files of public classes and public variables to create the mods that we want to make.
I'm not sure it's Tynan's job to teach us to mod...
The xml is pretty straight forward, each xml class is a C# class, each xml tag is a field in that C# class. Open the class in a decompiler to find all the fields and their possible values, ranges, etc. For most simple mods you can simply refer to the core xml without even opening a dll. But if you are trying to do fun and wonderful things, this is where the reverse-engineering starts and there are no answers Tynan can give to cover all the possibilities.
Quote from: 1000101 on June 22, 2016, 04:34:16 PM
1 and 4 have been in CCL for a bit now. ;)
I know, but the topic of this thread is to make the core game easier to mod! So basically reduce the need of detour and other (dirty?) tricks. ;)
Quote from: Rikiki on June 22, 2016, 04:37:22 PM
Quote from: 1000101 on June 22, 2016, 04:34:16 PM
1 and 4 have been in CCL for a bit now. ;)
I know, but the topic of this thread is to make the core game easier to mod! So basically reduce the need of detour and other (dirty?) tricks. ;)
I'd call those "feature enhancement" compared to some of CCLs "pure fix" detours though. A lot of the detours in CCL are just to "fix" core behaviour (such as the steam geyser issue which actually was in CCL from day one but used a different means to do it).
Whatever. I'm done. Do with it what you want, I'm out. This is isn't worth the stress and the headaches. I'll go back to quietly lurking and being useless.
EDIT:
I have changed my mind. I won't go quietly. I understand that there will be repercussions for my actions, but at this point I have passed the point of caring of the consequences. I do not care if I get banned, both account and IP from this site. However, this needs to be said and I'll try and be civil.
The biggest problem with modding, is also the most costly to fix; the problem is you, Tynan and until that is fixed, no amount of "small and cheap" fixes will solve the problem.
You have worked in a large development team environment before starting rimworld, with Bioshock Infinite. You know from experience that communication with your fellows is critical in developing a game; if there is no communication there is no game, just a chaotic mess of code, assets, and dreams jammed together in a dysfunctional state. Therefore you, of all people on this site, should know what happens when there is ineffective communication between members working on a project.
Each major modder that works on the game should be considered an unofficial member on the development team as their mods ensures the longevity of the game when it is still in its Alpha Status; without modders, I can safely say that people would have likely forgotten about Rimworld soon after it got out of it's Kickstarter. These modders give life and greater enjoyment to users.
The reason there is modder burnout at all, is due to ineffective communication between yourself and those modders. The reason they can't update their mods is because of decisions you make without consulting them on how it will affect all the other members on the team; if you made similar decisions while working on Bioshock Infinite, without explaining to others the choices you made and why, it would cause huge problems to develop, as they usually do in game companies with ineffective communication. When you change something from public to private or completely refactor code without telling the other members on the team what you are doing, it will break their code and prevent them from doing their job. If you want modders to stick around and actively care about their burnout and the loss for the game as a whole then you need to setup a form of communication between modders and yourself; this wouldn't be necessary if you had only added modding at the end of the development cycle, but if you had, you probably wouldn't be as successful as you've been either.
Treat modders as team members, and explain your reasoning for changes with them, and listen to them on how the changes affect them. Without communication, modders will continue to burnout and many mods will never see the light of day. Your success as a developer and businessman depends on the success of Rimworld. If the modders all burn out before the actual release of the game then the content that they provide will not be present either. And as many users, for many games, feels that mods makes a dull game feel fresh again, you need modders to stick around. The only way that is going to happen is if you actively communicate with modders and try and avoid changing things that will directly prevent them from modding. By communicating with modders on a regular basis and knowing what things they use to make their mods work will help you in making better choices and ensure that modders stick around. Thus, working on learning how to communicate better with modders is the best way to make modding easier, for all involved. However, setting up an effective communication system will likely take a lot of work, trial and error, and working with community on a regular basis eating up development hours, so knowing you, you will likely say it costs too much, that it would take up too much time, divert critical development hours to communication time and dismiss my suggestion due to its cost. I hope that you will implement an effective communication system between yourself and modders; it is the best option. However, if you don't implement some way to communicate better, then I don't think that the potential I saw in the game in its Kickstarter will ever reach fruition and the game that I hoped to play and enjoy when it finally would release will never come to pass. ... But there is always the chance...
That is all.
palandus - Communication is what I'm trying to do in this thread; but please also realize that I also have a lot of other things to do, that it's an alpha game, that I won't leave code poorly factored or cut core game progress speed or start building up compatibility cruft to make modding a bit easier in the short run. I really appreciate the fact that people are modding the game, but it's still an alpha game with an aggressive development schedule that gets new features often. This is good for players, because people like games that expand fast and add cool stuff, but it creates a natural and unavoidable problem for modders because the game isn't the same game month over month.
Anyway, thank you for your contribution.
Quote from: Rikiki on June 22, 2016, 07:56:07 AM
Here are my requests Tynan:
- In Building_NutrientPasteDispenser, make TryDispenseFood overridable (so we can change the required food amount and the type of dispensed meal).
- Handle map GenSteps from different mods (add an index to order them? or a system similar to the hook points in the thinkTree?). It is currently tedious to make patch for any other mod adding a GenStep :P (Haplo's ruins, prepare carefully, crash landing, outpost generator, ...).
- In Verse.PawnRenderer.RenderPawnAt function, it would be cool to be able to use the wiggler as we want (so we can override the pawn rotation. My initial idea was to create a sniper foxhole in which the pawn is laying down to get better accuracy and protection. :) ).
- In CompGlower.ShouldBeLitNow, add a public boolean parameter than can be easily toggled by modder. I currently have to spawn/despawn invisble glowers building as a workaround. :-\
Thanks for these. Will definitely do number 1, and will look into the others.
Note to everyone: This is the sort of actionable, specific request I'm looking for!
I saw someone mention the Minecraft Forge Ore Dictionary before, and I think that's a brilliant idea.
For those that don't know, it's a system that allows you to essentially "label" items with a common alias. So if 3 mods add 3 different kinds of titanium and 3 computer chips, they could all be used interchangeably as long as mod devs added a "titanium" and "computer chip" label to each.
I don't know how long it would take to implement, but an item dictionary would certainly help modding scale up if the Rimworld community explodes after the Steam release.
palandus please stop being a drama queen.
Quote from: brucethemoose on June 23, 2016, 03:10:46 AM
I saw someone mention the Minecraft Forge Ore Dictionary before, and I think that's a brilliant idea.
For those that don't know, it's a system that allows you to essentially "label" items with a common alias. So if 3 mods add 3 different kinds of titanium and 3 computer chips, they could all be used interchangeably as long as mod devs added a "titanium" and "computer chip" label to each.
I don't know how long it would take to implement, but an item dictionary would certainly help modding scale up if the Rimworld community explodes after the Steam release.
This is already in, everything with the same <ThingDefName> is replaced by the last loaded mod contaning the same thingdef name thing.
So its more of the modders agreement on Thingdefname, to make like a specific list
(Off Topic)
It would be nice if we could thumbs-up or thumbs-down posts to easily show agreement or disagreement. Suggestions, comments, and inflammatory remarks could all benefit from that.
Quote from: mrofa on June 23, 2016, 09:56:41 AM
palandus please stop being a drama queen.
Quote from: brucethemoose on June 23, 2016, 03:10:46 AM
I saw someone mention the Minecraft Forge Ore Dictionary before, and I think that's a brilliant idea.
For those that don't know, it's a system that allows you to essentially "label" items with a common alias. So if 3 mods add 3 different kinds of titanium and 3 computer chips, they could all be used interchangeably as long as mod devs added a "titanium" and "computer chip" label to each.
I don't know how long it would take to implement, but an item dictionary would certainly help modding scale up if the Rimworld community explodes after the Steam release.
This is already in, everything with the same <ThingDefName> is replaced by the last loaded mod contaning the same thingdef name thing.
So its more of the modders agreement on Thingdefname, to make like a specific list
But that overwrites the previous versions. What happens when multiple people add something like wood - each with different colors, flammability, maybe market value? Each previous one would need to be replaced, which is completely different from what I was suggesting. It works for the most part, but it's not the same. You may say that we can easily add new wood, it just counts as stuff, but then what about making production tables - they need stuff plus wood, steel, etc. Plus, it avoids any toe-stepping which may prevent people from making mods (even if I think I have better ideas, why make a fishing mod when one already exists? If I add [resource] to my mod, this modder will think I'm trying to copy their idea!)
If you have say 4 mods(thats tested number), each of them add wood with <ThingDefname>Wood, each mod wood have diffrent color, diffrent stuff stats and so one, last mod loaded will overwrite all prev version of such Thinkdef, this include settings of stuff and stats, descriptions and all stuff you got in xml thingdef.
Simply said if your mod loader have
1. Mod A
2. Mod B
3. Mod C
4. Mod D
Mod D duplicated resource with all its thingdef settings will be used in game.
This is basicly why you are able to replace vanilia thingdefs in a mod, becouse core is always on 1st position
The oreDictionary idea is pretty solid. But, I could see that being a community addition like CCL rather then a vanilla change. It might be possible with a bit of ingenuity now, I see it being required as the last mod in the load order which overrides the multiple labelled materials but maintains a separate def for each by changing the ThingDefName field to the original name, say Wood, and concatenate the mod name from the relevant field. So if my mod added a dark mahogany and I labelled it Wood, it will become GlitterTechWood and can be used interchangeably with OtherModWood from a mod called OtherMod which added a creamy birch and is named Wood in it's own file.
Rather then replacing the def it now has two materials that can be used in the same recipes as Wood in addition to every other version of Wood. It's similar to making the material a Stuff, but more powerful as the OreDictionary can make something a stuff in a recipe during loading without the xml recipe needing to be changed and both different defs would work for anything that as Wood as a recipe. So, mods can work with other mods by adding more types of ComputerComponents or Wood without needing communication between mod makers. It could be a powerful addition to the vanilla game for sure, it has been working in Minecraft for years, but like Minecraft it was a community addition and not what this thread is about.
Quote from: Tynan on June 23, 2016, 01:27:38 AMpalandus - Communication is what I'm trying to do in this thread; but please also realize that I also have a lot of other things to do, that it's an alpha game, that I won't leave code poorly factored or cut core game progress speed or start building up compatibility cruft to make modding a bit easier in the short run. I really appreciate the fact that people are modding the game, but it's still an alpha game with an aggressive development schedule that gets new features often. This is good for players, because people like games that expand fast and add cool stuff, but it creates a natural and unavoidable problem for modders because the game isn't the same game month over month.
I just wanted to add that once the game is complete, even if Tynan doesn't provide a solid how-to, it'll at least no longer be a moving target and the community can put that together. (For example, my current signature has a link to Alpha 13's uses of XML in Core, and my A14 version will be even better.)
oredic feature is not possible to implement with CCL or any other framework without early (before database) loading support from vanilla game.
(*properly*, it's possible to install hooks and reload database, but this will double loading type and likely to cause major memory leak)
not everyone is aware, but, all "core" mod developers are obviously aware about spigot\forge.
all community currently need is 4 very minor modifications of modloader about loading mod provided assemblies with specific tag very first, ever before GUI, everything else is perfectly possible with hooks.
Yes, as RawCode and I both suggested, we need a early code injection point while the game data is in an empty state.
As a simple suggestion, putting the Detours from CCL into the core game is a great addition! :P +1 Vote for this!
Below the simple suggestions, generally speaking, when I was actively modding Rimworld, I have 3 major issues:
1. Cannot override functions that I wanted to. I have to add CCL dependency only for the Detours!
2. C# functions that, in ILSpy can't de decompiled in the right way! The ILSply can't understand the functions with yield statement, and as a modder, is difficult to Understand what the this function do! :)
3. New alphas refactor of Xml Defs, I have to mos cases rebuild my entire Xml Defs.
Here is another interresting one!
Add a way to set needs according to the PawnKindDef. The function RimWorld.Pawn_NeedsTracker.ShouldHaveNeed only allow to distinguish between colonist/prisoner and stranger.
A solution could be to add a <onlyForFactions> property (List<FactionDef>) in the NeedDef. This way, I could make my neutral military camp AI pawns more 'human' because they will enjoy drink a beer after o day of patrolling. :D
Here is the piece of code:
[...]
return this.pawn.RaceProps.needsRest;
}
// Need specific to a given list of faction defs. Only for pirates, only for insects, ...
if ((pawn.Faction != null)
&& (nd.onlyForFactions.NullOrEmpty() == false)
&& nd.onlyForFactions.Contains(this.pawn.Faction.def))
{
return true;
}
return (nd != NeedDefOf.Joy || [...]
Would it be useful if you added something like LoadBefore and/or LoadAfter list to the About.xml, and then let the game try to guess the correct loading order given these parameters?
Quote from: hwfanatic on July 07, 2016, 03:33:41 AM
Would it be useful if you added something like LoadBefore and/or LoadAfter list to the About.xml, and then let the game try to guess the correct loading order given these parameters?
+1 For this!
I came to here to write something like that! :)
Quote from: RawCode on June 21, 2016, 04:50:37 AM
foreach (Type t in asm.GetTypes())
{
if (t.HasAttribute<StaticConstructorPreInit>())
RuntimeHelpers.RunClassConstructor(t.TypeHandle);
}
This, very much this. With this we could solve a lot of the other issues people have been mentioning in this thread.
- Mod Dependency Resolution: could be handled by adding a "dependsOn=.." to the XML and loading a DLL mod that redirects the normal xml loader to handle ordering/missing deps
- OrDictionary: I started working on a ModHelper abusing CustomXMLLoader() to redirect methods. Almost had it working, but ran into the common issue of not being able to hook into the code early enough.
- ModPack Helper: My current pet project which allows updating existing Things without completely redefining them. I have a working prototype using CustomXMLLoader() as the pre-hook and ResolveReferences() as the post-hook. The other feature allows decorating XML Defs with attributes which control loading based on if other Mods/Defs are loaded, but this relies on a custom Def. A hook would allow me to augment the default loader to handle this for all Defs.
We could handle the following ourselves if we had the above hook, but barring that, more hooks in the core XMLLoader would be nice.
If I've followed the code correctly, the current process for loading Mods is:
1. Load ModDefs
2. Load all Non-reference properties for all Defs
3. Resolve def reference properties
What would be nice is to add some hooks between steps:
0. PreModLoad()
1. Load ModDefs
1a. PostModLoad()/PreDefLoad()
2. Load Non-reference properties for all Defs
2a. PostDefLoad()/PreResolveRef()
3. Resolve def reference properties
3a. PostResolveRef()
For my use case, I would be using the pre/post methods to remove items from the CrossRefLoader as well as the DefDatabase.
Speaking of:
Making DefDatabase<>.Remove() public so I don't have to reflect to accomplish the above.Otherwise, a +1 for
documentation. From the a14 post:
Quote
Various refactorings to make modding easier and code easier to maintain and more flexible. Much more functionality is now implemented as composable ThingComps.
But, I can't find a list of what these modding changes actually are anywhere.
Hello Tynan.
I would vote on the following:
1) A global event system for mods.
Allow mods to receive callbacks for events such as- game initializing, vanilla defs loaded/reloaded, initialization/re-initialization complete (at main menu), Update (each frame), OnGUI, map loading, map loading complete, game tick, game save/load, before map unload. Also, on opening/closing of a window on the WindowStack (for interface mods). In the mods menu- callbacks for when a mod has been enabled/disabled (CCL breaks to this day if the mod menu is closed without a restart).
Most of these can be accomplished using a Unity object and MapComponents, but a dedicated system would make for cleaner and more future proof code.
2) As skullywag mentioned, source code for all enumerators (methods with yield return) would go a long way in making researching the code easier for newcomers.
3) A clean way to remove mods from a save. Say, a mod with saved things is removed and the player attempts to load a map with data added by that mod. The game could warn the player, and ask if it should proceed. The map would then be loaded, removing all missing things, researches, map components, etc. in the process. Perhaps, an "uninstall" type of functionality could be put in place, to allow the mod to perform custom cleanup on a map before removal.
Take care.
I'd also like to add this: the above are just small suggestions, since with the way the game's codebase is organized it is generally a pleasure to both explore and modify. The separation between Verse and Rimworld code adds clarity, and the Def system is wonderfully flexible and an inspiration for future games.
I learned a lot by just figuring out how the game works.
I feel some work could be done to provide a reliable architecture to the modders.
From a technical point of view, it would consists of a "MyMod" class (written by the modder) that inherits a "BaseMod" class (written by the devs). The BaseMod class would contains hook methods for initialization such as OnLoad, OnGameLaunch, OnGameCreate, OnGuiCreate, ... that can be overwritten by the "MyMod" class.
The game would find the address of this class in the About.xml.
This "manifest" file could also contains the dependance of the mod, then the code that handles code loading should ensures that these are loaded before calling the OnLoad method of the "MyMod" class.
Essentially, the idea is to add a layer between the game and the mods so that they don't directly access the core of the game, but an interface that the devs specify.
I've done mods & plugins for some games (Minecraft, Cities Skylines, ...), and I launched a small modding API for Planetbase, and I think this is a clean architecture that allows mods to work side-by-side without stepping on each others' toes. If the API is properly made and complete, the modders don't have to deal with hacky workarounds (Manipulating Unity's GameObject or C#'s reflection API) to introduces new mechanics to the game, though they would still be able to do it if the API doesn't provide what they're looking for (but it would be an undefined behaviour from the dev's point of view).
i am not a modder, but to players like me, it would be much easier to be able to add mod via steam workshop or sth like the mod nexus for fallout 4.
Mods are already on steam workshop.
Mods are already on Nexus :D
Two labels for the player factions would be real neat for the thumb-in-the-middle-of-palm modders like me, to avoid multiple factions of same name or ridiculous ones like faction "Colony no hats" ::)
(http://i.imgur.com/pXwiZhZ.png)
like one label for the scenario edit screen and another actual one in game
I'm trying to make a mod (http://steamcommunity.com/sharedfiles/filedetails/?id=733113011&tscn=1469750669) that adds a new species of alien, but humans and aliens can't, ah, "hook up" without dev mode. Even if you do make them hook up with dev mode, they won't do any lovin'.
I heard this was to prevent animals from breeding with incorrect species, but this wouldn't really apply to humanlikes, would it? (Seeing as only lovers get lovin', but they don't produce babies anyways.)
Quote from: Diana Winters on July 28, 2016, 08:45:52 PM
I'm trying to make a mod (http://steamcommunity.com/sharedfiles/filedetails/?id=733113011&tscn=1469750669) that adds a new species of alien, but humans and aliens can't, ah, "hook up" without dev mode. Even if you do make them hook up with dev mode, they won't do any lovin'.
I heard this was to prevent animals from breeding with incorrect species, but this wouldn't really apply to humanlikes, would it? (Seeing as only lovers get lovin', but they don't produce babies anyways.)
Oh yes I second this! I would love to have my norbals be able to get some human lovin' too
they're bit rough around the edges, the norbals, but they deserve to be loved
I recently thought it would be nice to be able to use a tool on the debug menu to skip forward a certain number of seasons or years.
"modular" AIs, so you can specify in the XML use a colonist's AI, or a mech's AI, or some other AI, then things like MD2's droids wouldn't be such a pain in the rear to do/update, i remember having Droids wayy back when your colonists could only grow potatos and didn't care if they where raw (i want to say it was A4 or there a bouts, but i could be a few versions off)
"Modular" Pawns, start with a base "type" then use XML for specs like traits,immunity gain speed, moment speed, etc
Load order tweaks,
"Depends on" is a good idea, but doesn't account for all load order situations, so there should also be an option for "Should Load Before/After"
a check for xml mods that use existing defs. this could be done using a temporary list of vanilla defs. using this list you can then tracks changes when mods replace a def. then warns when another mod tries to make a change to an already replaced def.
Sorry if it was already suggested:
-An way to reload the mods without restarting;
-When i enable the debug mode, it would be nice to know the name of the class of the object i'm looking to (example, i'm seeing the geothermal generator, and his name is PowerPlantGeothermal, base class is BuildingBase, height is x, etc etc etc)
-Also, on debug mode, it would be nice if i was able to change the colonists skills, instead of having to generate a new colony with the predef colonists;
Thing identifier, simple string or enum added to thingdef class and specify in xml to tell what the thing actually is.
Is it a wall , door , workbench, seat or common pice of furniture. Adding thing like that would make search and codding much easier, not to mention efficient, since you wouldnt need to check 30 things about a thing to establish "Yep its a wall or a squieerl".
Hi Tynan, I just wanted to chime in that for me modding is a huge addition to the game.
Please continue to make it easier to mod!
I think I mentioned this previously here, or in another thread.
Adding a waterShallow and waterDeep terrainAffordance to the water terrains would allow modders to make "water buildings". Right now the only equivalent is to allow placement on water and land.
Needs and ThinkTree modding suggestions:
First off, can you change the Needs a little?
Instead of a single field for "colonistAndPrisonersOnly" in NeedDef, can we get individual allowances?
ie: allowPrisoners, allowColonists, allowVisitors, allowAnimals, and allowMechanoids
This will make giving needs to individual pawn classes much simpler and remove the need for hardcoding to remove the Joy need from prisoners.
Secondly, can we get injection points inside the ThinkTreeDef sub-nodes so we don't have to clone the entire sub tree and all it's nodes to add new leaves at specific points?
eg: <!-- Prisoner -->
<li Class="ThinkNode_ConditionalPrisoner">
<leaveJoinableLordIfIssuesJob>true</leaveJoinableLordIfIssuesJob>
<subNodes>
<li Class="JobGiver_PrisonerEscape" />
<!-- Insertion hook for modders -->
<li Class="ThinkNode_SubtreesByTag">
<insertTag>Prisoner_PreMain</insertTag>
</li>
<li Class="JobGiver_PatientGoToBed" />
<li Class="JobGiver_PrisonerGetDressed" />
<li Class="ThinkNode_PrioritySorter">
<subNodes>
<li Class="JobGiver_GetFood"/>
<li Class="JobGiver_GetRest"/>
<li Class="ThinkNode_Priority_GetJoy">
<subNodes>
<li Class="JobGiver_GetJoy"/>
</subNodes>
</li>
<!-- Insertion hook for modders -->
<li Class="ThinkNode_SubtreesByTag">
<insertTag>Prisoner_Needs</insertTag>
</li>
</subNodes>
</li>
<!-- Insertion hook for modders -->
<li Class="ThinkNode_SubtreesByTag">
<insertTag>Prisoner_PostMain</insertTag>
</li>
<li Class="ThinkNode_ConditionalReleased">
<subNodes>
<li Class="JobGiver_ExitMapBest">
<defaultLocomotion>Walk</defaultLocomotion>
</li>
</subNodes>
</li>
<li Class="JobGiver_WanderCurrentRoom">
<maxDanger>Deadly</maxDanger>
</li>
<li Class="JobGiver_IdleError" />
</subNodes>
</li>
Because we don't have injection points inside the trees and node levels, modders have to clone the entire sub-tree and inject the clone before that particular sub-tree is used. This leads to mod incompatibilities and redundancy in the sub-tree cloning itself.
Edit: I have implemented additional ThinkTree injection points in CCL including within the priority sorters.
Quote from: Sam_ on August 02, 2016, 06:33:19 AM
I think I mentioned this previously here, or in another thread.
Adding a waterShallow and waterDeep terrainAffordance to the water terrains would allow modders to make "water buildings". Right now the only equivalent is to allow placement on water and land.
CCLs PlaceWorker_OnlyOnTerrain supercedes the terrainAffordance allowing you to build on any terrain including water. ;)
These might exist/be possible, but from the XML-auto documentation it doesn't seem to be.
For pawns allow a property that determines the healing speed.
Say <baseHealRate>13.0</baseHealRate>
Currently if you give something a high <baseHealthScale>13.0</baseHealthScale> (say like a Thrumbo) it still heals wounds at the normal pace of 1 hp per healing step. Which means it can take ages to fully heal up after being wounded.
For <lifeStageAges> let <ImmunityGainSpeed> be part of life stages (seems to be hardcoded to drop off around 60-ish now, regardless of expected age).
Say
<lifeStageAges>
<li>
<def>AnimalBaby</def>
<minAge>0</minAge>
<ImmunityGainSpeed>1</ImmunityGainSpeed>
</li>
<li>
<def>AnimalJuvenile</def>
<minAge>6.0</minAge>
<ImmunityGainSpeed>1.2</ImmunityGainSpeed>
</li>
<li>
<def>AnimalAdult</def>
<minAge>25.0</minAge>
<soundCall>Pawn_Thrumbo_Call</soundCall>
<soundAngry>Pawn_Thrumbo_Angry</soundAngry>
<soundWounded>Pawn_Thrumbo_Pain</soundWounded>
<soundDeath>Pawn_Thrumbo_Death</soundDeath>
<ImmunityGainSpeed>1.2</ImmunityGainSpeed>
</li>
<li>
<def>AnimalOld</def>
<minAge>180.0</minAge>
<ImmunityGainSpeed>0.9</ImmunityGainSpeed>
</li>
</lifeStageAges>
Edit:
Also the ability to assign restFallFactor to trait definitions, and not just HeDiff stages definitions.
Ex: Traits that make pawn require more sleep overall, or less sleep overall.
In addition to this, the ability to always give certain traits to certain animal / species.
Ex: Make a new trait "Energetic" that halves the rate at which the pawn becomes sleepy. Always make all Wargs have it.
This is a longer thread, with a lot to read. Having played around with some modding for several weeks now, I think I understand a specific minor feature/flaw with the modding system correctly.
As of right now, if you want to mod an abstract class in the Core, you have to either A) modify it in the core directly, or B) copy it to your mod, and likewise copy all classes derived from that abstract class to your mod.
The abstract class thing being confined to the scope of a mod is important, to prevent namespace collisions I think. Regardless, it would be nice to be able to override Core abstract classes.
I think my suggestion would be to add an xml tag for abstract classes that looks like <override>true</override> or some such.
Apologies if I misunderstand how this works presently.
If you want a thing to use a different class in your mods dll you change the xmls <thingClass>Building<thingClass> for example to <thingClass>ModNamespace.CustomBuildingClass<thingClass> The you can extend the main building class or whatever. Is this what you are reffering to?
No, I was thinking of modifying an abstract class (and only an abstract class) in the base game, such that all the classes that derive from it in the base game pick up the changes. The only way that I have been successful at doing that is modifying the abstract class in the Core.
You can Detour using CCL, this is the current accepted way of doing any kind of override to core methods.
Thank you, and understood. I'll look into that. I think the request remains the same, though. The base game should offer the ability to do this, either through incorporating CCL (as previously discussed in this thread), or doing something similar.
Edit; you said "methods". Does a Detour permit overriding of the Core XML/load data?
There is no way the game can change the behaviour of the C# compiler or .Net runtime. What you are asking for is something that is simply impossible. There is nothing Tynan can do to change how the programming language, compiler, and .Net runtimes work.
C# is a strongly typed object-oriented language. You cannot add to a class without inheriting it and if you want the new features to carry forward you need to write new child classes which inherit from your class.
In fact there are no programming languages that would allow what you are asking for. Even loose cruddy ones like Java and Javascript.
What you can do is write extension methods, write your own child class with the functionality you want, and/or use CCL to detour a method or multiple methods.
Really, those are your options.
I don't know why you are talking about the C# compiler or the .Net runtime when I am referring to the XML files the game loads from the Defs directories. It appears that you are saying that there is some strong relationship between that XML and the CLR, but a modder who hasn't touched the game code can't really know that.
As for your sweeping generalization (there is are "no" programming languages that can do that), I would encourage you to cease speaking so grandiosely. Plenty of dynamically typed languages allow runtime modifications of the basic class definitions. Python for example.
python isn't a programming language, it's a scripting language. There's a difference. Although I will agree that the blanket statement of "no" isn't 100% accurate but in C# it's is accurate. But then, all general statements are false.
And in RimWorld there is a direct relationship to the xml and C# classes. Every xml class is a C# class. The tags are the C# fields of the class.
There are *compiled* languages, like lisp, that have all sorts of dynamic properties. I wouldn't be surprised at all if you could modify a base class at run time in lisp. I would bet a lot of money you could. Scripting languages are programming languages, and it is common to refer to them that way. Consider this IEEE article: http://spectrum.ieee.org/computing/software/the-2015-top-ten-programming-languages (http://spectrum.ieee.org/computing/software/the-2015-top-ten-programming-languages). In it, Python is acknowledged to be presently slightly more popular as a programming language than C#.
On the topic, will the CCL detour permit the override of a getter, and therefore permit you to override the fetching of basic attribute data for a class?
I understand that the design of the game is what it is, but it is a bit unfortunate in this particular use case, as it makes certain kinds of modding activities more difficult.
Well, let's leave the debate on what separates a programming language from a scripting language aside as it's non-productive. :)
As to CCLs detouring and property methods (getters and setters) the short answer is "yes" and the long answer is "yes, but."
The "but" in this case is that if the method (any method) is shorter than 32-bytes of IL code then the JIT marks it as a candidate for inlining (not guaranteed that it will, but it's a candidate for). Further, generic methods also have issues with being detoured. So far nobody has seemed to crack the issue to find a way to detour those but in theory they can be detoured.
I suspect the issue with generics is that the compiler creates a template for the method and then creates the proper method at runtime depending on the circumstances of its usage. Without knowing what the method name of the circumstantial usage is, it seems to be almost impossible to make it work correctly.
I've got some, its about how slaver create slaves for trade. Now it just pick any race that have intelegence = Humanlike and put them in his stock. They problem i have, is that i cant strictly define what race\faction slave will belong to. I need it mostly becouse i want to use mechanics of game to support lore of races and factions i have ingame. So situations, when slavers race sell member of their own spicies do not happen ingame.
So i suggest, to change criteria slaver use, or add additional, so we can specify what race\faction slaves he can acquire during stock generation.
Would you kindly change the SkillRecord => pawn attribute from private to public or protected so it can be accessed from a derived class (imo that (being able to access base class objects from derived classes) should be the case for all objects, if you want to make things easier for modders ;) ).
Additionally a way to override/detour get/set methods (this apparently doesn't work with CCL if i read the above entries correctly), would also help.
Thanks
I'm really new to XML and C# and modding with it. The thread has become so large that it's a lot to read so excuse me if my proposition has already been noted.
Unless I'm wrong, I noticed that certain things work with a radius. Explosions, light, affected areas to some effect, it's all circular and based on a radial value, right?
Since this game is based on square tiles, I'd love to see options to define in, let's say, a square or rectangular way. Or perhaps even a rough triangle. Light armatures in real life do a good job of shaping the area that its light directly shines on. I'd love to be able to make TL armatures for the game that light up a rectangular area.
I'd love to be able to easily make a big spotlight 'turret' that has a triangle shaped beam of light shining onto the target.
Or as another example perhaps a claymore mine that explodes in a triangle area in front of it.
EDIT: As someone with ADD, having the eventual long list of mods and having to figure out the right load order when multiple mods have their own dependencies is often reason for me to stop playing a game for a while. I've always run into that problem with the X3 series of games. There's too much info, too much 'cross interference' so to say, too much to figure out where what mod goes in the load order.
So as a user (and testing mods and compatibility), modders having the ability to set up their dependancies and loadBefore/loadAfter + a system that automagically solves (or at least attempts to) would mean the world of a difference!
Also, being able to easily move mods around in the mod list would be nice. Those tiny arrows become bothersome if the list becomes big. :)
I am trying to add more trait-specific mental breaks but i cannot do any for spectrum traits because multiple spectrum traits share the same DefName. So basically, what i'd like is an extra field for mental breaks that lets you specify the trait degree (ie. Neurotic is -1 and Very Neurotic is -2). This way i could make a mental break for the DefName encompassing Neurotic and Very Neurotic and give it an integer that lets it figure out which degree of that trait to associate with
Quote from: Tynan on June 10, 2016, 04:01:27 PM
I'd like to make the game easier to mod, but it's hard to tell, from my perspective, what would be the most useful changes to make to make this happen.
So I'm soliciting requests.
Just try to think of the most important things you'd want that would make modding easier for you. I'll aggregate the suggestions and try to implement the most cost-effective and popular ones.
Thanks all!
Make backstories accesible again.
Support for weapons bigger than 64x64. Like 128x64. I make halberds and then realized that the game shrinks them. Also reach/range for melee weapons?
If I make a halberd, I better be able to hit from the second row.
A lot of classes (like Need and its children) have a this.pawn field which is private or protected. Please make it public.
Actually, many classes have somewhat strange logic for whether their fields are private or public. I've seen a class which had two almost identical fields for holding a float, one private, one public.
Something that I noticed during coding was, that I always had to restart the game to reload my .dll file. It would be helpful, if possible, if you could add the ability to reload all mods while still staying in the world. Maybe as an option in the Debug-Actions menu.
I spend half my time telling people over and over to turn on developer mode and tell me what errors they are getting, instead of "All my pawns stopped moving" or whatever.
I practically have to tell it to every player individually.
Anything that would ease that pain would help. A note in the mod menu, lots of money, a personal help desk, whatever you can spare, really.
Then saving mod configurations / choices per alpha. I have to switch back and forth sometimes to fix errors for the previous alpha. This would help.
I've recently made Hospitality change the ToString of ModPackThingy from identifier to name, so the output log shows all mod names instead of random numbers. This should be in the core game.
Just give <addsHediff></addsHediff> <li>s. Please. I want an operation to give more than just one hediff. That's everything I'm asking for. Make it look like this:
<addsHediff><li>SimpleProstheticArm</li></addsHediff>
+1;-)
I just started modding but a couple things I noticed offhand that threw me off in the C# code:
1) There are basically two namespaces and then just a flat list of a ton of classes. Some sort of package organization would help a lot when looking for certain classes and business logic.
2) Certain types of information are split in how they are accessed. For example, some pawn properties are accessible directly on the pawn but some are accessed through controllers where you send a pawn in as a parameter and it returns the value for it. Bringing these things in line and having a single way to access such properties would be less confusing.
It would be fantastic if we also could add more than one weapon to the same turret, more than one projectile to the same gun, more than one effect to the same projectile, etc.
Example; I have a spotlight mod and the vanilla turret, but I can't make an upgraded turret that also has a spotlight built onto it.
EDIT: I just realised that might be a limitation to that buildings and pawns can only wield a single 'weapon' in their 'hands'. Would be fantastic if that could be altered!
I have a request, actually.
Could we possibly be able to choose a different image for Steam thumbnail than Preview.png?
I kind of like having a small-ish preview.png for the mod selection screen, but it doesn't do so well when it gets to Workshop so I've been using a workaround (https://steamcommunity.com/app/294100/discussions/0/359543951727504577/) to get it to pick up a custom thumbnail for Workshop instead.
What about an external utility to upload mods to the workshop?
So that we don't have to boot the game every time to do it.
Heck, why not a command-line mod checker that returns errors like the devmode console would do? Just have it run the game without all the graphics, or something. So that we can quickly and cleanly get back errors. Again, so that we don't have to boot the game every time we want to test a change that doesn't require loading an actual game. (Though if that were also possible, that'd be even more amazing. It loads all the graphics for testing purposes but doesn't actually render them?)
i would like to see the ability to add more biomes to the game
I prefer a guide than a change. A proper guide not in order to add more assemblies, but to efficiently use functions already made inside. e.g any possible comps, and what they do, Worker Class, etc. A draft would be nice.
It's been mentioned many times before, but here goes again:
Proper hooks to insert mods: After loading a game, before saving a game, before, after and during map generation, on ticks. You may say: Use MapComponents, but as they are right now, they are broken and can't just be added for mods, unless using tricks or CCL. This is stuff mods need out of the box!
Quote from: Orion on August 26, 2016, 10:22:32 AM
You may say: Use MapComponents, but as they are right now, they are broken and can't just be added for mods, unless using tricks or CCL.
Can you elaborate? In what way are MapComponents broken? What functionality do they have that isn't working, specifically?
They aren't broken per-say, but new ones need injection into an existing save.
Overrideable translations for sake of total overhaul mods.
I haven't tested it yet, but it looks like the game will automatically inject MapComponents into save games now.
Quote from: Tynan on August 28, 2016, 07:40:27 PM
Can you elaborate? In what way are MapComponents broken? What functionality do they have that isn't working, specifically?
I'm not checking daily if it suddenly works, but the problem indeed used to be that a new map had to be created so a mod could have its MapComponent. Unlike a developer, a player usually does not want to start over his 150 hour colony and rather does not use the mod. Which makes modding kinda pointless.
Quote from: 1000101 on August 28, 2016, 11:18:17 PM
I haven't tested it yet, but it looks like the game will automatically inject MapComponents into save games now.
If this is the case I take back my complaint about MapComponents.
I actually don't think that's the case.
See this is interesting to me, since you're saying that a feature to add mods to existing savegames is important, which is something I wouldn't have thought of.
This is why we're here :D
Myself I don't play with mods either that can't be added to an existing savegame.
But I'd say 90% of the current mods add fine into existing savegames (many thanks to CCL). But to stay independent of CCL you have to do some major workarounds. I'm creating a new GameObject in the menu with Object.DontDestroyOnLoad(gameObject); that keeps checking if the game is finally loaded to then run some special code. It's a rather icky solution and completely not obvious to new modders.
What's quite a shame is that you can't add new Jobs to existing savegames without breaking the assignments of the existing jobs, unless you add the job at the very end, where another mod might already have a job. It's one of the few things (apart from MapComponents) that don't play well with adding to existing savegames.
I have a request for info for y'all.
The difficulty here for me seems to be that there are a ton of requests - everyone has their own little thing they want changed. Unfortunately we can't cover all these; I really want to make the changes that will have a big impact on a lot of modders at once. Bang for your buck, so to speak.
So it would be really great if modders could discuss and come up with a top-3 list of things that would help a lot of people at once. Consider this an invitation to discuss with each other what would help you all together.
Hey Tynan, maybe it would help if you listed some things that are modder-friendly that are already on your to-do list, for elimination purposes. :)
Perhaps this thread should be locked now that we have an "official channel" for modding requests.
Any requests which have been made in this thread can be discussed and requested through said channel where Tynan/Ludeon can manage them more easily.
Request 1: I would like the game to show clarity regarding the XML "best practice" that has been talked about in this thread (https://steamcommunity.com/linkfilter/?url=https://ludeon.com/forums/index.php?topic=19499.0). If a mod tries to inherit a Core abstract def without having duplicated it inside the mod's XML, please make RimWorld throw an error.
Request 2: Let mods include graphics that can override vanilla textures if they use the correct file path (a) without having to duplicate and redefine the appropriate Core XML, and (b) without having to recreate the appropriate folder inside Core (Steam mods can't do this). For example, if there's a "MyMod/Textures/Terrains/Surfaces/Dirt.jpg" file in a mod, let RimWorld seamlessly use the mod's texture rather than the default. If more than one mod changes the same graphic, mod load order would determine which one "wins".
I have just one request:
As i understand it, A15 "broke" CCL and it might take some weeks for that team to
update it, so it would really help if developers of coremods or mod-libraries could be
sure to have access to the code that they need so they can provide the compatibility
for mods. I could imagine that, if such breaks happen often, developers of such coremods
and libraries simply give up.
While the corecontent of RW is very nice, for small teams, contentcreation
might be much work. Making the game as moddable as possible in my view is then
quite important so the community can add features and content to enhance the game and
should need arise, keep it alive.
*grins*
I can understand though that one might frown upon releasing any amount of code to the public
if one uses really disgusting names for the variables.
In any case, this is a wonderful "game" already (i personally ab-use it more as a simulation).
I am warmly reminded of "Little Computer People" ;D
Zhentar over on the CCL thread just posted this:
https://ludeon.com/forums/index.php?topic=16599.msg265091#msg265091
its a version of ILSPY that successfully decompiles iterators, they are very very close to perfectly decompiled. I would suggest every modder grabs this version, it means no more reliance on needing the source code. I cannot thank him enough.....
^ What he said. There may be a little bit of guesswork needed, but the difference is like night and day.
Assuming you document your code, would it be feasible to release the documentation with new versions of Rimworld? This has probably been suggested already, my apologies if that is the case.
It would be nice if fuel could be defined in a separate XML or inside the fuel items rather than inside the objects that take fuel (in other words, the various fueled crafting benches and the generator). As it is now it would be a very bad idea to add a new item that is suitable as fuel to the fuel filter of those fueled structures because it would create so many potential conflicts with other mods.
As an example, currently we can use RecipeDefs instead of declaring the recipe inside the objects ResourceBase - this allows a mod to make an item craftable without creating a conflict with mods that changes the stats of an item; it would be really nice if a similar thing could be done for fuel.
XML comments on the game objects.
I'd like to see trap damage types moved to xml defs, can't find it there - especially this <trapDamageCategory>Sharp</trapDamageCategory> - to define other classes like "sharp" there. Allowing poison traps, or traps that deal certain damage type like weapon projectiles. Or maybe the structure is different, and shouldn't be used like this?
Quote from: TrueDestroyer on October 02, 2016, 04:43:30 PM
I'd like to see trap damage types moved to xml defs, can't find it there - especially this <trapDamageCategory>Sharp</trapDamageCategory> - to define other classes like "sharp" there. Allowing poison traps, or traps that deal certain damage type like weapon projectiles. Or maybe the structure is different, and shouldn't be used like this?
trapDamageCategory is based on DamageArmorCategory, so basically you would like a DamageCategoryDef I think rather than just trap damage.
Quote from: TrueDestroyer on October 02, 2016, 04:43:30 PM
I'd like to see trap damage types moved to xml defs, can't find it there - especially this <trapDamageCategory>Sharp</trapDamageCategory> - to define other classes like "sharp" there. Allowing poison traps, or traps that deal certain damage type like weapon projectiles. Or maybe the structure is different, and shouldn't be used like this?
I had the same reasoning about "fermentation barrels" mechanic.
AFAIK for now, there is no way to define ingredients and products in XML only (like with other production buildings and recipes).
Having this working like other production buildings/recipes could allow us to easily make custom alcohols but also a ton of other things that requires items to "wait" until something happened; if we apply this method to other modded buildings. Like drying food, having to let smokeleaf to dry before consumption, maybe compost, etc
The same goes for butchering and corpses mechanics. It could be nice to have it more customisable via XML.
No idea if this has been mentioned before, but the ability to make a trait be only allowed for males or only allowed for females would be nice. I've got some Fallout ones that would be unusable/require a bunch of extra tweaking to make function.
Ashborn, that's already possible. There are defs for commonality and commonalityFemale so you can set either one to 0 and have it only apply to one gender.
https://github.com/RimWorldMod/RimworldModdingFiles/blob/master/Defs/TraitDefs/Traits.xml
Example for male-only trait (random value):
<commonality>1</commonality>
<commonalityFemale>0</commonalityFemale>
And female-only (random value):
<commonality>0</commonality>
<commonalityFemale>0.4</commonalityFemale>
Quote from: Dingo on October 09, 2016, 01:19:05 AM
Ashborn, that's already possible. There are defs for commonality and commonalityFemale so you can set either one to 0 and have it only apply to one gender.
https://github.com/RimWorldMod/RimworldModdingFiles/blob/master/Defs/TraitDefs/Traits.xml
Example for male-only trait (random value):
<commonality>1</commonality>
<commonalityFemale>0</commonalityFemale>
And female-only (random value):
<commonality>0</commonality>
<commonalityFemale>0.4</commonalityFemale>
Thanks, I asked a few people on the slack and they said there wasn't anything like that.
I would like to see the core textures actually in the folders. I see that I can add them to overwrite core textures, but it would be nice to just have a folder of png files to edit to modify instead of having to create each one manually.
On a side note, I saw a post with all the resource textures as a zip file for A13, but the link did not work. Is there a way to get core textures to start with?
Marc-
SHAZAM!
https://ludeon.com/forums/index.php?topic=2325.msg265704#msg265704
That shazam made me smile
Quote from: Tynan on August 29, 2016, 06:17:03 PM
So it would be really great if modders could discuss and come up with a top-3 list of things that would help a lot of people at once. Consider this an invitation to discuss with each other what would help you all together.
I think something most of the coders can agree on is some sort of built-in injection method, that allows us to override any function. This is something that I think CCL adds in, but it would be great to have it buit-in. As it is right now I'm basically always copying my injection code from one mod to the next. There are also a few simple relfection methods I've written to help with getting/setting/invoking private members/methods that would be nice to just have built-in as well.
Quote from: kaptain_kavern on October 02, 2016, 04:58:44 PM
I had the same reasoning about "fermentation barrels" mechanic.
AFAIK for now, there is no way to define ingredients and products in XML only (like with other production buildings and recipes).
Having this working like other production buildings/recipes could allow us to easily make custom alcohols but also a ton of other things that requires items to "wait" until something happened; if we apply this method to other modded buildings. Like drying food, having to let smokeleaf to dry before consumption, maybe compost, etc
The same goes for butchering and corpses mechanics. It could be nice to have it more customisable via XML.
Yeah this is beyond infuriating. I thought that the new brewing mechanics would make things easier for my mod (Can I Brew It), but it turned out to be another piece of code that I don't have the skill to edit...
dont know if it came up, but a quick start button. (there was a mod for that back then.) but if you enable dev mode and start the game up there should be a button to quick start a colony. one click and it starts your colony from the menu, with all random stuff.
not sure about other modders maybe its just me and my modding progress. but i usally enable my mod i m working on, add something and then test it out if it workes as intended. if i forgot something etc. for textures to compare them to their vanilla conterparts. so i usally start the game up alot during making a mod, starting a new colony, just to be ingame and test some minor things out. close it again if i changed something and start up again. at the moment and with the scenario this takes a lot of clicks, so a button to speed this up would help a big help for any mod someone is making i assume.
thx for reading, great game btw love it ;)
Quote from: sulusdacor on October 18, 2016, 05:57:30 AM
dont know if it came up, but a quick start button. (there was a mod for that back then.) but if you enable dev mode and start the game up there should be a button to quick start a colony. one click and it starts your colony from the menu, with all random stuff.
not sure about other modders maybe its just me and my modding progress. but i usally enable my mod i m working on, add something and then test it out if it workes as intended. if i forgot something etc. for textures to compare them to their vanilla conterparts. so i usally start the game up alot during making a mod, starting a new colony, just to be ingame and test some minor things out. close it again if i changed something and start up again. at the moment and with the scenario this takes a lot of clicks, so a button to speed this up would help a big help for any mod someone is making i assume.
thx for reading, great game btw love it ;)
Make a shortcut, and add "-quicktest" to the end of the target. That'll launch you straight into a fresh colony.
Quote from: sulusdacor on October 18, 2016, 05:57:30 AM
dont know if it came up, but a quick start button. (there was a mod for that back then.)
It was from CCL
didnt know about the quicktest thing, thx. kinda makes my point invalid^^
As RimWorld has become more popular, there are more modders and more mods on the forums.
Putting mods into mod lists (that is, topics with one mod per post) reduces the number of threads needed, but it doesn't necessarily make it any easier to find what you're looking for on the Releases board.
Apart from posting in the Announcement topic, I've given up on posting mod releases because it's easier to just tell people to look at my site or on Steam.
hope thats not a thing already like my last suggestion^^
would like to see some sort of compatibility mechanism to pack inside one mod. so if mod A is used with mod
B, the game would find the files the modder specified in his mod A to use if mod B is active with it together. hope that makes sense. not really a easier to mod thing, but more a mod managment thing. if this is the wrong place to post this, please someone move it.
let me explain a bit:
currently you would have a bunch of seperate downloads for one mod. compatible version with a, compatible version with b, compatible verison with a+b and so on. with steam there will probably be much more mods poping up and doing the same thing. since you have to upload basicly a new mod to add a compatible version this can become quite a challenge. especially when updating your mod and the compatible versions or adding new stuff to the mod.
one of the miniaturisation mods uses some sort of such system in a smaller manner i think(https://ludeon.com/forums/index.php?topic=22763.0). where it checks if another mod is used and then acts accodingly. i would love to see this for all mods. which would be either some sort of file where i could say if mod A is active with my mod, use these files. if not use these. or maybe for xml only some sort like the comment system (would leave all mods using assemblies behind maybe), where i can say read this part if mod A is runing with my mod, if not skip this part. i'm not sure if thats possible or would slow the game to a crawl when loading up the mods. but from a practical standpoint would be nice. since it would only have one mod to update with its included compatible files and not have several. hope it makes sense. more a mod managment thing not so much the process itself.
completly other thing, a bit in the same "several own mods" realm. a language aboutinjected thing would be cool. so that you could have the right mod names in the mod list ingame, with the users language in the description. minor thing and i personaly dont mind. but was adding some files myself and ran into that.
last thing this time totaly on the subject: have mostly done xml modding myself and no coding knowledge so might be a bit biased here. in general i feel like the xml modding is bit easier to get into. so having a lot options there i alwyas a good thing in my eyes. i like that you can change most visible ingame stats of the buildings (like size,power,glow etc) and i think going with this route if future building thingclasses or other stuff is added might be quite good for modders (yeah like the fermenting barrel). i feel it is usally a good thing if you can change the visible stuff in game in the xml. so if you start out you have some sort of fast feedback when trying out stuff. and then have the coding part for the "behind the scenes" stuff. in general i feel the game is a lot of fun to mod and the current system with xml and coding is quite good (from a mostly xml modders perspective).
Obviously a mod manager, mod conflict checker and possibility to less conflicts by merging mods. Like mod a creates water. mod b modify water to black colour. mod c modify water to 64 stackable.
Merging> mod total = water black, stackable 64.
Instead of replacing filex mod for filex mod ( that causes conflict ). What about merging option?
A Listener\Observer system in which we can hook into important game events such as; Game loading, loaded, save, saved a map.
Also listeners\observers in general for pawns and things.
For how it would work simply look at the Java AWT\Swing libraries for reference in how to add a listener.
interface GameStateListener {
void OnGameStateChange(); //A game state change has occured. e.g Entered play mode, went back to main menu or custom state.
bool OnGameQuitting(); //Return true if it vetoes the quit.
void OnGamePostQuit(); //The game has pretty much quit and is ready to go back to OS.
void OnMapLoading(Map map); //When the map have started to load.
void OnMapPostLoad(Map map); //When the map is loaded and entered a playable state.
void OnMapSaving(Map map); //When the map have started to save.
void OnMapPostSave(Map map); //When the map has finished saving.
void OnMapCleanup(Map map); //When the map is in the process of being unloaded.
void OnMapSetup(Map map); //When the map have loaded the save data but have not yet started putting all things to their positions.
}
This should get a rough idea of what i'm looking for.
Edit:
A way to add our own custom LookMode handlers would be useful for custom data types for all the Scribe classes. During the current creation of my mod i ran into that it was not very flexible in the way the Scribe_Values which is used by Scribe_Collections worked especially.
Example save output (http://pastebin.com/H5y93e8Q) of how it currently looks with the ugly way of needing to use Deep LookMode and IExposable implementing classes in order to save data that differs.
Some interface that let you hook in with your own "LookMode" during saving and loading could be neat i guess.
Please set Building_PsychicEmanator and WorkGiver_CookFillHopper classes as public instead of internal. :)
An Object Testing Arena similar to the one in Dwarf Fortress to quickly get into a world to test a mod.
read the readme that comes with the game, game in devmode when testing mods and use the -quicktest (or whatever it is now) command line parameter on the games shortcut.
I will sacrifice my firstborn to get Tynan to stop marking things private and forcing me to reflect them.
Quote from: Psychology on December 24, 2016, 02:13:16 PM
I will sacrifice my firstborn to get Tynan to stop marking things private and forcing me to reflect them.
Hah, I feel your pain! A number of times I have run across a static method and thought "yesss! it's static, i can send it all the necessary params!" and then realized it was private and had to copy the whole method. I suppose I could have used reflection...but that doesn't seem like any less of a hack than copying the logic.
Also, composability is an issue. There are a LOT of methods that do too much where I would really love to have a helper method that does part of whatever the logic is so I can use just that. This has also caused me to copy methods, ripping out for example one if statement that separates two cases. A great example here is drawing the mood bars in the colonist sheet. It draws the mood bar and the label all at once. It would be really helpful if this kind of thing was multiple methods.
It's called an accessor method, Tynan! You can keep your precious private values AND make them accessible to other methods.
Also, it would be nice if there was some documentation on how to use the various Rand methods. Rand.MTBEventOccurs() is kind of baffling.
Quote from: GiantSpaceHamster on December 27, 2016, 04:58:07 PM
I suppose I could have used reflection...but that doesn't seem like any less of a hack than copying the logic.
Reflection in general is a standard that increases compatibility with other mods. You don't want to touch anything you don't have to, and reflection is just looking.
Hi,
i'm pretty sure i and like half the people that (try to) make mods for Rimworld have already requested repeatedly. Kindly make all variables and methods public! If you want to make the game easier to mod!
I just stumbled over your most recent questionable use of the above in the GenFilePaths class. ModsConfigFilePath is public, its required ConfigFolderPath on the other hand is private, as is FolderUnderSaveData which is used by ConfigFolderPath. And finally you have SaveDataFolderPath, used by FolderUnderSaveData, which is again public. Now kindly explain to me what sense does that make?
Also, it wouldn't hurt to implement a generic Mod Options Tab/Menu (similar to what CCL had with its ModConfigurationMenu), so that people that want to make configurable mods don't have to interfere with/reflect general game option tabs.
Thanks
regards
zlj
When I attempt to put the .pdb file that has the debug info for my mod's dll into my mod's assembly folder Rimworld crashes on startup. It would be great if I was able to hook in to debug so I can use a profiler to see where the performance problems in my mod are.
So pawn.Faction is public, but pawn.factionInt is protected? But they are both Faction objects? What is the difference between them? Why does factionInt have to be protected, especially when you use both in the same method?
Quote from: Psychology on December 31, 2016, 10:21:49 PM
So pawn.Faction is public, but pawn.factionInt is protected? But they are both Faction objects? What is the difference between them? Why does factionInt have to be protected, especially when you use both in the same method?
This is a perfect opportunity for a bit of a design/C# lesson. Pawn.Faction is a getter for Pawn.factionInt. It's a way to expose the ability to retrieve the value of factionInt without exposing the ability to
change the value. If you look at the code for Pawn.Faction, there is only a getter declared ("get"), no setter ("set"). This also provides the ability to change how the faction is defined without changing the API. If factionInt was renamed or turned into a calculation the value could still be exposed with the Faction accessor and mods using it would not need to change their code.
This is proper design.
Quote from: GiantSpaceHamster on January 01, 2017, 08:12:39 PM
Quote from: Psychology on December 31, 2016, 10:21:49 PM
So pawn.Faction is public, but pawn.factionInt is protected? But they are both Faction objects? What is the difference between them? Why does factionInt have to be protected, especially when you use both in the same method?
This is a perfect opportunity for a bit of a design/C# lesson. Pawn.Faction is a getter for Pawn.factionInt. It's a way to expose the ability to retrieve the value of factionInt without exposing the ability to change the value. If you look at the code for Pawn.Faction, there is only a getter declared ("get"), no setter ("set"). This also provides the ability to change how the faction is defined without changing the API. If factionInt was renamed or turned into a calculation the value could still be exposed with the Faction accessor and mods using it would not need to change their code.
This is proper design.
No, it's not, because you then proceed to use pawn.factionInt instead of pawn.Faction. If you make a getter,
use it to get!! I'm well aware of accessor/mutator methods. The problem is the lack of consistency.
On that note, why is every Recipe class public
except for Recipe_RemoveBodyPart?!
This sounds kinda of obvious but maybe less game breaking updates? I know its alpha but it seems kinda of odd that each update breaks all the mods. I have seen other games in alpha that don't break all their mods each version update.
I know that some of this may be obvious, but having a detailed API for anyone with little to no programming experience, also maybe us JSON? Starbound uses it and its relativly easy to mod the game as well as patch (update vanilla files) without a dirty copy (just replacing vanilla files. This would also ensure that the vanilla files stay safe and avoid unnecessary errors. I know this may involve redoing parts, but you did ask what would make the game easier to mod, also with Unity, not sure if you can use JSON.
Guys, this is turning into a debate on coding standards. We should keep this to small(ish) things that are easy to do for Tynan. For example, asking Tynan to switch to JSON is pretty ludicrous, it's not gonna happen at this stage.
Also, for the accessor/private field access being used intermittently, we might just be seeing compiler optimizations. Not sure that's the case here, but it's entirely possible simple getters are being inlined.
Quote from: Fluffy (l2032) on January 06, 2017, 12:43:46 PM
For example, asking Tynan to switch to JSON is pretty ludicrous, it's not gonna happen at this stage.
We are technically still in Alpha... He did ask what would make modding easier, so I just gave my 0.02 cents that is all.
First of all, hediffs are a glorious, incredibly effective modding tool. I love them. A customizable, class-linked property that can be placed on pawns at my discretion without conflicting with any other mods? Hell to the yes, what a great feature. However, AFAIK there's no easy way to add HediffGiverSets to vanilla races without overwriting the core XML. Using HugsLib, I can just grab the list of ThingDefs with OrganicStandard and add my own custom givers to the set, but it would be great if there were a way to do it with XML, like with ThinkTrees.
There seems to be an oversight in Verse.ResearchMod...
This is the class that is used in ResearchProjectDefs to call C# workers to do fancy things, but the Apply() method on it is not virtual, so can't be overridden, and the specialAction Action field that is called in Apply() is private, so can't be assigned to.
(without dirty tricks, anyway).
In fact, the whole researchMods field on researchDefs is broken -> Exception parsing <li>Fluffy_Breakdowns.ComponentLifetimeOne</li> to type Verse.ResearchMod: System.ArgumentException: Exception parsing Verse.ResearchMod from "Fluffy_Breakdowns.ComponentLifetimeOne" ---> System.ArgumentException: Trying to parse to unknown data type ResearchMod. Content is 'Fluffy_Breakdowns.ComponentLifetimeOne'.
at Verse.ParseHelper.FromString (System.String str, System.Type itemType) [0x00000] in <filename unknown>:0
--- End of inner exception stack trace ---
at Verse.ParseHelper.FromString (System.String str, System.Type itemType) [0x00000] in <filename unknown>:0
at Verse.XmlToObject.ObjectFromXml[ResearchMod] (System.Xml.XmlNode xmlRoot, Boolean doPostLoad) [0x00000] in <filename unknown>:0
Verse.Log:Error(String)
Verse.XmlToObject:ObjectFromXml(XmlNode, Boolean)
Verse.XmlToObject:ListFromXml(XmlNode)
System.Reflection.MonoMethod:InternalInvoke(Object, Object[], Exception&)
System.Reflection.MonoMethod:Invoke(Object, BindingFlags, Binder, Object[], CultureInfo)
System.Reflection.MethodBase:Invoke(Object, Object[])
Verse.XmlToObject:ObjectFromXml(XmlNode, Boolean)
System.Reflection.MonoMethod:InternalInvoke(Object, Object[], Exception&)
System.Reflection.MonoMethod:Invoke(Object, BindingFlags, Binder, Object[], CultureInfo)
System.Reflection.MethodBase:Invoke(Object, Object[])
Verse.XmlToObject:ObjectFromXml(XmlNode, Boolean)
System.Reflection.MonoMethod:InternalInvoke(Object, Object[], Exception&)
System.Reflection.MonoMethod:Invoke(Object, BindingFlags, Binder, Object[], CultureInfo)
System.Reflection.MethodBase:Invoke(Object, Object[])
Verse.<AllDefsFromAsset>c__Iterator1ED:MoveNext()
Verse.ModContentPack:LoadDefs()
Verse.ModContentPack:ReloadAllContent()
Verse.LoadedModManager:LoadAllActiveMods()
Verse.PlayDataLoader:DoPlayLoad()
Verse.PlayDataLoader:LoadAllPlayData(Boolean)
Verse.Root:<Start>m__735()
Verse.LongEventHandler:RunEventFromAnotherThread(Action)
Verse.LongEventHandler:<UpdateCurrentAsynchronousEvent>m__733()
As a newbie Rimworld modder I was surprised that it was impossible/difficult to just override textures and items. I expected mods to "stack", overriding any resources/definitions lower in the mod list. This is how most games I've modded/played seem to behave.
Just changing a texture means having to put the file into the Core mod directory or duplicating the Thing definition in the new mod directory.
A new hotbar tab for Modded items, only available when mods are enabled, that allows for each mod to list its objects, orders or UI elements respectively
The biggest thing holding me back from doing more modding is the lack of documentation. I've release one mod, and I'm fairly happy with the results, but it required a lot of time just learning what I could and couldn't do aside from the actual progress on the mod itself. I have a list of 8 or 9 more mods I might be interested in making but I simply cannot justify the time expenditure to figure out the modding API for everything in addition to the time it will take to do the actual mod logic once I know how things work.
I am aware of the modding info on the wiki and have been searching the mod forums but that is still time consuming and doesn't really cover any details, it's all very high level. What is needed is a lot more depth on what is available and what all the individual fields mean. For example, the existing Core 'mod' is insufficient because that does not (a) give you a schema that defines what the available options are in one place or (b) tell you what any of the fields mean or how they are used.
I'm not giving up on modding, but I certainly won't have the time and energy to make all the mods I might be interested in.
More clear XML examples for item creation and effects.
when game in dev mode, i want additional button in menu, 'reload mods' for faster reload my edited mod
how it looks now (game is always running):
fix your mod
switch to game
go to mod list
uncheck mod, 'ok'
wait
go to mod list
check mod, 'ok'
wait
how it can seen:
fix your mod
click 'reload mods'
wait x2
Quote from: Poroh on January 18, 2017, 07:03:28 AM
when game in dev mode, i want additional button in menu, 'reload mods' for faster reload my edited mod
how it looks now (game is always running):
fix your mod
switch to game
go to mod list
uncheck mod, 'ok'
wait
go to mod list
check mod, 'ok'
wait
how it can seen:
fix your mod
click 'reload mods'
wait x2
Mods are not loaded correctly (in some instances) unless the game is restarted so all of that is moot currently. Just so you know I would never test a mod without restarting the game.
Categories for mods.
Any core mods like huglibs showing up in their own box instead of being dumped randomly in the modlist. This way it makes it easier to locate and activate that core mod.
Mods in the..mods list should be organized in alphabetical order. This would cut down on time wasted searching for hugs libs or any other Core. Failing that having Cores be auto placed at the top of the mod list once inserted into the mod folder would also be a big time saver.
Creating new Defs is... somewhat magical. I appreciate this feature intensely.
I noticed that linkableFacilities, the building comp that controls what said building can link to, requires the base object to reference what can link to it. Current issue with this setup is that any mod that wants to add onto this feature needs to override whatever is there first, at least with vanilla methods.
Wouldn't it make more sense for the linking object to have a list of objects it can affect, rather than having the base object have a list of objects that can affect it? It would definitely make it more mod-friendly when it comes to compatibility. For example, in a vanilla scenario, the vitals monitor would have the listing to say it can attach to the bed, rather than the bed having a list saying the vitals monitor can attach to it.
Quote from: Goldenpotatoes on January 24, 2017, 09:31:46 PM
I noticed that linkableFacilities, the building comp that controls what said building can link to, requires the base object to reference what can link to it. Current issue with this setup is that any mod that wants to add onto this feature needs to override whatever is there first, at least with vanilla methods.
Wouldn't it make more sense for the linking object to have a list of objects it can affect, rather than having the base object have a list of objects that can affect it? It would definitely make it more mod-friendly when it comes to compatibility. For example, in a vanilla scenario, the vitals monitor would have the listing to say it can attach to the bed, rather than the bed having a list saying the vitals monitor can attach to it.
I believe you can have the linking object have the list, pretty sure it works both ways, just like recipes. Both the recipe, and the workbench can have the recipe in the XML, it just depends on how you want that implemented.
Quote from: neur0breed on January 26, 2017, 07:58:19 AM
I believe you can have the linking object have the list, pretty sure it works both ways, just like recipes. Both the recipe, and the workbench can have the recipe in the XML, it just depends on how you want that implemented.
It works both ways, but it wouldn't properly apply the modifiers as far as I'm aware.
For a vanilla scenario, adding the list to the vitals monitor instead of the bed would have the bed applying modifiers to the monitor and not vice verse. I may be wrong on that, but I'm pretty sure that's how it works.
Vertical scroll bars for the research screen. Sometimes the research projects drop off the bottom of the screen and become inaccessible.
https://ludeon.com/forums/index.php?topic=30299.0
Sorry if this has already been suggested but loading a save from the command line would be nice
A Scrollbar or Resizable Pawn Character Menu.
Some Mods add Skills that can't be seen on the menu, because there is no room.
I vote for more XML documentation. For example there are some fields that aren't in the current xml documentation but exist, such as race immunity gain speed. Also maybe some explanation on what differnt things do.
I'm going to use a specific example of a situation I ran into recently, but this concept applies to a lot of areas of the code base.
RimWorld has a sort order for displaying colonists, represented in the colonist bar (ColonistBar.cs). The logic for generating this sorted list is in a private method within ColonistBar.cs. This makes it difficult for mods to use the "RimWorld" sort order for pawns to present data in the same order. When the colonist bar is enabled, the public accessor ColonistBar.Entries provides the sorted list, but when disabled the list is empty. If there was a way to retrieve the sorted list of colonists regardless of whether the bar was enabled or not that would be helpful (whether that would be populating the entries even when the bar is hidden or a separate method somewhere else that the colonist bar uses).
More generally speaking there is a ton of business logic that's private or embedded in methods that do more than just that thing which forces mods to copy large chunks of RimWorld code, which is a maintenance nightmare. I realize that the reason the list is not being generated when the bar is hidden is to not run the calculations for generating the list, but I think there are going to be situations where such state-dependent calculations may be desirable by modders regardless of whether or not the one feature in the vanilla game that uses it is enabled at the time or not.
That would be really great to allow us to easily detour methods without destroying original ones.
There is a common method used on some windows functions.
In the beginning of every method's code are filled with "nop" assembly instructions. A certain number (5 ?), enough to fit a "call" or "jump" instruction to the detouring method.
The new method that could decide whether to call the original method or not.
Being able to edit a pawn available skin/hair colors and body shapes through the race xmls. I tried to edit those things by decompiling the Assembly-CSharp.dll only to get errors while trying to generate a new world.
I just wasted 65 minutes of my limited lifespan trying to do a thing that could have been done in 5. And this is not fun at all.
can you please move DamageArmorCategory and other damage/armor stuff into xml's from .dll? It will make modding/adding weapons and armors more vary, and modding/adding types of damage/armor much easier and handy.
Quote from: dniwe_kore on February 24, 2017, 09:38:34 AM
can you please move DamageArmorCategory and other damage/armor stuff into xml's from .dll? It will make modding/adding weapons and armors more vary, and modding/adding types of damage/armor much easier and handy.
Not sure what you mean by this, projectiles deal a damagedef, the damagedef has the armour category on it. This is already available in xml. Might need to explain exactly what you want to do here.
i wanted add new armor type to minimize stun duration, instead of blunt armor type. But because of DamageDef
public DamageArmorCategory armorCategory;
i can't. I'm bad at coding, but i guess vanilla DamageDef takes armor types from vanilla DamageArmorCategory. And if i'm going to add new armor types, i guess i should add them into vanilla DamageArmorCategory, changing CSharp library.
Also i guess interface takes values from DamageDef, so adding my own DamageDef will cause more stucks for me.
Of course i can change default types of armor(blunt+sharp to pysical, free blunt to blinding defence for stuns), but having opportunity to add new will be useful and good.
I'm sorry, if i'm wrong and if atm i aleady can add armor types.
[attachment deleted by admin due to age]
What would make the game easier to mod is the implementation of hard and soft dependencies.
A few people have mentioned dependencies in general in various places but from what I have seen they usually only refer to hard dependencies. I've just recently started modding on a new project with Rimworld, but I've run into issues with implementing a modular modpack. It's easy to implement hard dependencies outside of the game simply by saying 'You need Mod-Core loaded to run Mod-1 and Mod-2", but what about the issue where Mod-3 could be standalone, using vanilla recipes and resources, but if Mod-1 exists then use resources from that instead.
An example I have is with a building that uses the stuff categories. It is in a standalone mod using this:
<stuffCategories>
<li>Metallic</li>
<li>Woody</li>
<li>Stony</li>
</stuffCategories>
But, another mod I have which could be loaded before adds a lot of materials, specifically a Plastic stuffCategory. I could make the mod have a hard dependency and just define it as:
<stuffCategories>
<li>Metallic</li>
<li>Woody</li>
<li>Stony</li>
<li>Plastic</li>
</stuffCategories>
But, the point of this post is the case where <li>Plastic</li> needs to be optional. I'm just thinking of a system I would add, or looking to add with my own assemblies but considered also posting here, which can define hard and soft dependencies. One option I have only considered so far is having an .xml in the About file for dependencies, defining each as hard or soft, prompting the user when a hard dependency is not met, and then for soft dependencies using xml attributes to define the correct block to use. So, to use the above example to illustrate you could have;
<ThingDef Name="Bench" Abstract="True">
<allOtherElements/>
</ThingDef>
<ThingDef ParentName="Bench" Dependency="None">
<DefName>Bench</DefName>
<stuffCategories>
<li>Metallic</li>
<li>Woody</li>
<li>Stony</li>
</stuffCategories>
</ThingDef>
<ThingDef ParentName="Bench" Dependency="Mod-1">
<DefName>Bench</DefName>
<stuffCategories>
<li>Metallic</li>
<li>Woody</li>
<li>Stony</li>
<li>Plastic</li>
</stuffCategories>
</ThingDef>
Obviously the issue here results in how to handle the default option, or what to choose when Mod-1 isn't loaded. Instead of None maybe Default when no other dependency is valid. Also, what do you do with multiple soft dependencies.
I originally thought of this when I was making a mod for Factorio, in which modders use LUA instead of XML files to mod the game. The soft dependencies are enforced using standard conditional logic such as "if Mod-1=true then load this else load this". So, I'm looking into how I could add something similar to Rimworld, even if I have to hardcode my mod packs dependencies in an assembly somehow.
I'm not even sure if this is feasible to mod this in Rimworld in it's current state, or how much I would have to break to make it happen, but this is an idea I had that resolves a large number of issues with my current project that I thought I would share.
@Tynan, it seems when reading through the posts in this topic, the requests seem to center around two Major Focii:
1.) Please provide thorough documentation. (for example there a lot of "I heard that", "I noticed that", and "[So and so said]", comments in the forum as well as direct requests for docs.)
2.) The other one is "Public Classes".
3.) The third seems to be a wash.
My own opinion would be to make the 2 classes of Coders happy by Giving them solid templates or docs re XML files, for the XML folks, and then public classes more often, as well as hopefully comments or documentation in say, "Verse", "Rimworld" and "Verse.Sound".
Suggestion: Built-in Profiler
In the central time slice distributor/visitor track the portion of time spent in each mod and make that a visible pie chart in-game, when in developer mode.
The purpose is to apply some sense of competition for best use of the limited CPU cycles through easily understood comparative performance. It would help catch those "just for now" hacks that create lag.
I not sure if its been mentioned:
I think there is a need to change how we add animals into the various biomes. Because every mod that adds new wild animals tend to replace the same biomedefs xml files; as a result, there is a conflict.
just my 5 cents
It would be good if there were some templates for mods. Like we just need to draw a weapon/animal sprite, change some parameters in that template like health, dps, where it spawns, etc. And the mod would be ready
Quote from: AngleWyrm on March 04, 2017, 09:16:18 PM
Suggestion: Built-in Profiler
In the central time slice distributor/visitor track the portion of time spent in each mod and make that a visible pie chart in-game, when in developer mode.
The purpose is to apply some sense of competition for best use of the limited CPU cycles through easily understood comparative performance. It would help catch those "just for now" hacks that create lag.
I would prefer to use the CPU use for every function (or at least a limited amount). therefore for every mod aswell.
Often I would like to see that part of a single mod is spending much CPU time.
Quote from: Plymouth on June 10, 2016, 05:13:37 PM
I know it is a far call, but in case of changes, a sort of converter from old XML parameters to new ones would be a nice thing to have. Of course it is not something necessary, only very handy. Would save a lot of time in mod updates during alpha transitions, if such a program existed.
That would be a massive and ongoing project, so I'm afraid it's a bit out of the cards. I'm really looking for simple things that'd be useful forever.
[/quote]
I just got into this mod scene with [A16]... has this a big problem in the past? I already have a python script that basically does exactly what you're asking for (for a different application) --it would be rather straight forward to reconfigure it for RimWorld mod updates/conversions.
can i suggest more tutorials?
there are many mod categories that plenty of modders can contribute on if there are more tutorials, since few people wanna scan all the xml defs files and trying to figure out which one actually does what, so tutorials can help minimize the repetitive effort required :
1)add/modify animal pawns : (FAQs) how to add or modify animals? what are the commonly relevant defs and an explanation for what it does. (ie : animal life stages, animal products through handling, animal products through butchering, etc..) can you force an animal to spawn at a certain life stage (baby)? can you milk them to produce chem fuel? can you butcher them and get components? etc..
2) add/modify humanoid pawns (pc/npc) : also good tutorial would be how to create custom playable/npc races
3) add/modify mechanoid pawns :
4) add/modify weapons/apparel :
5) add/modify furniture :
6) add/modify building :
7) add/modify crafting and work stations : this is probably more complicated than others.
etc..
post example tutorials of those things and you're likely to get flooded with tons of new mods adding content and graphics.
----------------
edit :
as an addendum :
look at adding a new animal pawn for an example. in order to do so you need to add entries to the following xml files stored in different folders :
-ThingDefs_Races > Races_Animal_YourNewAnimal : add a new xml file here to create a new "race" for your animal. has defs for move speed, attacks, life stages, graphics, draw size, market value, temp range, milkable/shearable/eggs, herd boolean, body size, hunger rate, food type, leather product, wildness, pack animal boolean, spawn biome, etc..
-ThingDefs_Items > Items_Exotic, Items_Resource_AnimalProduct, Items_Resource_Stuff : controls items spawned when animal is butchered, milked, sheared, or when laying eggs. : (defs defined here are called in ThingDefs_Races > Races_Animal_YourNewAnimal)
-Misc > LifeStages : it controls the lifestages, it's defs are later called in ThingDefs_Races > Races_Animal_YourNewAnimal
-Bodies > Bodies_Animal_YourAnimalX : defines the anatomy of your new animal
-RecipeDefs > Recipes_Surgery_RemoveOldScar, Recipes_Surgery_repairBodyPart : for healing your animal (refers to the defs defined in Bodies > Bodies_Animal_YourAnimalX)
^and the only reason why i know these things is coz i looked at the defs in an already existing mod, otherwise i probably would not have any idea which xml does what and which ones are interconnected with one another.
yet even with this as a guide, it's still quite confusing because of the interconnected defs/xmls and editing one file could break code if other affected xmls aren't edited as well.
so there should be a more easier way to add new content/assets.
Quote from: Linq on December 24, 2016, 02:13:16 PM
I will sacrifice my firstborn to get Tynan to stop marking things private and forcing me to reflect them.
^ Pretty much this. It's really awful for inherited classes in mods. I'm sure it makes rimworld more stable, but I've basically just given into mass copy/paste instead for mods. For instance, infinidrill is just a slight change on the deep drill, but it was just easier to paste it all and change 2 or 3 functions. Which means if there's a bug fix in deep drill I'm going to miss it for my mod T_T
At the very least protected by default for classes that are predicted to have a low amount of child classes (i.e. 99% of concrete things in the game) would be so much nicer and have very little impact on the base game I think. Making slight tweaks to existing things is a lot of what mods do and probably isn't as much what the base game does. Don't kill me senior engineers :D
Not modding per se, but use and maintaining of mods :
Saveable Modlists
EdB's Modlist Interface -> active and inactive mods in two seperate lists.
Mods Sorted by name given in about.xml, not the name of the modfolder
Make Mode Version a required entry in the about.xml
select and move multiple mods at once.
hotkeys for activation/deactivation and movement of mods in the list.
sorting options for mods ( date, author, name, mod-intent* )
*intent being QoL, Content, Interface ..
TL;DR: ThingWithComps as an interface. I think that would resolve an issue i'm having in creating a class PlantWithComps.
Basically, I want to add Comps to a Plant, for some really fun modding. But the two options I have for inheritance don't work.
* Inherit from Plant: If I create PlantWithComps inheriting from Plant, then when comps are added to PlantWithComps, the ThingComp.parent does not point to a ThingWithComps.
* Inherit from ThingWithComps: If I create a PlantWithComps inheriting from ThingWithComps, then all the classes that expect to operate on a Plant (ex. Designator_Plants*) all have to be rewritten.
As it is, I am recreating Thing-ThingWithComps functionality. If anyone has some syntactic sugar to resolve this, please let me know. I'm not a native c# dev.
Spitballing but could you not have plantsWithComps extend Plant and copy all the thingWithComps into that new class. Therefore smushing everything together....I dont think theres any other way right now.
Tried it. When PlantsWithComps (with copy/paste ThingWithComp code) instantiates its ThingComps (PlantsWithComps.comps), the ThingComp.parent is typed as a ThingWithComp but PlantsWithComp inherits from Thing, so it can't be cast as a ThingWithComp.
Now I guess you could create your own MyThingComp and do `public new PlantWithComp parent`... and that might work for all your own comps, but not any of the existing comps since they would not inherit off MyThingComp.
Good thinking, but bummer.
I wish I could have brought this up earlier as there may have been a possibility to have this incorporated into A17. It probably wouldn't be a hard fix with a code refactoring tool on the RimWorld code. It wouldn't break existing plugins if an interface were used.
I'm creating an example for my own code so I should have a demonstration shortly. I'm using it basically as a complete reimplementation of Components for my own needs. I guess if I need an existing component, I can at least copy/paste that component in pretty easily.
Here is functioning code to extend any "Thing" class in the game with Component-Like functionality (existing components can't be used because of their fixed types). In my case, I am using this code to add functionality to plants (Plant does not extend ThingsWithComps so current Components can't be used). See the Druid plants in my underdevelopment mod Unifica Magica (https://ludeon.com/forums/index.php?topic=31826.msg325689) which can spawn Entangling Vine Plants and Exploding Ferns.
Here's my Tutorial page for ExtendedThing (https://github.com/roxxploxx/RimWorldModGuide/wiki/SHORTTUTORIAL:-ExtendedThings).
Feedback welcome!
Quote from: hemebond on January 09, 2017, 06:38:25 PM
As a newbie Rimworld modder I was surprised that it was impossible/difficult to just override textures and items. I expected mods to "stack", overriding any resources/definitions lower in the mod list. This is how most games I've modded/played seem to behave.
Just changing a texture means having to put the file into the Core mod directory or duplicating the Thing definition in the new mod directory.
100% this. Texture updates should really be a basic image override, and contextual of the mod hierarchy. This should also apply for _all_ textures (rather than needing to define graphics_linked etc).
Totally understand rolling up the sleeves if textures are different dimensions, but the basic updates should be super easy.
Would be awesome to be able to customize the meshSize of an equipable item, mostly with respect to weapons.
If you want a gun to be huge, you pretty much have to make it a square, and that takes away from the creativity of it all.
I know Ohu accomplished this in his faction color mod, but it would be a great feature to have in the base game for some of us xml plebs :P
I'd love to see the tags for PawnCapacityDefs defined in XML, possibly in some form of StatOffset. Currently they're all hardcoded in the various CapacityWorkers, making it impossible to know what body parts affect what stat.
Things that would make modding easier: A built-in system to do xml patches and overrides.
Though, I feel such are more important to ensure better mod compatibility and less headaches for modders, such as making mods easier to maintain. I talked about this in the Proposal: .patch system for better mod compatibility (https://ludeon.com/forums/index.php?topic=28709.0) thread.
Granted, there is notfood's MFO (Mod Friendly Overrides) (https://github.com/notfood/RimWorld-MFO/wiki) and AlcoholV's Ac-Override Injector (http://steamcommunity.com/sharedfiles/filedetails/?id=806500222). I've used both and both have their strengths. But both systems also have their limitations. And these rely on a modder maintaining them for each update. If not, mods that rely on them could be left up a creek without a paddle.
... I was going to also mention the need for a better way to do code injections. But, I just read that HugsLib (https://ludeon.com/forums/index.php?topic=28066.0) now uses Harmony library, which is supposed to be a much better practice. So... never mind.
Edit:
Never mind... I just found out about the new PatchOperation (https://gist.github.com/Zhentar/4a1b71cea45b9337f70b30a21d868782) system. That's pretty much what I was asking for.
With the new patching possibility it could be nice to have way of triggering a patching "when something happen" in game. Like a research or a comp...
Currently, the only error produced if a PatchOperationSequence fails is: "[modName] Patch operation Verse.PatchOperationSequence failed"
This provides no information regarding the filename or structure of the failing sequence, nor which operation failed, which essentially means that the entire mod has to be discarded and then reassembled piecemeal until the failing sequence is located. If the message could reproduce the failing node either in the log or as part of the crash message itself, it would simplify identification of the cause for error.
If nothing else, a subnode <log>My error message here!</log> for the <Operation class="..."> or <Operation class="PatchOperationSequence"><operations><li class="..."> nodes which will print the user-specified log message to the console when the operation fails would be most welcome.
[edit] It appears that root Operations do produce full messages as to what operation has specifically failed -- it's simply PatchOperationSequences that don't.
Quote from: kaptain_kavern on June 16, 2017, 11:47:07 AM
With the new patching possibility it could be nice to have way of triggering a patching "when something happen" in game. Like a research or a comp...
I'm not sure how you think this should work, but trying to patch files during run time would be a lot more complicated than it sounds.
I imagine what you want is the ability to replace a thing with a different thing when a condition is met, which could be useful for a ton of things.
I like how Tynan asked if modders could talk together about the major important things, but then almost a year later we still have newbie modders asking for every single little hardcoded thing to be moved out of the code and into XML...
Guys, just learn C#. Seriously, it's not THAT hard. This is the most modable game without direct programming knowledge I've ever seen (except maybe for Westwood's old C&C games), and so many are STILL unhappy ::)
Quote from: JT on June 26, 2017, 09:04:01 AM
Currently, the only error produced if a PatchOperationSequence fails is: "[modName] Patch operation Verse.PatchOperationSequence failed"
[snip]
It's pretty easy to just diagnose this yourself. Just move each operation outside of the PatchOperationSequence and see which one fails. "(The) entire mod has to be discarded and then reassembled piecemeal" is a massive exaggeration - you dont NEED to have them inside a PatchOperationSequence to work; the whole point of PatchOperationSequence is to do multiple patches based on preconditions. But when you're developing yourself, you're in full control of the preconditions and environment. So just move them outside of the sequence to debug yourself - it's not that complicated.
Quote from: Weyrling on June 27, 2017, 02:42:28 PM
Quote from: kaptain_kavern on June 16, 2017, 11:47:07 AM
With the new patching possibility it could be nice to have way of triggering a patching "when something happen" in game. Like a research or a comp...
I'm not sure how you think this should work, but trying to patch files during run time would be a lot more complicated than it sounds.
I imagine what you want is the ability to replace a thing with a different thing when a condition is met, which could be useful for a ton of things.
This is already possible, it's called "write it in C# and compile an assembly". Patching is for modifying XML definitions, but you're trying to do runtime logic. You can't do runtime logic in definitions - this is the whole point of coding.
And if you think that's too hard, it really isn't. I've modded a lot of games in the past, and the RimWorld wiki with Harmony library and Visual Studio is some of the easiest and most powerful modding I've ever seen. Two days ago I didn't even know C# (albeit I am a Java developer by profession) and today my WIP mod replaces Steel with Iron Ore and makes Iron Ore > Steel production (done only via XML and Patches) and I've also managed to make Charcoal from cuproPanda's Powerless! Mod and Coal from Black Fuel mod act as a fuel that is 3x as potent a fuel source as wood (done via C# and the Harmony library).
Considering how great the Harmony library is, I don't consider *any* of these features as important - they can already be done. What WOULD be nice is a pre-patch system that runs before XML loading, or some kind of automatic *Def Name attribute resolution so we can use ParentDefName="AParentThingDefToInheritFrom" - but the chances of developers ever seeing these serious technical requests are likely slim because everyone spams all these open-ended and vague wishes that are extremely novice things that only lazy or unpracticed people would have trouble with.
No offense, it's just frustrating seeing so few legitimate concerns that are lost in the screams of amateurs.
Quote from: CosmicDan on June 28, 2017, 12:22:36 AM
I like how Tynan asked if modders could talk together about the major important things, but then almost a year later we still have newbie modders asking for every single little hardcoded thing to be moved out of the code and into XML...
Guys, just learn C#. Seriously, it's not THAT hard. This is the most modable game without direct programming knowledge I've ever seen (except maybe for Westwood's old C&C games), and so many are STILL unhappy ::)
Quote from: JT on June 26, 2017, 09:04:01 AM
Currently, the only error produced if a PatchOperationSequence fails is: "[modName] Patch operation Verse.PatchOperationSequence failed"
[snip]
It's pretty easy to just diagnose this yourself. Just move each operation outside of the PatchOperationSequence and see which one fails. "(The) entire mod has to be discarded and then reassembled piecemeal" is a massive exaggeration - you dont NEED to have them inside a PatchOperationSequence to work; the whole point of PatchOperationSequence is to do multiple patches based on preconditions. But when you're developing yourself, you're in full control of the preconditions and environment. So just move them outside of the sequence to debug yourself - it's not that complicated.
Quote from: Weyrling on June 27, 2017, 02:42:28 PM
Quote from: kaptain_kavern on June 16, 2017, 11:47:07 AM
With the new patching possibility it could be nice to have way of triggering a patching "when something happen" in game. Like a research or a comp...
I'm not sure how you think this should work, but trying to patch files during run time would be a lot more complicated than it sounds.
I imagine what you want is the ability to replace a thing with a different thing when a condition is met, which could be useful for a ton of things.
This is already possible, it's called "write it in C# and compile an assembly". Patching is for modifying XML definitions, but you're trying to do runtime logic. You can't do runtime logic in definitions - this is the whole point of coding.
And if you think that's too hard, it really isn't. I've modded a lot of games in the past, and the RimWorld wiki with Harmony library and Visual Studio is some of the easiest and most powerful modding I've ever seen. Two days ago I didn't even know C# (albeit I am a Java developer by profession) and today my WIP mod replaces Steel with Iron Ore and makes Iron Ore > Steel production (done only via XML and Patches) and I've also managed to make Charcoal from cuproPanda's Powerless! Mod and Coal from Black Fuel mod act as a fuel that is 3x as potent a fuel source as wood (done via C# and the Harmony library).
Considering how great the Harmony library is, there are so many requests here that I really don't think are important at all - they can all already be done, even if it's in some slightly roundabout or awkward way. What WOULD be nice is a pre-patch system that runs before XML loading, or some kind of automatic *Def Name attribute resolution so we can use ParentDefName="AParentThingDefToInheritFrom" for def inheritance - but the chances of developers ever seeing these serious technical requests are likely slim because everyone spams all these open-ended and vague wishes that are extremely novice things that only lazy or unpracticed people would have trouble with.
No offense, it's just frustrating seeing so few legitimate concerns that are lost in the screams of amateurs.
Over the past couple weeks I've seen several modders attempt to resolve communications issues by establishing new timers to check for status changes. That method is likely to generate lag.
Some sort of .OnChange() method hook, so that mods interested receive notification when there is a change, instead of consuming CPU time checking every few time intervals.
could you please consider in future alphas to add mod version tag as a requirement in the mod about xml file?
i recently needed the ModConfig, being able to see active mods is really nice, but its a shame you can't get the mod version there.
in general, its a good practice to have a unified way to mod versions, even for mods with no assemblies.
Quote from: Tynan on June 10, 2016, 04:01:27 PM
Edit: The difficulty here seems to be that there are a ton of requests - everyone has their own little thing they want changed. Unfortunately we can't cover all these; I really want to make the changes that will have a big impact on a lot of modders. Bang for your buck, so to speak.
So it would be really great if modders could discuss and come up with a top-3 list of things that would help a lot of people at once. Consider this an invitation to discuss with each other what would help you all together.
Since so many ideas would run over each other, do a poll with the most popular ones that would be compatible with each other
Sorry if this has already been mentioned, but now that we can inherit core defs in A17 (instead of having to recreate all the abstracts ourselves), it would be nice if every core def was named for inheritance. For example:
<ThingDef ParentName="ApparelMakeableBase">
<defName>Apparel_TribalA</defName>
<label>tribalwear</label>
<description>A garment crafted without machines using neolithic tools.</description>
...
</ThingDef>
becomes
<ThingDef Name="ApparelTribalA" ParentName="ApparelMakeableBase">
<defName>Apparel_TribalA</defName>
<label>tribalwear</label>
<description>A garment crafted without machines using neolithic tools.</description>
...
</ThingDef>
Ive already suggested that to zorba as it also speeds up xpath for modders considerably as attribute lookup is near instantaneous.
Would they be still near instantaneous if we start to spread them all over the code?
Food Dispensers to not be hardcoded. Use buildings with the flag "isFoodDispenser" to check which buildings to attempt to pull from, not just the Food Dispenser Class.
Right now I think the Mod Backup List Mod at steam should be integrated into Rimworld. The features that mod offers for game development and mod list management are professional, and simply better than anything vanilla rimworld ever hoped to deliver, I suggest full integration with the game, Mod Author willing, of course.
Make the portable Version of Rimworld reliable.
A common resource pack.
In Kerbal Space Program modding community, there is a mod called Community Resource Pack, basically every mod talks the same. Say Mod A produces hydrogen, and Mod B can use that hydrogen created by mod A.
Most mod in KSP play nice to each other.
In rimworld, there is a mod that uses aluminium and another mod that uses aluminum, and it's not interchangeable. Same mods also use copper and copper, different graphic, and also not interchangeable.
I think it would be slightly harder to implement in rimworld, but it should doable. Note: I'm not a coder.
Genetic Rim can use Vegetable Garden's plasteel thread, and not just vanilla plasteel. Since it's graphically (and logically) more accurate.
OHU dropship can use Rimatomics' nuclear to power the ships.
Combat extended can use Rimatomics for uranium rounds.
How about two really basic things.
1. The Rimworld core code uses too many const values. These cannot be modded, because they compiler replaces their value at the call point.
2. Too many items in the Rimworld core are unnecessarily declared private. These last can be worked around due to reflection, but still. Consider:
private static bool IsDefeated(Map map, Faction faction)
{
List<Pawn> list = map.mapPawns.SpawnedPawnsInFaction(faction);
for (int i = 0; i < list.Count; i++)
{
Pawn pawn = list[i];
if (pawn.RaceProps.Humanlike && GenHostility.IsActiveThreat(pawn))
{
return false;
}
}
return true;
}
This code is from the FactionBaseDefeatUtility.cs file. There is no reason for it to be private. Some of the drawing routines, which will crash the game if not called in the main thread--these are understandably private, it worth it just to make the modder have to use ninja techniques to get to them--but cases like the above? No.
I'm not a coder and I don't really know how modding in Rimworld works, but I know how the simple mods (I guess in Rimworld its xml-patches) work in Kerbal Spaceprogram and Module Manager makes patching the base game as easy as it gets.
https://github.com/sarbian/ModuleManager/wiki/Module-Manager-Handbook
For ingestible ThingDefs, change <tasteThought> to a list.
This will allow easier editing of traits and associated ThoughtDefs, as each would be checked at a time of eating. For performance, I would suggest breaking from the list at the first tasteThought that was valid.
= = =
Expose the auto generated ThingDefs (for example, leather and meat) to .xml as an abstract that all leathers or meats inherited. This would allow for simper editing of graphics, thing category, statBases, etc.
An easier way for mods to check if there are other specific mods already installed.
Basically, make xpath work for mods without additional coding.
Quote from: faltonico on October 17, 2017, 12:46:15 PM
An easier way for mods to check if there are other specific mods already installed.
Basically, make xpath work for mods without additional coding.
I think that this requested should be satisfied by allowing an xpath query to do this:
<Operation Class="PatchOperationSequence">
<success>Always</success>
<operations>
<li Class="PatchOperationTest">
<xpath>*/ModMetaData[name = "Misc. Robots"]</xpath>
</li>
...
</operations>
</Operation>
The above would let you query the ModMetaData that is mandatory in the About file of every mod.
Of course, they also need to fix the Sequence system, which is somewhat broken in A17.
Up until B18, I was able to make custom melee weapon sounds with a super simple .dll mod. It's not that big of a deal, but I think it'd be cool to still have that capacity. Obviously having the setting in an XML is ideal, but not everything has to be possible through XML.
Anyways, simply put, an intuitive way to implement custom melee sounds would be greatly appreciated :)
Potential applications:
- Energy Weapons (Lightsabers, Energy Swords, etc.)
- Non lethals (Electric prods, tasers, etc.)
UPDATE: After some further searching through the XMLs of B18, I've found that you can accomplish what I'm talking about through the stuff system.
For the cost list in ThingDefs allow thing defines with multiple variations to be seen as valid materials. A bed is an XML define but the game would not see any beds in game as a valid material because every bed is a variation of stuff. Stone bed, metal bed, etc. This would make it easier to mod more complex variations without changing the game at its core too much. IE it would allow construction of a stone (cloth mattress bed) or a stone (leather mattress bed).
Only because having multiple stuff category lists is not doable currently.
Edit Update: I misunderstood how recipes could work and this is doable using recipeDefs, but it would make it easier if ingredient categories could be added directly to thing defines.
For example right now it has
CostList
StuffCategories
...RecipeMaker...
That way you can edit complex recipes directly inside the thingDef instead of having to make a recipe def. RecipeDefs also don't support direct construction of buildings AFAIK so there's that.
I kind of agree that everything should be under one roof for the sake of sanity when it comes to RecipeDef and ThingDef. Just put it all in ThingDef, since recipes are currently only ever used to make things and they always reference only one specific thing as a product. The only reason you'd want the two separated is if you need some order independence (which doesn't seem to be the case for anything currently in the game...?)
I mean, unless you want to separate concerns into ThingDef and CreateDef, where you'd unify Items and Buildings as just generic Things using only their ThingDef tags to differentiate them while the CreateDef would describe how you create, trade, and remove the thing during play. That makes the most sense to me.
Imagine a mod that enables a colonist to build some tribalwear on the ground with a welding torch and have another colonist swoop by to dance on it for a little joy, who can then pick up and wear it. Optionally, at a workbench a colonist can create a solar panel and wear it as a hat until you give them somewhere to place it down to actually function as a power plant. All with just xml! Pointless, but flexible!
NOPE, I forgot that deconstruction recipes exist and that's a very valid reason to keep them separated. Nevermind!
A wiki that details an API for dll modding, Maybe show what the mod edits like how android shows you what the app accesses before you download it, more detailed debug log (though I might just not know how to use it properly)
EDIT: C# has some limitations on what works here, it's more complicated than first glance.
I am coming very late to the thread here, but if the question is still open:
ThingDef.cs, the HasComp(Type compType) function. It would be nice if instead of == it used "is". As it is written now, a compClass derived from another compClass will not pass that test.
EDIT: This would require if ...==compType || ...compClass.isSubclassOf(compType)...
I do prefer to use derived functions over Harmony patches. ...I'll go write that Harmony patch now ;)
Still enjoying the game and enjoying modding as well,
--LWM
In the general theme of derived classes, however, it would be much easier if every public interface and, for that matter, every field, were virtual or protected. Given Harmony and Reflection, we can already break anything we want to break, but having the option to use derived classes would make some mods much easier to do!
I understand the more private options for the fields are useful from a programming point of view...but maybe when you release a new version, and everything is ready to go, change everything to virtual/protected as a final build, so modders can work with it more easily?
--LWM