Requests from modders to devs for 1.0 and 1.1

[paulthegreat]

Here are some thoughts from my own modding experience that would make it easier for me to avoid monkey patching or large workarounds.

• InsertCraftOrder (adds a button to the workshop view that calls a lua function to insert the new craft order at the top of the list instead of at the bottom):
  • if craft_order_list.add_order (or ideally, add_order_command) returned the order that it created, I would use existing functions to add the order and then move it to the top of the list, rather than monkey patching my own insert_order function into it. Yeah, I could use existing functions without that, but I’d still have to muck around with the order list’s saved variables, and that doesn’t feel good. I imagine there are many other similar places in the codebase where returning created objects would make it simpler to mod.
  • or in this particular case, even just an optional parameter to add_order (and add_order_command while you’re at it) to specify the index would greatly simplify it and could allow for other cool functionality to be modded in, like dragging an item from somewhere directly into a position in the craft order list and creating the order there.
  • the other issue with this mod is that the base game’s App.StonehearthTeamCrafterView is loaded so late and takes so long to load that my mod gets loaded before it! That’s right, we’re not just talking about my mod being loaded before other mods, we’re talking about the Javascript for it being run before the Javascript initializing the base game’s App views has finished! This is the start of my show_team_workshop.js; I originally had it set to a static delay of 1000ms, but that could still fail on slower computers so I added the repeating check (and my unit frame mod works just fine reopening App.StonehearthUnitFrameView without a delay):

$(document).ready(function () {
    var _tryReopening_StonehearthTeamCrafterView = function () {
        if (!App.StonehearthTeamCrafterView) {
            Ember.run.later(this, _tryReopening_StonehearthTeamCrafterView, 100);
            return;
        }

        App.StonehearthTeamCrafterView.reopen({

• UnitFramePlus (enhances the unit frame, primarily with extra buttons to simplify common tasks):
  • this mod is a bit of a mess because it’s my first major mod attempt (before that I was just making personal modifications to @Gruffus’s Town Monitor mod, some of which made their way into my latest Obligation/Timer Tracker mod in a much better way).
  • in order to add UI functionality in the simple/proper way, I have to mixinto some jsons to add a command to hearthlings (to show the promotion tree). This is a very smooth process, but requires the server to handle things that ultimately only affect the client (since the command being added is just to give easier access to client functionality).
  • toggling the “job” activity for hearthlings was pretty straightforward; the tricky part was monitoring when it changed for party members when you had that party selected, so that the UI could properly reflect that change. There are two parts to this that bear mentioning:
    • I had to (or thought I had to) override the entire components property of the view in order to add the bits I cared about. Information about using App.[View].reopen(...) effectively would be very helpful for UI modders. (Can components and other view properties like it be modified at run-time? [don’t get pedantic about “run-time,” you know what I mean ])
    • I still don’t know how to observe changes to the selected party’s members (not changes to the membership of the party, but changes to the actual members themselves). My solution is terrible, but it works: if you select a party, until you change your selection a timer will check the party members every 100ms to see if the property I’m interested in has changed from its cached version; if so, it updates the UI. A potential “proper” solution would be to create a sub-view that tracks individual party members and then observes changes and passes the message back up to the main view, like how the Citizens view does it, but that seemed like overkill and probably lower actual efficiency than my stupid way.
• Obligation/Timer Tracker (gives a simple UI way for viewing, interacting with, and automating common timer-based tasks like consumables):
  • tracking timers is not something that’s easily done currently (e.g., when is a timer created and for/by what controller/service) and would take a big rework to change I’m sure, so my service has to hack into lots of things. Hopefully my next addition, things that show up in the alerts view like trade agreements and goblin demands, will be a little easier to access.
  • I imagine there are a lot of limits on what could be exposed with the time tracker for performance reasons; similarly for the event system, which is what I would normally hope would get used more thoroughly like in .NET or other OO languages/frameworks. I guess I don’t have specific requests here, just wishes that the OO principles I’m familiar with could be used more effectively.
  • one of the biggest things I struggle with actually is HTML/CSS. I have no background in web development, and I get frustrated trying to figure out the exact combination of seemingly arbitrary tags that will get my UI elements to render somewhat close to how I envisioned. In this mod I have a div of the class “stupidContainer” that I don’t think I should need, but somehow prevents a grandchild component from spilling outside of a child component. I also had a heck of a time getting jQuery draggable to work, and ultimately had to counter-intuitively not include the handle parameter for it to function.

I guess my biggest modding requests are things that are probably already being worked on:

• at the very least basic guides for how to create and modify Stonehearth-style Ember views including how to reference core/mod assets of all types in the different platforms (JS/HTML/CSS and Lua)
• maybe take a single complex Ember view and its associated Lua references and really break it down and comment the heck out of it: what are these parts trying to achieve and why do they go about it this way?
• and of course a complete MSDN-style object model reference, most of which can be auto-generated with scripts, but then maybe it can be transformed into a wiki or something so that ultimately the modders can flesh it out more and things like “related articles” and examples can help modders quickly locate the information they need.