Requests from modders to devs for 1.0 and 1.1

Edit: this got implemented

This one is really small:

Add “model_variant”: “female” to female skeletons, and zombies.

This way they can use female clothes. For most mobs this does not matter, but skeletons have different proportions when female.

screenshot%202018_07_14__10_56_47
^ Both using male clothes

I’m trying to remember… Is there a way for modders to specify one or more hearthlings as a class other than a worker on embarkment screen?

For example: Making a kingdom embark with 4 Workers and 1 Footman instead of 5 Workers?

If not I think this would be very beneficial to modders.

1 Like

For edge cases where the talisman isn’t enough and they need a level in say, blacksmith first?

For the edge case that you want to embark with a special class that isn’t available through obtainable job talismans

1 Like

Good idea, would make embarking with a max of one class easier.

Edit: this got implemented

Considering that I already mistakenly bumped the post, let me just move this suggestion to here too:

Just took a look at the Clan Amberstone as kingdom mod and I think we need a way to specify kingdom’s diet so they don’t get their stomachs filled with roasted rabbit jerky…

3 Likes

Could in addition to other traits give them vegetarian.

3 Likes

Edit: this got implemented

Another extremely small change that can make a huge impact, in the HabitatManager add water to this table:

local habitat_types = {
   none      = true,
   occupied  = true,
   plains    = true,
   foothills = true,
   mountains = true,
   water = true,
   forest    = true
}

And a new return ‘water’ for this method:

function HabitatManager:_get_habitat_type(terrain_type, feature_name)
   if terrain_type == 'mountains' then
      return 'mountains'
   end
   if self._landscaper:is_water_feature(feature_name) then
      return 'water'
   end
   if self._landscaper:is_forest_feature(feature_name) then
      return 'forest'
   end
   if feature_name ~= nil then
      return 'occupied'
   end
   if terrain_type == 'plains' then
      return 'plains'
   end
   if terrain_type == 'foothills' then
      return 'foothills'
   end
   log:error('Unable to derive habitat_type')
   return 'none'
end

So we can add landmarks to the water, like this:

screenshot%202018_07_15__16_35_51

13 Likes

Any chance of multiple region collision types within a single entity? Or a way to “group” entities to approximate that behavior?

And please include in the documentation how terrain and other C++ systems work, with explanations of enums like region collision type (as far as I can tell, there are just NONE, SOLID, and PLATFORM, and I’m not entirely sure of the specifics of PLATFORM behavior).

How hard would it be to have crafting recipes accept more then one kind of crafting station? (or is that allowed even now? With some trickery? )
Use: currently cooks always start with a stone cauldron but classically metal cauldrons have been used throughout the ages aswell. Could lead to crafting station upgrades with backwards compatible recipes.
(so the new stations could still do the old recipes)

You can mixinto workshops to specify equivalents. See the upgraded potter’s kiln as an example.

4 Likes

I have a couple requests related to workshop displays:

  • add an ‘ordinal’ attribute to recipes so that their sort order can be fine tuned differently than just by crafter level, then alphabetical
  • add an optional ‘detail’ image for a recipe that replaces ‘portrait’ only in the larger picture on the right of the workshop panel when the recipe is selected

I have managed to get both of these into my mod, but it requires overriding two large js & html files, and I’d rather not have my mod conflicting with someone else’s that has extensive UI tweaking.

For the former, I just added an ‘ordinal’ to each of my recipes in a given category, then added a test in _compareByLevelAndAlphabetical within the show_team_workshop.js file (if both items being compared have an ‘ordinal’ attribute, it checks those before level and name).

For the latter, in show_team_workshop.html, I edited the ‘portraitContainer’ div to check if the current recipe has a ‘detail’ view. If so, display that, otherwise show ‘portrait’ as normal.

Seems like both of these are fairly generic tweaks that other modders might find useful.

Please remove (or sequester) files that are not being used. The entire building system (as an example) is spread out across many directories, and it’s hard to tell what’s actually part of the current version of it and what’s part of old versions.

1 Like

Also, less reliance on unmodifiable locals (e.g., in lib.building.fixture_utils), requiring a complete override of a file instead of allowing monkey patching when you only want to change one or two functions.

simple request: add the word “shield” to shields. (currently they are just armour. but armour AND shields would be good)

preferably the whole key words part it items would be an array, not a string but that would be a lot more time consuming to fix.

1 Like

Edit: this got implemented

Really simple and still backward compatible change. Change the

"roles":"role1 role2 role3"

in the job_description to an array as

"roles":[
    "role1",
    "role2",
    "role3"
]

This way we can easily add more roles as we want without mod conflicts.

To make it work you would need to also change job_component.lua, this:

   if self._job_json.roles then
      local split_roles = radiant.util.split_string(self._job_json.roles)
      for _, job_role in ipairs(split_roles) do

into this:

   if self._job_json.roles then
      local split_roles = self._job_json.roles
      if radiant.util.is_string(split_roles) then
         split_roles = radiant.util.split_string(split_roles)
      end
      for _, job_role in ipairs(split_roles) do

Then in the job_info_controller.lua, change this:

            self._sv.roles = {}
            local split_roles = radiant.util.split_string(self._description_json.roles)
            for _, job_role in ipairs(split_roles) do

to this:

            self._sv.roles = {}
            local split_roles = self._description_json.roles
            if radiant.util.is_string(split_roles) then
               split_roles = radiant.util.split_string(split_roles)
            end
            for _, job_role in ipairs(split_roles) do

And last, the app.js:

                        if (job.description.roles && !job.description.is_npc_job) {
                           var rolesString = job.description.roles;
                           var rolesArray = rolesString.split(" ");
                           for (var i=0; i < rolesArray.length; ++i) {

to this:

                        if (job.description.roles && !job.description.is_npc_job) {
                           var rolesArray = job.description.roles;
                           if ((typeof rolesArray) === 'string') {
                              rolesArray = rolesArray.split(" ");
                           }
                           for (var i=0; i < rolesArray.length; ++i) {

Edit:
Oh, and also the roles in equipment, change this in equipment_piece_component.lua:

      if self._json and self._json.roles then
         local split_roles = radiant.util.split_string(self._json.roles)
         for _, job_role in ipairs(split_roles) do

to this:

      if self._json and self._json.roles then
         local split_roles = self._json.roles
         if radiant.util.is_string(split_roles) then
            split_roles = radiant.util.split_string(split_roles)
         end
         for _, job_role in ipairs(split_roles) do

Edit2:
You also need to change this in two functions (findRelevantClassesArray and getJobsForRole) in object.js (in radiant mod):

      var classArray = [];
      var roles = roleString.split(" ");
      var jobData = App.jobConstants;

to this:

      var classArray = [];
      var roles = roleString;
      if ((typeof roles) === 'string') {
         roles = roles.split(" ");
      }
      var jobData = App.jobConstants;
10 Likes

Edit: this got implemented

Following the above suggestion, there is also this old request: Technical suggestion about entity tags (material_tags)

Which can be done very similar. It is also backward compatible.

All you need is change this code of material.lua:

   local mat_parts = {}
   for _, tag in ipairs(radiant.util.split_string(material_string)) do
      table.insert(mat_parts, tag)

into this:

   local mat_parts = {}
   if radiant.util.is_string(material_string) then
      material_string = radiant.util.split_string(material_string)
   end
   for _, tag in ipairs(material_string) do
      table.insert(mat_parts, tag)

And also this in the unit_frame.js:

         if (catalogData) {
            var materials = catalogData.materials ? catalogData.materials.split(' ') : [];
            if (materials.indexOf('human') >= 0) {

to this:

         if (catalogData) {
            var materials = null;
            if (catalogData.materials){
               if ((typeof catalogData.materials) === 'string') {
                  materials = catalogData.materials.split(' ');
               }else{
                  materials = catalogData.materials;
               }
            }else{
               materials = []
            }
            if (materials.indexOf('human') >= 0) {

Edit:
We also need to change the shop.lua, same drill:

   local materials = {}
   local tags = entity_description.materials or ''
   for _, tag in ipairs(radiant.util.split_string(tags)) do
      materials[tag] = true

to:

   local materials = {}
   local tags = entity_description.materials or {}
   if radiant.util.is_string(tags) then
      tags = radiant.util.split_string(tags)
   end
   for _, tag in ipairs(tags) do
      materials[tag] = true
6 Likes

Just dropping by to completely support both suggestions (job roles and material tags into arrays) above :smiley:

1 Like

Seconding both, could especially use the tags tbh…