Say hello to citizen, or as she will be know, EVE:
She was made at the crafter, she eats and sleeps but doesnt work and is naked:
Here is the file that makes her, just make a new recipe for the carpenter:
So who wants to help this community project work?
color me intrigued… but what’s the end result? are we building Eden, or? 
Ahh the end result. Consider her a test bed for modding in craftable items with full AI abilites, turrets, carts, robots, whatever you want. You can do a goblin as well using goblin instead of female_1 in the file. It is on your team doesnt eat doesnt sleep. I dont know about combat yet.
I think you may of hit upon something, @Wombat85, If “Eve” could work (as in how a worker works) then you could almost have yourself a golem machine…
Has nobody learned anything from Terminator ?.. 
Nice. This quest to get EVE working is the fun part of modding, as well as the frustrating part 
.
I will join. 
Lets see, can we promote her?
She needs the worker “outfit” or she won’t work. 
Awesome idea, though!
Yes, that’s why these ones aren’t psycho killing machines.
…
For that, you need the T-100 Upgrade Package, otherwise known as the “wooden sword” 
.
Now all we need is Adam.
Right, say that after Stonehearth one day asks you to install a certain unscheduled update that the devs don’t seem to know about.
May as well already start organising the resistance…
So tried this:
and it didnt crash, it was built, except there is no item called worker to appear, so the carpenter walks to the stockpile and drops nothing in. Any thought how can assign this profession to the worker at the recipe level, or is the consensus we need to play around in famale_1?
This is the lua code that create our workers at the embark, any thoughts on how we can introduce this to a build event at the workshop:
Recipes and items dont have luac code so this is problematic, and I would really think it a good thing if we could mode it from a .json standpoint
Worker is not an entity as female_1 is. It is just some AI code that assigns some job tasks. So you cant create a recipe for it.
What I think might work, with my limited code knowledge, is to make an item same like the saw. link it to a worker promote code. And give EVE a command button to give her the ability to promote. Maybe the critter/pet code can give us some insight how this exactly works. As you can click a button and it assigns the critter some pet profession.
The good thing is Radiant is writing a guide. Some part is already in.
Actions
Actions are the fundamental building blocks which drive Entity behavior. They handle everything from sleeping in a bed, quaffing a beer at the bar, to running away from Cthulhu. If you need to add more basic capabilities to what an Entity can do, you're probably going to need to write an Action.
Overview
All Entities have a pool of Actions which they can choose from. These Actions, collectively, represent the sum of everything the Entity could ever decide to do. Each Action in the list performs a very specific task, called an Activity. An Activity is simply a name / args tuple which describes some specific behavior. For example, the PickupItem Action header looks something like this:
PickupItem.does = 'stonehearth:pickup_item',
PickupItem.args = {
item = Entity
}
Here, the 'does' field in the header contains the name of the Activity and the 'args' field the names and types of all arguments passed to the Action running the Activity. When actually running the Action, all names and types of the fields in the 'args' header field must match.
The act of picking up an item is actually quite complicated. First, we need to find a path to an item, then follow that path to reach it, then play an animation and finally move the item onto the entity's carrying component. That's a lot to do! Each of those steps are actually performed by other Actions in the system, each of which exposes its interface through Activities of their own. For example, PickupItem uses the RunToEntity Action which implements "stonehearth:goto_entity". RunToEntity in turn uses actions which implement "stonehearth:find_path_to_entity" and "stonehearth:follow_path".
In summary:
Actions implement all behaviors for an Entity.
Actions can be composed of other Actions to implement complex behavior.
Each Action implements exactly one Activity.
Actions vs. Activities
Now's a good time to describe in detail the distinction between Actions and Activities. Activities are what an Entity should be doing. Actions are how an Activity should be done. This distinction is important.
Suppose we want an Entity to eat some food (the what). We want to be able to implement many ways of actually doing it (the how). The most straightforward is to walk over to a piece of food in a stockpile, pick it up, and eat it. You could imagine many more ways, though. What if the Entity is a Wizard and has a Conjure Food spell? What about going over to a chest and taking a piece of food out of that to eat it? Maybe there's a Cheese Golem who can eat his arm? Each of these would be implemented as a separate Action, all of which do the "stonehearth:eat_food" Activity. The AI Component will dynamically pick the best Action for the job based on information supplied by the Actions themselves (see below).
Conceptually, the sum of the Actions attached to an Entity represent a dynamic graph of nodes where Activities are the edges between nodes.
Dispatching Actions
The Entity's AI Component is responsible for deciding which Action to run at any given time. All Actions are run on a Thread owned by the AI Component. This ensures that at most one Action can run on an Entity at any given time, which would lead to some odd results.
The AI Component thread is quite simple. It chooses an Action which does the "stonehearth:top" Activity from the pool of Actions in the Entity and runs it. When that Action finishes, it chooses another Action that implements the "stonehearth:top" Activity and runs it again, until the Entity is destroyed. Those actions, in turn, will execute Actions to do sub-Activities, etc. until we reach a base Action which is so trivial that it's implemented in straight code.
At each step in this process, there are likely many Actions which implement an Activity (e.g. "stonehearth:goto_entity" could be done by walking there, or using a teleportation ring, etc.). The AI Component uses a special election process to determine which Action gets to run. Specifically:
All Actions are asked to "start_thinking" simultaneously. "start_thinking" is the mechanism by which an Action is informed that the AI Component would like to run it.
The Action which returns a result first is immediately run.
If multiple Actions all return a result simultaneously, the one with the highest priority gets run.
If multiple Actions all have the same priority, they are weighted by the "weight" field in their header and a random Action is chosen.Eve can now be upgraded:
Can someone make a worker tailsman for me, kinda lonely on this community project.
Up date inbound, we also still need a way to update the citizens menu so eve gets added.
Tutorial on how I got her shortly.
Tutorial: Adding eve, it goes through quick because I use jing. I skip over the basic stuff coverd in other tutorials.
Part 1: Modding the files
Part 2: How she works and whats next
What about the default hammer that workers use?
its not a tailsman, its written differently, can certantly use it as a basis for one though.
Yeah, but I mean the model etc is all there, so you can surely just clone the, say, hoe code & switch out the model etc.
Yea I could, was kind of hoping @SteveAdamo or someone else might want to, its easy enough to do and a great starting point.
apologies, I’m off for a one week vacation… took my family to DisneyWorld! 
I’ll be back on Sunday though … although at that point I’ll likely be feverishly responding to work emails… groans
