as I’m having a time if it, trying to decipher on my phone, explain in laymans terms… you’re adding shortkey options?
ok, i was in fact running a modified stonehearth.smod file earlier, but i replaced it with the original, relaunched the game and… nada…
stonehearth.log (2.9 KB)
Would you have any ideas on how to override an action? I’ve tried google and several attempts but I’m not sure what you’d even need to do to change it. What I’m trying to do is to enable the new game options menu but I can’t seem to get it to work from a separate mod. If there could be the option to enable or disable mods from there it would be quite good, all that would need to be done would be changing the config file to disable some of the mods are doing a special relaunch to skip the main menu and splash screen.
The other interesting thing I’ve been trying for which I’m not sure if you’re tools could be helpful for is a JavaScript console. It could be quite useful for debugging ui’s and quite a few other things I suspect…
Do you know if ther is anyway to alter the handlers or any other part of the lua while the game is running? I’m pretty new to lua so there might some trick I don’t know. The docs seem to change language though for the relevant parts so it’s probably just some pre-req knowledge that I don’t have.
Nope. It allows you to add new entries to the start menu (i.e. the building menu). Either by adding new categories or adding to existing ones. This can be used by multiple mods to add whatever they please. It’s really intelligent! I haven’t found a good way to get this into an example, however. Perhaps I’ll pick up the existing but not quite implemented hotkeys for “Chop tree” and “Collect berrries”.
No sign of RP; please add stonehearth_mod.log
and stonehearth_mod_server.log
. And if those files do not exist, uhhh… You’re sure you’ve placed the file into mods/rp.smod
?
What you likely want is to use the view’s .extend
method (check the commit I’ve mentioned above or rp_time_is_money
). You can simply re-define functions and they will be overwritten (the old function is still accessible using this._super()
).
Not really possible without rewriting all mods quite heavily. They are patching game behaviour and this needs to be done before any other mod can access it (dependency system) or the game is using it. Many game services keep references to other services, so overwriting these services completely would become impossible. The only mod that currently skips this would be my tim anyway, and I doubt many others will do that.
I’ve thought about adding something like this, but most likely this would not affect current mods (i.e. after disabling/enabling mods, a restart would be required). This would be the most sane way to handle it. What I would do to get there would be:
- Patch
App.StonehearthTitleView
(I think it’s called), overwritedidInsertElement
to add my own button into it. Clicking on it owns a new view that I’ve defined, which is the mod panel. - The mod panel calls a lua function which returns the list of mods. This can then include descriptions and versions too, fields that are currently not present in the
manifest.json
but could easily be added - more data isn’t going to hurt anyone - Clicking on the checkboxes/buttons sends a call to lua, which then disables/enables the mod and writes those changes directly into
config/rp.json
. This requires access to a specialmod
table, however, or a new status. Right now, disabled mods, mods that fail to load and mods that are not RP at all (and therefore we have no influence over) are all justrp.constants.mod_status.SKIPPED
. - This is not going to change anything about JS right now. By re-designing the thing a little (all JS scripts that base on RP are usually required to call
rp:server_init
because otherwise Stonehearth might not be available or something like that - a call assures that all functions have been initialized), it could be possible though. Instead of callingradiant.call('rp:server_init')
, we could call for exampleradiant.call('rp:mod_init', 'my_mod_name')
, which would then return a boolean (true if the mod is active (i.e.rp.constants.mod_status.LOADED
), false otherwise).
So, there’s work to do and I’ll get to it - first I’d like to show off the new start menu thing a bit though, because I think it’s really, really useful.
If you watch this livestream, you see that they actually have an implemented debugging… center… thingy running. They’re embedding Chromium as far as I can tell, which means that by browsing to http://localhost:1338 with a capable browser (for example… Chrome), you should be able to access the developer console to interactively mess around with the game and get access to all the fancy console
functions.
This would make my life so much easier (and prettier than rp.log
), but browsing to that location right now returns simply a blank page (however, localhost:1338/json
works, so I am not entirely sure what is going on). Perhaps they have turned off access to these tools, perhaps they don’t exist in the release build, I don’t know. That they’re available, but only some-sort-of strikes me as really odd.
A console that would show the lua log, however, could be interesting (i.e. whatever is written into the stonehearth_mod.log/stonehearth_mod_server.log
). However, I have not been able to find a good way to deal with that - lua would need to send those events to JS somehow and that’s something I’m currently struggling with. I have an idea that involves a cache table and object tracing, we’ll see what happens. I’m horrible at graphical stuff however (check out my posts in the Geoffer’s Academy) so be prepared.
If you have a reference to any of the classes, you can modify them (as simple as that). Simple monkey-patching is what about 99% of my mods do. Whether the game is running or not yet doesn’t matter, if a function is called over the table (i.e. service:foo()
) and has not been cached (local foo = service.foo
, which never happens by Radiant) then you can go nuts on it. The same applies to JS.
Remember that once a function has been executed (for example, ctor’s, didInsertElement
and friends) patching it isn’t going to be of any use (check rp_time_is_money
for an example: If App.shellView
already exists there’s no use in patching its didInsertElement
to skip directly to the game - I need to “manually” switch, which isn’t as pretty).
What about the log we already have? It’s event_call_handler.lua, and the event_log ui. I’m sure there is some way to modify that to make your own logging service.
I also noticed an issue with spawnstuff, it breaks on smaller screen sizes. I’ve got a very simple fix as it’s fairly trivial to make it however it uses css and I’m not sure if you’ve got a way of setting that up through rp so I figured I’d check.
As for the js debugger I’ve been trying some things, the best lead I found was this but it didn’t seem to work.
EDIT: It seems like it might’ve been disabled in the release for some reason. That’s my only guess anyway.
EventTracker
seems to be not used anywhere at all; at least it’s not referenced anywhere inside of lua. I believe it’s a dead end. However, event_log.js
does about what I’ve planned to do earlier; it’s tracking a variable. So that seems to work.
An issue on Radiant’s side as smaller screens are kinda broken. The next version of rp_spawn_stuff will be completely different and I guarantee it’s going to be amazing. Have a video of the current version that will likely be released this evening along with RP 1402. If you want to have a look, check out the video I’ve uploaded. I’m still tweaking a few things (for example, trying to work around the ghosting issue that normal SH has too), making an icon and generally prettying stuff. But so far, it looks promising!
Yepp, that’s what Radiant uses (just on port 1338). But as I’ve said, for some reason, it doesn’t seem to be accessible to me. I’ll have a look at it later again.
if ever there were an understatement, this would be it…
the video has the “creative mod Steve” jonesing… very cool stuff!
as for my woes with loading your framework/mod, i will place that squarely on me and or my system… while i am quite confident i placed the files in the correct folder, i do not have as much confidence in my machine being able to adequately run SH, let alone any modifications i might try to toss at it…
this will be remedied … shortly
my. sweet. baby. geezuz… he’s broken the internet!
have you managed to place items at varying angles? does your talent know no bounds? can i continue to pose questions to which we already know the answer?
It’s really not my work. The guys did a pretty sweet job in the engine, all I did was to provide a possibility to place items in non-90 degrees (pressing shift rotates 15° instead of 90°). For beds, this doesn’t work quite (they still align themselves to an axis, which can look funny) but chairs work fine. It allows you a bit more of variation, but keep in mind that it’s still a grid below - so you can’t really place stuff “freely”. At least, I don’t think so. I’m not going to investigate a replacement for radiant.terrain.place_entity
as that one works quite fine.
Charmed, but I’m quite aware of my limitations.
Can we continue this conversation with rhetorical questions?
as in, the units will sit themselves correctly, in chairs placed off the 90°? intriguing… stands to reason they would be able to sleep at those alternate angles as well… sir, you are making it difficult to stay away from the code…
at this point, im eager to hop in, but with my machine hardly able to run the client, not being able to quickly make changes, and hop in to test is just…
can do?
Check the screenshot, there’s two doing that.
In theory, yes. Perhaps the sleeping effect just isn’t handling it well, I’ll see what I can do about that later.
I looked and found out how it works. get_event_tracker is defined in the manifest to refer to the call handler EventCallHandler, that is essentially just a bridge to json for the EventTracker service. That service is a storage area for the data of the most recent event from the EventService service. That’s what is called to add things to the log, it’s used like this
event_service:add_entry(“text here”, “optional type”)
Hopefully that helps as it seems like you could just copy paste everything and rename to get a new logger.
I’ll have to look at your code once your done with the spawner as well, get it functioning with the ui I’ve been working than tackle modifying the attributes of specific instances of entities.
My current mystery is that radiant.call seems to be being used to refer to things in radiant even though they aren’t in there. Like playing sounds from js does it with radiant:play_sound even though I can’t find where that exists.
I see now (I had limited my search to lua, which is why it didn’t come up with the manifest). However, this is a completely different kind of log; it’s the thing on the right that keeps track of your citizens. The messages like “I’m feeling grumpy because you didn’t build a bed next to me” or “I’m sorry to chop you to bits, Mr. Tree”. It’s not really usable for programming logs, I’d rather have something that can be scrolled, perhaps filtered. In the end, yes, it’s just using a tracing to get the job done - which is what I’ll likely do too.
You’ll have a hard time finding it, because it’s defined in the engine. radiant.call
simply patches a message to an internal message system, trying to find a proper receiver. Of course, those receivers can be implemented in the engine too, there’s quite a few of them.
would this be viable for combat logs, etc.? or assuming those of us with OCD were interested, a complete log of virtually every action captured by every unit from day 1?
It’s already possible to have data from all loggers bundled in one location. However, if you write that to a file, you get crazy lag spikes and stuff simply stops to work. I believe promoting someone wasn’t working anymore because it took just so long. The amount of data you can gather from all logs is quite impressive and should not be underestimated.
I mean, you would have to be more precise about what you mean with “virtually every action”. Every time the AI decides which task is the most promising? “I chopped down a tree and ate some berries?” What level are you aiming at?
yes sir… as someone who has to routinely troll SharePoint event logs to restore applications, and keep Executives from leaping from tall buildings, i can appreciate that logs files can grow in size exponentially…
i was thinking about this from the “chronicler” perspective… capturing the “major” events that could define a units actions over the course of a day/week, etc, which could then be pieced together for a journal of sorts…
so how many times he performed an actual task (chopped wood), when he sat down to eat, when he turned in for the night… all things that would actually be visible to the player…
Sounds like useless stats. I love useless stats. We could have graphs, too. Draw conclusions by simply plotting the chopped wood and happiness data into the same graph. Yes.
Should be doable, all in all. I’m not sure if it’s easily doable as an independent mod, however, since it would require encapsulating the actions.
I didn’t mean for that specific thing to be used for logs, just as a pattern since it is basically a barebones lua to js service. It contains near everything you could want for it, scrolling and infinite history would be trivial at worst from the HTML side. All you’d need to do is copy it and change the name and output.
As for logging if we could include goto’s then a heat map of resource and villager distribution could be interesting. The catch would be how much that level of logging slows things down, might be faster if you just collected data than outputted it in a special format at regular intervals. We would even be able to do replays with it.
Ah, alright. But as I’ve said, this is probably tracing. I would prefer something like GMod has (or had) though, basically just a huge text area. The console has no priority right now though; first I want to make sizable workers flexible (using the same approach as spawn stuff). After that, I’ll properly document RP so it becomes easier to use for others. At least manifests and the basic RP functions should be documented in some way.
And then it’s time to release 1402. And wait for bug reports. Probably have to fix @SteveAdamo on the way there, too.
The best thing would be some periodical snapshotting I think, i.e. every five seconds you quickly gather the location of all workers and then store their locations somewhere. Of course, just collecting the data would be the way to go.
The problem is that lua does not support threading, so we can’t just have some sort of “background logging” going on. It’s going to be tricky to find a way to log all these things but when the time comes I’m sure we’ll manage.