The game runs fine on my computer (quad core, awesome graphics card etc).In the first build I was getting stuttering due to path finding, its, thankfully, fixed now. (path finding seemed to pause the game very temporarily, this is because of the way they do path-finding (on the same thread), but they made pathfinding better, but it is still on the same thread)
But, i still sometimes get stuttering with lots of commands (though they are working on that, so)
yea.
That night theme. I dig it.
Solid update is solid.
Quadcore, Hexacore, Googolcore doesnāt matter if your application isnāt multithreaded. SH canāt make too much use of MT because lua canāt deal with it. They can (and do) separate the GUI (i.e. chromium), the server lua state and the client lua state but thatās about it.
The threading and synchronisation overhead can really easily kill any performance gain you get through multithreading. Itās not like you can just add a few more threads (and assume that people have CPUs that can run them, too) and suddenly you get twice as many FPS.
I realize its hard to do with lua.
Iām not worried about performance i get a solid 100 fps, path finding can pause the game because the computer is only working on that thread, which is why it should be multithreaded, also they do the pathing with c++ not luaā¦ They only activate the pathing with lua.
Like I said however, It doesnāt happen anymore.
(only under extreme situations)
Dwarf fortress splits up its path-finding based on the amount of settlers you have, so you get no overhead from it (but it is also in c++)
It doesnāt matter. I can write you a program that uses 3 threads and performs worse than one using just one thread using the exact same algorithm.
More threads != more performance. It doesnāt matter that this is done in C++, which is capable of threading, and not in lua: You need to get the data back from the worker thread into the lua (i.e. main) thread. This requires synchronisation of some sort. This can (and will) slow down one or both threads and/or show increased memory usage.
Multithreading is not the holy grail, itās not a synonym for optimisation and if used just because āthereās work to doā you often get worse results.
Unless each single path finding operation takes ages (Iām talking noticeable seconds here) and youāre doing an okay-amount of them all the time, threading is a waste of resources.
I stated, it only happens under extreme situations now.
I was just making a suggestion that MAY possibly perhaps work at some point.
They stated they are working on a new stuttering issue (most likely the cause of the āextreme situationā stuttering) (which involves your settlers āThinkingā too much so it will most likely be fixed.)
I also suggest that they find a way to (based on the amount of settlers you have) make pathing less precise slowly over time. (which is how dwarf fortress handles it) (and yes this is possible, so donāt give me spork about it, I have done this myself,)
edit:
I edit my stuff too muchā¦lol
This sandwich tastes good but my legs feel burnyā¦
They could also , have an āAI pipelineā where they split up multiple villagers pathfinding routines over a few frames, so 4 villagers arenāt path finding in the same frame, instead, it would take 2 or 4 frames.
It would be unnoticeable.
And it wouldnāt make a difference for large cities. because there are so many of them that you really donāt notice the slight delayā¦
(they may already do this however, i havenāt looked into it much)
@Avairian if you try out the example from the official blog, this is actually a basic mod and works. The mixinto is renaming and -sizing the tree and the override changes the model.
Will try to get something done with my own stuff next.
Update: Strange behaviour. I have re-installed Stonehearth and now it seems like I have the same issue. Can only place the camp standard and after that nothing happens if I have a ācustom mod installedā.
Update 2: Seems like it is mandatory to have the .smod-files in the folder, otherwise mods are breaking the game (game stops after placement of camp standard).
Wellā¦ I havenāt launched the game inā¦ looks at calender a few weeks! I better get playing with the update nā the such.
Here a screenshot based on a blank installation including the āFlagstoneā-mod from the official blog.
Copy and pasted the parts off the blog and then changed things around to mixin my quince_bush.json and overrode the model with the quince_bush.qb. Sees to be working now, must have had some sort of formatting error. Gonna try experimenting with it after work. 
It just seems that Stonehearth is now handling the mods-folder different. I have troubles to get anything running if the .smod-file is missing. Also if I edit something inside the .smod-file this results into breaking the game once the camp standard is placedā¦ which makes testing at the moment a bit cumbersome. As soon as I have a more clear picture what breaks when I will file in another bug report.
interestingā¦ I wonder if this is somewhat āby designā, to enforce the adoption of the new mod API tools?
If it is, it is a horrible design decision. My personal workflow was to modify stuff in the official libraries first, then port it over to RP (for example, to find out whether function X was called and therefore had to be investigated, I put a print() inside it).
Not to mention that some functions can really need an inofficial patch - their assert for example was really useless in the older versions (āassertion failed!ā without any context, err). If we canāt patch that anymore I donāt know what to do.
But hey, Iām awake now so Iāll start figuring out what is going on - I might even do this as a stream if thereās interest. Since the game does work partially, I donāt think itās intention but rather something with resource loading going haywire. Itās time to add debug.traceline() and have some fun with it.
seems much more likelyā¦ best of luck with the investigation-ing! 
Nicely done on the new release. Got in there and had a house up in moments. Granted, one of my workers decided to get stuck inside of it while it was under construction. BUT! As soon as the scaffolding was removed they returned dutifully to the task at hand. ^^
Bravo!
this is precisely what happened to one of my workersā¦ oddly enough, the only male among the groupā¦ perhaps this is @sdeeās doing?
This happened to one of my workers as-well.
Reminds of the the old Edgar Allen Poe story, āThe Cask of Amontilladoā.
