Any images for a proof? 
Differences of opinions here mainly, I think white or blacklists within the code are going against the purpose. If they mimic stonehearthās naming conventions Iāll be able to find and track down what I need. For example in my version it currently checks entities against faction data to see whether theyāre part of one and if so checks for professions without promotion talismanās to promote to. Thatās because there isnāt code for gaining a new citizen yet or Iād try patching into that. I fully allow people to create proxies because there isnāt any reason why they shouldnāt be able to, Iāve even nearly got workshops/professions working. I block wearable equipment because I havenāt seen any that is good yet and I donāt think there will be any at a guess. I just do a lot of stuff because I want to be able to create every entity they put in their manifests. Besides itās my procrastination code, itās expected to become hefty.
Sure, they wonāt actually behave like workers but here you go.
2 Likes
The purpose is not āSpawn everything that is in the gameā, the purpose is āSpawn useful thingsā.
The idea of the filtering was to allow useful entities to be displayed - remember that space was/is sort of limited. What an āusefulā entity is depends heavily on the category. I donāt think proxies, for example, make a lot of sense to spawn - because in the end, a proxy is just a carried item. The whole proxy system looks like something that will be worked over at some point - I would much rather see one proxy entity instead of one-per-entity.
A filter per-folder is a much cleaner solution than one universal check that decides based on a few values.
1 Like
Different goals then, I plan for mine to be useful to modders. It will be able to both create everything but also to create modifications of them. Iām giving people the ability to do things like input size, name, or whatever. I give proxies in a different way for example by letting them add them directly to a stockpile. Thatās the difference, mine is a part of a larger mod Iām making that should let them do just about anything that is possible to do. The goal is to make it make you as close to a god of the stonehearth world as itās possible to get. Yourās seems more like a sandbox mode, similar but different purposes and suitable for different people.
Iāve closed the PR on GitHub (and quickly summarised why I think itās a bad idea) - but itās your choice. I want a more safe tool, you want a more complete one - these are really incompatible goals.
Meanwhile, letās talk about RP again for a bit. Iām currently thinking about re-designing the JS side a bit. Since thereās no known way to mess around with the lua loading order, we can at least mess a bit around with JSā one.
The idea would be to have two additional mod files, ā+rpā and ā~rpā. The naming is chosen to āfoolā the current loading process:
2014-01-13T14:09:51.717Z => "radiant"
2014-01-13T14:09:51.957Z => "+rp"
2014-01-13T14:09:51.957Z => "rp"
2014-01-13T14:09:52.255Z => "~rp"
2014-01-13T14:09:52.365Z => "shell.init"
2014-01-13T14:09:52.365Z => "title.init"
2014-01-13T14:09:52.377Z => "gotoShell"
2014-01-13T14:09:52.388Z => "server_init"
(since this test contained little more than a simple foo.push, itās possible that +rp and rp were executed quickly after each other).
They would do the following stuff:
- +rp itself contains the JS library that is currently within rp. All current JS will be moved from rp to +rp and +rp will get a few new functions where mods can register (instead of the current
radiant.call('rp:init_server')). - rp itself will only house the lua side, including callbacks. It will still handle the lua-file loading.
- ~rp will perform some special magic. Since all mods have been loaded at this point (all mods before ā~rpā, which means every mod that has a sane name), ~rp has the complete list of mods available. It will then somehow (I am not completely sure how right now) enforce that the application itself does not start until it has gotten the list of (active) mods from the lua side. Then it will go through the (registered) JS mods, call them (similar to how the lua side works right now) and after that is done, it will start the application. Or rather, continue it.
This sounds massively complicated, and it is, but it allows mods to have whatever name they choose and disable/enable them without the smod file loaded. It also allows mods to query data from lua without risking that they miss the patch time for a view.
Quite sure this is so not what we are supposed to do, but itās the best thing we know so far.
1 Like
@RepeatPan , you are already Tonyās favorite person on the internet. 
Sending a smoke-signal to @Ponder, from where he is buried deep in AI valley, valiantly deploying vaccines for our OCD stockpile bug.
In addition to your prolific innovation, what we appreciate most about your thoughts is your awareness of how complex it is to release a āfinalā API. As people who have released API after API in our other lives and coded our way through the consequences, we can say with experience that your willingness to tweak your own stuff to accommodate structural changes makes you worth your weight in gold. We want Stonehearth to be around for a long time, and as such, our code needs to be sufficiently structurally sound to support years of evolution. Unfortunately, weāre still discovering exactly what that means. We havenāt released any official information yet exactly because weāre worried about inviting you all to build houses on this prime voxel land, and then ruining everything with catastropic earthquakes.
Team Radiant will continue to discuss. Thanks for letting us know how important it is to you. 
Weāre listening, even when we donāt always have answers.
4 Likes
In my opinion, thatās part of the fun too. As Iāve said above, people playing the game and modifying it right now should be aware that whatever they have is really volatile (I guess not having a save option is the best way to demonstrate that ;)). I still live in fear that whenever I do deploy this JS loading system, youāll release a new build that has exactly that integrated into the engine itself. I guess one could compare it to extreme sports - thereās always a bit of adrenaline involved.
Not all changes that destroy our little houses must be bad, however. Itās possible that we will profit from the volcanic eruption a little bit later. Itās also giving a chance to re-think about the building we had before and what could be improved - stuff that would normally go under āEh, it ~works right nowā.
But of course I respect your decision and while I wish there was a little bit more light in this dungeon, Iāll continue the exploration. By taking the usual way, through every wall encountered.
2 Likes
I am pretty sure every modder is aware that updates might break everything.
But as a non-coder I can see the excellent job you guys already have done to make everything easy to mod. copy/pasting code works in almost every case. The biggest problem is not messing up names / , / {} or similar things. 
2 Likes
as one of your biggest fans (
ā¦ back off @Ponder), watching your library evolve is certainly part of the fun tooā¦
very metaphoricā¦ sort of phoenix rising from the ashā¦ 
Quick question, letās say it would be possible to have an auto-updater for mods, but it would require you to download an executable from me (which likely would require the .NET Framework)ā¦ How useful would that be and how willing would people be (i.e. even if it was OpenSource and all, how trustworthy am I?)
That seems troublesome, elaborate? Is it an auto updater for only your mods?
It will be a simple auto updater over HTTP, which checks if the URI located in the modās manifest has been updated or not. If thatās the case, the file will be re-downloaded, otherwise itās kept as it is.
This requires of course some sort of āstaticā address for the mods and proper Last-Modified headers. But each mod can be hosted wherever you want. My mods will certainly be the first to feature it, others can use it of course too.
1 Like
I see. Mods hosted on Stonehearth Kingdom, when updated display when it was (you guessed it) last updated on the main download page of the mod (See Desert Mod: http://www.stonehearthkingdom.com/files/file/21-desert-re-skin-mod/). Could the Last Updated portion of the mod be scraped from the page, and check when it was last updated against that? So when it is newly updated the static url provided on the download page can be used to download the latest update of the mod?
No. Iām not going to these lengths to add error-prone āMaybe this is the last modified date?ā checks that will break whenever the site updates its layout or are generally less reliable.
The only compromise I am going to make that the static URL can be a json, formatted like this. If you want to āabuseā my updater as SK client, youāll have to provide such a JSON and have mods point towards it.
It shouldnāt matter if the site changes itās layout as the page can be scraped for the specific class which will be the last updated portion as it will be the same on every mod page, so it will be very easy to target the last modified date with no confusion. I have no intention of making an SHK client as of now, I would just like whatever you are doing to be compatible
Who is going to promise that? Why should the program add a special case for one site (and am I to add such special cases for every site then)?
I believe that with the JSON approach we can both be happy. I can throw the JSON onto my Dropbox, linking to the most recent GitHub release, and you can have one created server-sided with a script (unlike smod files, the JSONs may be generated on-request, as their Last-Modified header will be ignored).
It shouldnāt be too hard to integrate such a JSON response into SHK.
Very true. Iāll snoop around and see what I can do
Meanwhile, Iāve started to build the whole JS Mod handling. Using deferred objects, I think this can be pretty well.
My only issue so far has been that I seem to be unable to destroy the loading screen Iām injecting before the title (that loads all the JS mods and displays this properly).
If everything goes according to plan, JS mods could show progress (if they want/need to), are inheritable and all that SimpleClass fuss.
Itās still quite a mess and Iām not quite sure yet how I will merge the JSON and the mods, but weāll see.
An auto-updater is not practical and people would not be very willing. I suggest using a more traditional approach to hosting your mods and simply focus on the mods themselves.
I tend to disagree. Especially in this early phase, auto-updater can be extremely useful. Of course, once mods are updated a few times a month, this no longer applies.
Weāre also not exactly talking about a āloss of timeā either here; nobody has huge modding projects yet as there are still lots of empty spots on our map.
I mean, I can wrap a program like that up in two hundred lines or so. Give me a day?
Actually, letās just do it. 3 2 1 ready go.