Heh, thanks. I’m done with the current version, so I need an average, worst-case user… hmmmm… Hey, I’ve got something I have to show you!
The first draft of the documentation for my mods (currently only user-sided, but seeing as rp_hotfix does not add any API whatsoever, this is okay I think?) is ready and available. I tried to make it kind of doable for normal users, but I feel like the whole user_settings.json deal was perhaps a bad idea. Maybe I should offer some sort of fallback option? That means, if the mod has not been defined in the user_settings.json, try to read the old config/[modname].json?
It would make settings easier right now than it is, that’s for sure. But I hope to get going in EmberJS so I can provide a nice interface for all these things soon-ish.
the documentation for rp_hotfix is very approachable… i especially like how you’ve broken down the configuration content…
as it seems your code is being injected into a core file (yes?), it obviously presents a problem with each subsequent release… its the same thing we struggle with when developing for SharePoint (and we inevitably end up writing custom logic that references pages other than their OOB counterparts)…
Nooot quite, at least not anymore (not since… the first standalone release). Since I don’t know/am somewhat sure there’s no way to have a server-sided initialisation, I’m having a JS which simply asks RP to initialize. This way we’re completely standalone… of course the mods are loaded “a bit late” due to this, but since we know very little about actual loading orders, that statement might be absolutely useless.
Anyway, not injecting anything. RP is required like any other service too. We’ve seen this when they’ve updated from 14 to 22 - RP itself was working quite nicely. A few mods broke because of functions that were slightly altered, but most mods and RP itself survived.
If the mod uses the config API (I haven’t linked that before - have a documentation about config stuff!), it would be simple to add external json support. I’m currently adding that until we have a “proper” mod interface. That means you just need to update RP to get config files in mods/config/ to load again.
Since my mods are using RP’s API, they’re encapsulated enough to not care about this. I can change RP to load the config from external sources (if user_settings.json is not available, or perhaps as addition? First config/, then user_settings?) and mods will do that without any update.
I mean, in the end, I developed RP in a way that mods developed for RP can simply move onto the normal modding API without having too many/any changes at all. RP will cease to be a “requirement” at one point and simply become a nice thing to have until it’s gone entirely. At least, that would be the plan. We’ll see in nine months, I guess
ok, correct me if im wrong, but this screams of the same process as would be used in a web application… although, i suppose with the Chrome API being leveraged? that is effectively what your working with here…
See, the thing is this: Mods can specify a file on the client that is to be included by SH (manifest.json:client.init_script). This works nice (minus dependency/order loading, there you have to hope that it’s alphabetically loaded). However, for server sided lua (the server side is everything but the camera/rendering: world generation, AI, etc.) I think there is no such entry point (… believe me, I tried). Therefore, I had to work around a bit.
If you define a JS file in any mod, the engine will load it. Now this JS file can call lua functions on either server or client… And this is the “backdoor” we’re using. Engine loads JS, JS loads lua, lua loads RP, RP loads mods.
Technically absolutely not the right way to do it, but it’s the best I could come up with. And it as hacky and dirty as it sounds (I would really like to change that, believe me!), it seems to work
Unrelated news re: config: I’ve added the option to do about the same as they do with stonehearth.json/user_settings.json. First it tries to load config/[mod name].json (and validates it), after that it tries to load the mod’s entry from user_settings.js (which can overwrite stuff). That means we can simply download config files (sigh) again and put them into mods/config/ and it will nicely load and no messing around with JSON. For now.
Also, I’ve noticed that rp_hotfix is horribly broken (scrolling-wise)… I’m trying to fix that as we speak. I would like to get some sort of out-of-focus-please-stop-moving too, but I’ll have to dig in the binary strings/decoda to find the right function for that (if it even exists).
That just makes me think of the “One Schmott Guy” thing from girl genius. Besides I haven’t really done anything other than look smart so far, although I am at least making good progress on forcibly merging the workshop ui and spawn_stuff. I’ve managed to get to less than a hundred broken things from my mass deletions from both parts. Although I’ll be halfway to version 1 of creative when I get it done and have completed the very first step to Godmode.
@RepeatPan, with the stuff I’ve done with spawn_stuff I’ve thought about how you came up with some of the checks and thought of better-ish ones. Like check against render_info or model_variants for critters as otherwise critters without unit_info like the mammoth are falsely skipped. also I got a bit thrown off by this line
local pt = s.location and s.location or Point3(0, -100000, 0)
What am I missing about lua that makes the and meaningful?
Good! Always open for additions. Just fork it on GitHub, change it, issue a pull request and I’ll check it out.
The default filters that are implemented right now are really “worst case” scenarios, i.e. trying to get only valid entities (no false positives). For critters, I had to check for a pattern that disallowed the wolf teeth and one that kind-of-makes sense. Since bunnies and wolves had an unit_info, I thought it was sensible to use those. I didn’t think to check render_type, but then again I only briefly glanced over the JSON. Remember, most mods that I do start out as some sort of “proof of concept”… It’s not necessarily a well developed one.
Very good question. I shall redirect you to stonehearth/call_handlers/new_game_call_handler.lua:28, place_item_call_handler.lua:36 or workshop_call_handler.lua:30. It could be something that unluac improperly decompiled or it’s just some sort of “developed code” (code that grew over time, was refactored, and therefore kind of got lost).
The and s.location is indeed obsolete.
Meanwhile, this little quote from the stream got me thinking.
And, I mean unfortunately right now the mods… I mean these guys are really clever. They’re sort of hooking into APIs that we didn’t mean them getting into. So we need a little bit formalisation around like “Here’s the proper way to do things” so different mods from different people can co-exist - but so far so good. At least the mods system seems to be working even in this rough form.
I’m quite sure there are more than a few things that I do wrong. Prime example would be add_post_creation_hook - the engine is event based. Instead of creating my own publisher-subscriber system, I should simply use the event system already in place. Truth be told, I still have not looked over the whole code - I merely grepped into files that contained strings I was currently looking for. The decompiled lua produced by unluac is not just not helpful because it is stripped of all comments, it’s also stripped of most (all?) formatting. That makes it a big chunk of tl;dr.
The other thing would probably be about hooking into the APIs directly to make changes - which is about 99% of the things I do. The reason I’m doing it this way is because I simply don’t know any better. Whenever I’m patching things like these, I really try to do it as “light” as possible - which means as few functions as possible and if necessary add an API so others can join in using the same patch.
The main issues with modding currently boil down to about three things; the lack of the proper debugging knowledge (such as CEF’s lovely dev console, ?skip_title and where the loggers all go to), the lack of internal engine knowledge (all the userdata’s functions which are “hidden” behind a C __index, the loading order of { mods, JS and lua }, as well as server entry points for lua) and a good portion of a general idea about the concepts used.
The last thing theoretically could be fixed easily even without “official” answers; __index tables can be guessed/pooled from dumped strings from the executable to some extent (or perhaps with some decoda magic, I still don’t know what capabilities that guy has). But the main thing is really the debugging/access knowledge, second would be the ordering.
I mean, the idea of RP was to get mods to be modular modifications. Avoid that every mod has to patch this function to get feature X (post creation hooks/events, proxy entities, start menu magic to name a few). I’m aware that I’ve neglected these things a bit recently (for example, rp_proxy_factions is a somewhat useless mod itself; its functionality could be integrated into RP directly - kind of the same goes for the random generator one). There’s definitely going to be a few changes but oh well.
I think I’ll fire an email in their direction and ask politely if I can get some answers to those three points. That could probably make my life a lot easier - and modding more successful.
It would be useful if they reply. As for the actual merging I’ve whipped up something quick from what I’ve got as mine has significantly changed how it outputs and sorts so I can’t just use the code. It effectively replaces all of the whitelist stuff and checks with a single function that replicates the functionality by checking it’s not a proxy, a profession, or a human and that it has a model. It causes it to pick up a lot more stuff as well, like it gives you the ability to spawn in weapons and armour.
It’s pretty simple, if I get workshop creation working for creative I’ll throw that at it too.
@naturalnuke The biggest I know of would be from my akrobi thread. There’s two that pass 1000 words in there. I should probably post something again in there.
… just keep in mind that this is the first alpha… also regarding modding. Knowing that this is all not close to final, the best we can do is trying to undetstand how things are working. I don’t think someone expects a complex mod right now .
@RepeatPan’s recollection of @Tom’s comments from the stream, as well as @voxel_pirate’s followup should all be kept in mind… not to discredit, in the slightest, what this brilliant community has done to date, but they have all been attempts at “tapping into” the modding system, as opposed to leveraging the framework the developers are going to eventually provide…
just imagine what will be created when we have proper modding tools, not to mention the fully realized systems, APIs, documentation, etc.
I am very well aware and I’m not doing this to discredit them or anything. I want to help - other users, myself, the game, choose one or more. We have right here and right now the chance to influence how a game is made (not exactly a huge influence, but at least a little bit). We can give feedback about what modders expect and how they would approach things, what they want to do and how they want it done. We can help shaping whatever the future modding API looks like.
If you strictly go for “Well, it’s an early game, it’s surely coming” - I would like to point towards Minecraft, which has been around for years announcing a modding API that surely comes in the next update. You know, the one after this big update! It’s never too early to start with this as long as the community goes on about this in a reasonable way. Nobody is to demand anything or complain without a proper reason. If we can manage to get together on a table from time to time and talk like adults (which, in my humble opinion, is an impossible thing to do in the Minecraft community), we can go far.
We are not close to know how things are, oh no. We can see the code (decompiled - no comments, lousy formatting, perhaps some relics from a malfunctioning decompilation) and we can see the concepts that are used - some. There’s lots of stuff we cannot see (for example, the game has a crash key - has anyone found that one yet?) that is either hidden in the engine or, in lua’s case, behind C __indexes.
A simple example would be KeyboardInput. It’s a userdata with an _index that is a C function (if I had to guess, it’s a luabind enum-to-lua). We know that it always had a KEY_ESC (previously without KEY but the point still stands). Since the last update, we know that it also has WASDQE and SPACE. What about the other keys? You can either guess or… well, that’s it. Using improper coding, you could say “Well, I simply use the ASCII Code that does the same thing” and have plenty of code that has such wonderful statements such as e.key == 185. This is one of the cases where I would say “That’s not supposed to happen.” It’s one example of many - yet it’s one of those cases that I least expect any solution soon. Building lua documentations from C code is something GMod still struggles with, even after all those years.
There’s a lot of stuff happening in this black box, the engine. There are some things that are required for even the simplest of mods; the loading order would be a good example. For example, to mess around with the JS views (which for some mods simply cannot be avoided), it would be helpful to know when the JS is loaded, when the main view is instantiated, and how to put something in-between or after those actions. Perhaps there’s an event for that already but we simply have not found it - perhaps it’s not referenced in any existing script. We don’t need a way to specify mod loading order right now as long as we can “hack” our own way in. We’re not necessarily looking for final, long-term solutions. We’re looking for intermediate ones. Preferably those that don’t create a lot of effort to create and maintain for them but are powerful enough to use for us.
Remember that their normal development environment likely has two, perhaps three or four mods which were all written by them. If they want to modify something, they can simply change the code. This is something that is not available if you want to create a true modmod - even when the API is there, it won’t (I would even go as far and say it can’t) cover all possible cases. They also likely know the classes and functions by heart - and if not, they can check the source. We don’t have that latter option.
I such at metaphors, but here we go: Currently, modifying the game is like digging a tunnel with a pickaxe. It’s working, it’s not quite state of the art technology but it works. It takes you longer to get through the mountain but it works. Might not be the prettiest or stablest tunnel, but it’s a tunnel. What we could use (and I kind of ask for) isn’t dynamite or a tunnel bore. It’s a jack-hammer. For all I care, it can be a humble steam powered one. Or pneumatic. I don’t think they ever made steam ones.
There is so much more potential in this, even in this quite early stage. Because the whole game is kind-of-accessible (code-/patch-wise), it’s possible to change about every single aspect - as a modmod. But a lot is wasted right now by using inadequate tools.
The modding API is far from being done - I know that. The reason I’ve created RP in the first place was to create an abstraction between the current game and mods until the official API comes tagging along. In the best case (which is not quite achieved yet, might never be), this allows the community to create modifications earlier and projects can later be ported over with little/no effort (as the modding API progresses, RP would simply redirect towards it instead of doing its own magic). Projects take time, especially larger and more complex ones. Instead of every developer for himself, a joint effort to do exactly what Tom said - to have modular modifications (I’ll call them modmods now) that can co-exist. On the developer side, I would say it gives them more freedom. Without the “pressure” of the community calling for a modding API (because there are a few intermediate solutions that are kind-of-okay), it could allow them to focus mainly on the game itself while the community takes care of the modding part on their own. All they need is a little kick to start it off.
It’s kind of hard to leverage something that does not exist yet, or has only been sketched. We’re filling holes as we go, whether or not we do it with the proper stuff kind of doesn’t matter until there is the proper way to do it. It’s all about innovation, after all.
Of course, but as I’ve said before, I think it’s important to be an active part of this process rather than sit back, nod and when the modding tools are officially released one complains about “Oh well this isn’t what I have imagined”. Personally, I think kind of “accompanying” a growing project is highly interesting - probably more interesting than just having a finished game with some API and a stamp on it “Mods inside”.
Now,
I don’t think I’m going to merge that one, but I’m open for discussion. Truncating the system back by removing the ability to fine-define per-category what is whitelisted and what not for a simple “Oh well, if it can be rendered and isn’t a human it’s probably okay” sounds too dangerous.
Yes, you can spawn more stuff, but the question is whether this is required or necessary. It’s all fine and dandy if you can spawn armour now, but armour doesn’t do anything - neither do weapons. I personally don’t see why they should appear in the spawn menu.
Under no circumstances should players be able to spawn something that can mess up their game. This is kind of the reason I put such harsh and fine-grained filters in place. Admittedly, the window kind of isn’t part of this category, but eh.
Removing these filters that allows us to define per-entity folder what is allowed and what not for a simple assumption is kind of crass. Remember that this does not just catch Stonehearth stuff, but stuff from other mods as well. You can not always assume that other mods have the same standard (or follow the same rules at all) as the original entities, so caution is heavily advised.
Propably vecause my lack of experience in GitHub - looks like I have a “little problems” with branch editing when you make a new release (“patch-1” was for 1400, “patch-2” for 1402, “patch-3” for 2300)… :I
Well, a nice idea, but I think a “wrong” approach - since you’re likely not going to maintain these old files, a new commit will do just as well. I mean, I could use branches for RP, I guess, but I don’t think (and don’t want) that anyone is using or maintaining an older version.
So personally, I would just operate on one branch and just fire commits as you go - it’s probably easier. I haven’t worked with GitHub’s client, however, so I’m not sure how well that works. Or how it works at all.
oh, I couldn’t agree more … don’t mistake my comments for suggesting the modding community shouldn’t be as active as it is… it was indeed meant more as a compliment on what’s been accomplished to date, and an interest in looking forward to what the future holds…
I’ve been trying to determine more intelligent ways to find valid entities. I’ve realized that a way to detect humans a playable race is difficult at best as professions are independent. In related news trying to promote a wolf to a worker causes an error, however you can promote sheep and rabbits so it’s odd. They don’t work though, it just screws with thier model.
.