After result of my previous Mod Idea (now known as Alternate Naming mod by @RepeatPan), Iāve got another idea for our villagers, to improve their āindividualityā. As I said earlier, at the moment I may only give ideas, which could be useable
Mod may be at the moment impossible/very difficult to create. So, letās start explaining
Start the game. Place your banner. Youāve got some villagers - in example: Arasm, Harper, Zetoph, Ardi, Ostia and Reika. Three males, three females. Nice start. Butā¦ why all three girls look absolutely the same? I know, there is a voxel game, but they have even the same hairstyle. Coincidence? I donāt think so.
How we may āsolveā this? There is already a method, which involves *.qb editing. Copy, Edit in Qubicle, Save, Add into smodā¦ Simple, but if you want to add all variations of colors, you may end overexpanding the file size.
Now itās coming my idea to improve the variety without expanding the file:
What if not only hair style, but also hair color will be selected during villager spawning?
Letās create/edit the file with possible hair/accessories colors. One value for hair color and one value for accesories color. When the new worker is spawned, his/her model has changed hair and/or accesories colors.
Problems:
Hairstyles have lighter/darker parts sometimes. But I think this problem may be overtaken by using 105/95 percent of the colour values ;p
More values for our villagers
All hairstyles should be recreated in the same color scheme in game files.
Dunno if editing models in-game is impossible.
*) all of those names are available by Alternate Naming mod
It might already be possible using rig data - the stuff the outfits do. A first step would be to split the settler model up into further regions (hair, decorations such as ear/nose rings) and then randomly rig them. A second, but much more annoying part that would go way beyond qbās file specification, would be to have components that can be randomly colored too. For this, it would be necessary to edit matrices during runtime (or at least, load them, edit them, and compile/bake them into an usable model of some sorts) - so thatās not possible now (I believe) and wonāt come for some time.
Ideally you could assign a qubicle block some meta information, such as āThis is texture1ā. You could then simply model the accessoire/hair without any color (i.e. grey scales) and the game would ācolorā it in the fitting saturation. However, this would likely need a 3rd party modelling tool and engine support.
If I am not mistaken the first human entity is already prepared like that, i.e. hair, etc. are separate parts. Only color-variants would require own .qb-files. And it is not yet implemented that the look is composed out of this parts.
The only way I can see at the moment involves io so itās kind of useless. It would be have the villager always use the same model but have it be a special model that is saved over at runtime with a different color every time a citizen is generated. Youād need to write a .qb ex/importer in lua and a system of reassigning colours but it should work for now.
luaās io isnāt exactly big on binary files so itās not a big loss. In addition, I donāt think itās a good idea to have the game generate files more or less randomly that are then used in the game itself.
If you really want to go for that approach, you might as well supply a bunch of pre-defined hair colors (that you can generate in whatever way you want) - which is probably a saner approach. I donāt think that itās possible to load these external models without mixintos anyway - so even if you could generate the qbs, getting them into the game could prove difficult.
An easy, but perhaps long way of doing this would be to meddle with the qb and male/female.json files.
I learned how to do it while working on my robo mod. No rigging needed.
Basically, each person (for the time being) is made up of 27 parts. Right now in vanilla stonehearth for it gets these from the head and body files. (and later on the profesion)
The Head provides the head, which (unfortunately ) have the hair glued on.
The Other 26 parts come from the Body.
So far the professions are just replacing the torso and the pelvis, I think.
So that leaves us the head (hair, bows, barrettes, etc), hands and fingers(rings and bracelets) and the feet(shoes/boots)
What you can do is divide up the body.qb into different parts (head, L hand, R hand, and feet (L&R?))
Make a bunch of different combinations and then tell the fe/male.json file to grab one of each. This is easy to do as the script is already there for picking a head.
Ta-da! More variations!
Anything more complicated than this would require rerigging the skeleton and redoing every animation. Howeverā¦ (now that I think about it) since @voxel_pirateās blender add-on can now import animations, perhaps that actually wouldnāt be too hard!
I believe you would just have to make the skeleton and meta files, then import them and the new model into blender, then import the animation, then export the animation. Since you would just be adding to the animation (not actually editing it) ,as long as the meta file is correct, all the new pieces should just follow along with the animation!
Weāre not looking for the easy way, weāre looking for a proper way. The goal should be to move away from core file modifications as soon as possible - or even better, not starting that at all. Iām not putting so much effort into that way because itās easy but because itās right.
A middle way would be to simply āoverrideā the human entity, i.e. proxy them (for example by using RP, or if they provide something similar). That way you could do that stuff without modifying core files - with about the same effect.
But that isnāt a requirement now is it? I mean, if one wanted to, Iām sure the hair could be replaced too. Itās just part of the head model after all.
But yes, the animations are a fair point. I believe, however, that this possibly could be solved by importing the old model with the old animation, importing the new model, parenting the new parts to the old parts and then re-animate everything.
Personally my favourite way would be if we could simply attach stuff to bones in the game, i.e. some_hair:attach_to(citizen:get_bone('hair')). Thatās the way the Source engine and stuff like TF2 does it - it offers much more possibilities than simply replacing whole parts (stacking hats for example). Especially if you could define an offset too (for i=1,5 do hats[i]:attach_to(citizen:get_bone('head'), Vec3(0, i, 0)) end). So I hope thatās something weāll get.
Exactly. As mentioned above the human_1 entity is already prepared and we know from past Live Streams that the plan is to have elements like the hair as separated entities which will be mixed with the other components.
From that point of view I still believe that the best way is to simply create a set of different hair-entities and wait for Stonehearth to implement the randomization. Once we see it in the game it will be a piece of cake to add new hairs, etc. ā¦ just add another .qb-file.
For sure if someone is willing / able to code a color-modifier that would even further increase the options.
When I said meddle, I didnāt necessarily mean overwrite. After the next update, with the new syntax it should be much easier to not tamper with the source code. I totally agree that we should be moving away from core modifications, But stonehearth is still in alpha and itās still very young, we have plently of time to ween off of the core (of course sooner is better). The fact that anyone can create a standalone mod at this point still amazes me, and itās hard for me to wrap my head around =]
Itās part of the head matix, and to replace it youād need to either replace then entire head (like how itās currently done) or rerig it with a hair matrix.
Iām pretty sure thatās what I said in the last couple paragraphs in my postā¦ or at least thatās what I ment to say . I canāt think of any reason why it wouldnāt work. The downside would be the monotonous task of importing/exporting the current 30-40 animations for each gender =/
That would be an awesome, and probably the best way.
Unfortunately, animations in stonehearth donāt really have bones, not in the traditional animating way at least. The animation files store the x,y,z and rotation of every matrix every frame (30fps), regardless of how they should be connected to each other.
But if anyone can do it, Iām sure you can! I use your mods everyday to help me test mine .
I hope none of this post came off as too negative. Iām kinda tired, but I really do think you are a good programmer. =] I have every confidence that youāll find the best way to do this!
Not necessarily. Depends on how they implement it, really. mixins, for example, are currently behaving counter-productive. The way it should work, imho, should be mixins < normal json < mixintos, i.e. normal overwrites mixin, mixinto overwrites normal. Currently, the order is normal < mixins - which isnāt helpful at all. If the pattern ends up mixintos < mixins < normal or mixintos < normal < mixins, it would be quite useless in terms of overwriting stuff.
Rerigging might not be a desirable action but itās the best we can do I suppose.
Iām sure @voxel_pirate could come up with some batch stuff if we need him to. Once the old model and the new model have been properly linked, re-writing the animations could be automated easily.
Which does mean, however, that each of these matrices represents a āboneā of some sort. In Source you donāt have access to advanced bone data either - you can just attach stuff to a bone (which means that whenever the bone is moved, all attachments are moved the same way) and query some information. The relationship between bones isnāt necessary for that.
In the very worst case (and what some folks at GMod did too before the attach-to-bone function became available) was to simply query the bone every frame and then re-position the attachment. This is of course laggy and way inferior to the engine doing it (because for example, the engine knows when a bone has really moved and it knows which things are attached to it - therefore, itās calculating once, modifying often).
This wonāt be possible for us, however, since weāre not having a frame hook - the best we could do would be gameloop right now, which is a measly 5 FPS.
Voxel_prirate prrobably could, heās like an animation guru =]
5fps is definitely not fast enough =[
I did just have a thought though about rerigging and animation.
Since the hair will always move with the head, we could have the hairās origin be the same as the headās. Then, we could copy the heads movement exactly; Which should be pretty easy to write a batch file for.
Sure, since splitting up one matrix into multiple matrix simply means that more matrices move the same way it shouldnāt be too hard to simply offset them. I feel like a more general approach would be the batching however, which would do the same but also allow for more advanced, fancy things.
Yeahā¦I concur.They seems to be dark or even darkerā¦May we have to use proper combination of colors and will also take prior concern on selection of hairstylesā¦ Find more hairstyle ideas here http://www.naturalbraid.com/