[Mod Idea] Villager's Looks


#1

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 :slight_smile:

Mod may be at the moment impossible/very difficult to create. So, let’s start explaining :slight_smile:

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. :stuck_out_tongue:

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 :stuck_out_tongue:


#2

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.


#3

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.


#4

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.


#5

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.


#6

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 :cry:) 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! :smiley:

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!


#7

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.


#8

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.


#9

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 :sweat_smile:. 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 :smile:.
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!


#10

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.


#11

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.


#12

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.


#13

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…:slight_smile: :slight_smile: Find more hairstyle ideas here http://www.naturalbraid.com/