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.
I have a couple requests related to workshop displays:
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.
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.
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;
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
Just dropping by to completely support both suggestions (job roles and material tags into arrays) above 
Seconding both, could especially use the tags tbh…
Would that be backward compatible with JSONs checking for multiple material tags next to each other, e.g. "stone stockpile_decoration"?
Edit: this got implemented
string_to_array.zip (59.6 KB)
Yes, this is a mod I made with both suggestions above implemented. I could rework job roles, equip roles, and resource tags like the oak log “wood resource”, and it all worked fine.
Jobs were working, equips were being stocked, hauled and equipped by the correct jobs. Items were being stocked, hauled, crafted, sold and even used in construction.
What black magic is this!? 
“Bruno”
Postmustbeatleasteightletters
A bit of a dream, but: would it be possible for fixture cutter to cut fractions of a voxel? I need a way to make entities which blend seamlessly into walls (entities use different shading than wall voxels so simply making them imitate part of a wall with same colour does not work, besides it would require separate variant for each voxel colour).
pawel, i think there should be a way to give them general-issue “wall collor” and that shader too, i think @Kittyodoom probably knows? or possibly @BrunoSupremo since i think he worked with the collors for world generation too. please correct me if im wrong guys 
though i am curious how you planned to use a partial cut to work around this 
?
The thing is I’d like them have both wall colour and non-wall colour voxels. That’s what I wanted to solve with multiple fraction cutters (you can have more than one cutter per fixture).
I still don’t know what you actually - mean- by this pawel 
Thanks for the suggestion! Unfortunately this would be a pretty large change, as we have a lot of assumptions in the code that assume a voxel is the smallest unit.
Also thanks to everyone for their suggestions and requests 
! Just wanted to let you all know we are looking at these and seeing which ones we can do for 1.1.