1. For Hand Armors, there should be a "no_slim" XML tag that can be combined with "hides_hands" or not. This tag should prevent _slim variations of meshes from being used while gloves are being worn. This would allow gloves that aren't giant forearm-covering objects while not breaking the current behavior of the engine, and it could be a one-time check when loading up an Agent's clothing.
2. Vertex colors for meshes using the various core human body Materials aren't being utilized when said Material is used by anything but the core body meshes. It looks like the current logic is something like:
if(is_human && mesh.isBaseMeshNoClothing) --> set the vertex color value from the character generator / facegen code in the shader.
What it should be doing instead is checking a (new) Material Shader Flag "use Character Skin Color" (a boolean). If boolean == TRUE, then pass the color value into the shader and apply it.
This would be, by far, the best solution. It's one binary check per submesh per frame, and it's consistent. If, say, a modder creates brand-new Materials for the skins of their characters and wants them to have color variations that players can pick out, that's supported, without any complex changes on the engine side.
Here's why it's a problem already. Let's say we try and make an armor that uses a submesh with one of the human body Materials. It looks like this in-game:
Add in problems with various Races not having correct colors supported unless they're naked, etc.
3. There aren't good measurement tools in the Meta Mesh Editor for measuring commonly-needed things, such as weapon lengths. Suggestions:
A. There is already a bounding box being built automatically. By simply subtracting the Y-distance from the floor to the bottom of the mesh, you'd have the weapon's length value (in this case, 96 cm).
B. Ideally, the end-user would get that value, the total length, width and depth.
C. Even more ideally, you'd replicate OpenBRF's point-to-point measuring tool, for times when modders need to measure something odd in a mesh, like the height of a doorway in a building mesh that they're not sure they exported at quite the right scale.
4. The Meta Mesh Editor could use a few basic features it currently lacks:
A. Scaling, Translation, Rotation and Mirroring of a mesh.
B. A standard human hand mesh, positioned at the grip point (i.e., the center in this case) that can be turned on / off in the display. Or just a nice colored line that shows the user really clearly where the handle of a given weapon is going to be.
5. There needs to be a simpler path to start building code for mods. Now that I've seen it, the C# route could use a major improvement. The example projects here on this Forum come with instructions that are either vague, missing important relevant information that newbie coders might not figure out, or are otherwise feeling incomplete. Current mods are highly dependent on reflection libraries, mainly Harmony, which probably doesn't help much with stability and definitely makes debugging mods harder.
Suggestions:
A. Consider strongly building in a C# runtime compiler, that will take loose code in a mod's folders and compile it, reporting errors usefully along the way. This means a new modder's first project could be as simple as a text file in an appropriate folder with some very simple code to show "hello world" in the game, rather than a lengthy process of setting up an IDE, setting up dependencies, etc. etc., which must be costing you hundreds if not thousands of potential modders over time.
Moreover, by encouraging runtime code as the standard, you'll be encouraging coders to stay safe. Code shouldn't be allowed to access IO willy-nilly; there should be clearly-defined methods to access files within the application's directories (reading an XML or JSON file, for example) but things like write access could be largely curtailed, making things safer. Right now you're at the legal mercy of whoever's maintaining the Harmony libraries being used, which may do any number of things, and the modders using them are totally free to write dangerous code using your engine's popularity as a good way to introduce trojans, etc.
This isn't merely scaremongering. A recent attack was made using Java in Minecraft mods, for example. Your company's reputation, if not strict liability, is at risk.
B. Bug reporting from the engine needs to be a lot more robust. I've noticed that the engine crashes silently and without useful feedback for simple mistakes in XML files, for example; at the very least, it should be outputting "Engine Crashed! Reading XML file <filename> at line <line>". This alone would save modders a ton of time.
C. Bug reporting from code, should proposal A be built into the engine, should become much easier. Instead of running a complex debugger, the engine can now report, "Engine Crash! Running Mod Code From <mod name>, Function <function name>, Line <line number>"
D. Instead of modders building code an using reflection to override the engine's code (with some danger involved- code run by reflection can do, well, anything it wants to) code could be running from internal callbacks. For example, your typical Mission code's game tick could have a callback method called Update() and modders could be writing their methods to hook into that, to do whatever they want to do during a Mission's game tick. Same with the Strategic Overworld, etc.
This largely depends on the existing code being able to be read, however! It's all well and good to want to, say, write new code to change the economy, but one needs to know where the relevant Objects are, the getters and setters, etc. That leads into the next point...
E. To better-support modders, strongly consider releasing the code of all gamecode DLLs in a ZIP file for every build, just as in the old days, when you distributed a new, uncompiled Module System with each new engine build. Right now, experienced coders using Visual Studio can look at gamecode classes and methods, to a certain extent, but are often in the dark about the inner functions or expected parameters of inputs and outputs.
6. Somebody should write a short, simple, "my first sword" document for how to build, texture and import a piece of modded content, and there needs to be a place here (not on Discord, where it's impermanent) to ask questions. I feel like the current engine kind of presumes that the only people building stuff for it will largely be 3D modeling whizzes.
Warband should have taught you better than that.
Back then, and still today, the vast majority of people wanting to try their hand at building 3D content will be relative newbies, and they need their hands held the entire way.
They don't know what Blender is. They don't know how to use it. They certainly don't know about making multiple meshes with fancy names like "my_cool_sword.1.lod2" and what all that means. Half the stuff I built was 3D meshes people built, but didn't understand enough about uvmapping and painting a skin to get done, or which needed extensive remastering. I loved helping people out with that and I made a couple of friends I know even today... but bear in mind that this is your real audience. Not just the whiz-kids. The 13-year-old kid who's seen this game, thinks it's neato, and wants to put in a sword. Support that level of simplicity and think about those people's experience.
I did something like that back then, IIRC. I'm probably not going to do it for you again. Find somebody who wants to stay and has the skills, both technical and as a writer.
7. I know it's too late to do anything at all about it, but XML sucks. It's hard to read and it's unpleasantly easy to break. JSON with a modern JSON interpreter that allows in-line comments, etc. would've been a much better choice. <shrugs> maybe back then, JSON was still too crude-looking to use. But now it's a slam dunk for a text format for data that's clear, readable and flexible.
8. There are dozens of questions about how art workflow works that nobody appears to know. You might want to fix that.
Stuff like (for example):
"Can we still use vertex animations for bow / crossbow animations" (I wanted to know, because I made a Chu-No-Ku crossbow for Warband, with animation, but it cannot work correctly by merely pulling some vertexes backwards in a shader.
"How many FBX files, including all the LODs, are really required for a complete 2-sex suit of armor" (the answer, unfortunately, is "four", and I think that's sad, when we just needed one, with one vertex-animation morph, in Warband).
"Some meshes have closed fists while others have open hands, are there shape keys for hand armours? And if so, does Taleworlds have a way to automate this?" Nobody knows, but one presumes you have a hand rig somewhere that you use to do this relatively easily. Export the FBX and put it in the next release in the modder's resource folder, along with all of the human / horse / camel bodies, please. Having to use TPACTool to break into your content, merely to get a working body mesh, is ridiculous.
"What are the art-asset rules for Hairs and Beards, and what is a workflow for putting a new one into the game?"
There are dozens more questions like this here. Most of them are unanswered.
...whew
Anyhow, that's it. I've had a pretty frustrating experience with this engine overall. The main problem, from a newcomer's perspective, is the confusing / misleading documentation, lack of a "jump right in" that's actually easy, and if you want to mess with content, the frustrations of things like, "you can look at our content, but you cannot override, change or export any of it", which is kind of the antithesis of modding, really, lol. Oh well. I'm glad that the game's sold well enough that maybe all this will get fixed up and I'll come back to a Skyrim total-conversion mod at some point, lol.
2. Vertex colors for meshes using the various core human body Materials aren't being utilized when said Material is used by anything but the core body meshes. It looks like the current logic is something like:
if(is_human && mesh.isBaseMeshNoClothing) --> set the vertex color value from the character generator / facegen code in the shader.
What it should be doing instead is checking a (new) Material Shader Flag "use Character Skin Color" (a boolean). If boolean == TRUE, then pass the color value into the shader and apply it.
This would be, by far, the best solution. It's one binary check per submesh per frame, and it's consistent. If, say, a modder creates brand-new Materials for the skins of their characters and wants them to have color variations that players can pick out, that's supported, without any complex changes on the engine side.
Here's why it's a problem already. Let's say we try and make an armor that uses a submesh with one of the human body Materials. It looks like this in-game:
Add in problems with various Races not having correct colors supported unless they're naked, etc.
3. There aren't good measurement tools in the Meta Mesh Editor for measuring commonly-needed things, such as weapon lengths. Suggestions:
A. There is already a bounding box being built automatically. By simply subtracting the Y-distance from the floor to the bottom of the mesh, you'd have the weapon's length value (in this case, 96 cm).
B. Ideally, the end-user would get that value, the total length, width and depth.
C. Even more ideally, you'd replicate OpenBRF's point-to-point measuring tool, for times when modders need to measure something odd in a mesh, like the height of a doorway in a building mesh that they're not sure they exported at quite the right scale.
4. The Meta Mesh Editor could use a few basic features it currently lacks:
A. Scaling, Translation, Rotation and Mirroring of a mesh.
B. A standard human hand mesh, positioned at the grip point (i.e., the center in this case) that can be turned on / off in the display. Or just a nice colored line that shows the user really clearly where the handle of a given weapon is going to be.
5. There needs to be a simpler path to start building code for mods. Now that I've seen it, the C# route could use a major improvement. The example projects here on this Forum come with instructions that are either vague, missing important relevant information that newbie coders might not figure out, or are otherwise feeling incomplete. Current mods are highly dependent on reflection libraries, mainly Harmony, which probably doesn't help much with stability and definitely makes debugging mods harder.
Suggestions:
A. Consider strongly building in a C# runtime compiler, that will take loose code in a mod's folders and compile it, reporting errors usefully along the way. This means a new modder's first project could be as simple as a text file in an appropriate folder with some very simple code to show "hello world" in the game, rather than a lengthy process of setting up an IDE, setting up dependencies, etc. etc., which must be costing you hundreds if not thousands of potential modders over time.
Moreover, by encouraging runtime code as the standard, you'll be encouraging coders to stay safe. Code shouldn't be allowed to access IO willy-nilly; there should be clearly-defined methods to access files within the application's directories (reading an XML or JSON file, for example) but things like write access could be largely curtailed, making things safer. Right now you're at the legal mercy of whoever's maintaining the Harmony libraries being used, which may do any number of things, and the modders using them are totally free to write dangerous code using your engine's popularity as a good way to introduce trojans, etc.
This isn't merely scaremongering. A recent attack was made using Java in Minecraft mods, for example. Your company's reputation, if not strict liability, is at risk.
B. Bug reporting from the engine needs to be a lot more robust. I've noticed that the engine crashes silently and without useful feedback for simple mistakes in XML files, for example; at the very least, it should be outputting "Engine Crashed! Reading XML file <filename> at line <line>". This alone would save modders a ton of time.
C. Bug reporting from code, should proposal A be built into the engine, should become much easier. Instead of running a complex debugger, the engine can now report, "Engine Crash! Running Mod Code From <mod name>, Function <function name>, Line <line number>"
D. Instead of modders building code an using reflection to override the engine's code (with some danger involved- code run by reflection can do, well, anything it wants to) code could be running from internal callbacks. For example, your typical Mission code's game tick could have a callback method called Update() and modders could be writing their methods to hook into that, to do whatever they want to do during a Mission's game tick. Same with the Strategic Overworld, etc.
This largely depends on the existing code being able to be read, however! It's all well and good to want to, say, write new code to change the economy, but one needs to know where the relevant Objects are, the getters and setters, etc. That leads into the next point...
E. To better-support modders, strongly consider releasing the code of all gamecode DLLs in a ZIP file for every build, just as in the old days, when you distributed a new, uncompiled Module System with each new engine build. Right now, experienced coders using Visual Studio can look at gamecode classes and methods, to a certain extent, but are often in the dark about the inner functions or expected parameters of inputs and outputs.
6. Somebody should write a short, simple, "my first sword" document for how to build, texture and import a piece of modded content, and there needs to be a place here (not on Discord, where it's impermanent) to ask questions. I feel like the current engine kind of presumes that the only people building stuff for it will largely be 3D modeling whizzes.
Warband should have taught you better than that.
Back then, and still today, the vast majority of people wanting to try their hand at building 3D content will be relative newbies, and they need their hands held the entire way.
They don't know what Blender is. They don't know how to use it. They certainly don't know about making multiple meshes with fancy names like "my_cool_sword.1.lod2" and what all that means. Half the stuff I built was 3D meshes people built, but didn't understand enough about uvmapping and painting a skin to get done, or which needed extensive remastering. I loved helping people out with that and I made a couple of friends I know even today... but bear in mind that this is your real audience. Not just the whiz-kids. The 13-year-old kid who's seen this game, thinks it's neato, and wants to put in a sword. Support that level of simplicity and think about those people's experience.
I did something like that back then, IIRC. I'm probably not going to do it for you again. Find somebody who wants to stay and has the skills, both technical and as a writer.
7. I know it's too late to do anything at all about it, but XML sucks. It's hard to read and it's unpleasantly easy to break. JSON with a modern JSON interpreter that allows in-line comments, etc. would've been a much better choice. <shrugs> maybe back then, JSON was still too crude-looking to use. But now it's a slam dunk for a text format for data that's clear, readable and flexible.
8. There are dozens of questions about how art workflow works that nobody appears to know. You might want to fix that.
Stuff like (for example):
"Can we still use vertex animations for bow / crossbow animations" (I wanted to know, because I made a Chu-No-Ku crossbow for Warband, with animation, but it cannot work correctly by merely pulling some vertexes backwards in a shader.
"How many FBX files, including all the LODs, are really required for a complete 2-sex suit of armor" (the answer, unfortunately, is "four", and I think that's sad, when we just needed one, with one vertex-animation morph, in Warband).
"Some meshes have closed fists while others have open hands, are there shape keys for hand armours? And if so, does Taleworlds have a way to automate this?" Nobody knows, but one presumes you have a hand rig somewhere that you use to do this relatively easily. Export the FBX and put it in the next release in the modder's resource folder, along with all of the human / horse / camel bodies, please. Having to use TPACTool to break into your content, merely to get a working body mesh, is ridiculous.
"What are the art-asset rules for Hairs and Beards, and what is a workflow for putting a new one into the game?"
There are dozens more questions like this here. Most of them are unanswered.
...whew
Anyhow, that's it. I've had a pretty frustrating experience with this engine overall. The main problem, from a newcomer's perspective, is the confusing / misleading documentation, lack of a "jump right in" that's actually easy, and if you want to mess with content, the frustrations of things like, "you can look at our content, but you cannot override, change or export any of it", which is kind of the antithesis of modding, really, lol. Oh well. I'm glad that the game's sold well enough that maybe all this will get fixed up and I'll come back to a Skyrim total-conversion mod at some point, lol.
