There are a few things that modders still need. As we approach the last versions, this is the time to ask for it!
Let’s organize all our requests here!
There are a few things that modders still need. As we approach the last versions, this is the time to ask for it!
Let’s organize all our requests here!
Edit: this got implemented
I already had a few requests floating around, but here are a few that would help me:
We can’t mod the first menus screens when creating a new game in a controlled way. For example, I can’t customize the menus based on if the Archipelago biome was picked, because changing those menus would change for everyone, even when other biomes are picked.
So my idea is to add in the root of those menus a few css classes, representing options picked in previous menus, like biome, kingdom, difficult, etc. This way, I can create a css file and customize the menu for only when the correct biome is picked. Or someone could go with a very monster-like theme if the player picked the hard difficult, or a simple theme adaptation based on the kingdom.
Here an example:
To achieve the above effect, I overwrite the js file to add the css based on the biome chosen:
self.$('#selectSettlement').addClass(biome_name);
self.$('.bullet').addClass(biome_name);
Then I also have a css file targeting a “archipelago” class. This way, if the player pick the biome, the icons get customized, else it keeps the defaults.
Doing this without having to overwrite the js would be nice
Let’s link this one here I guess: Technical suggestion about entity tags (material_tags)
Edit: this got implemented
The water level is hardcoded. Changing it to be customized by json would be nice too.
I remember Allie showed us a sketch of the arctic biome she draw where it had a big ice cliff into the water, that would only be possible changing this value.
@BrunoSupremo Oh man, I’m imagining a beach biome where the water level is set to 0.01 below the beach level, and then the daily cycle includes screen-edge additions and removals of wet/dry stones at key times to flood/drain the beach. It would probably have performance issues, but it would be really cool!
Oh, great thread. Just noticed it
Well, I posted something along these lines just now, so I’ll paste a link here:
I have a few ideas I would like to use myself, but I don’t know enough to successfully code them…
A service to switch between two models ingame:
Second idea is a service to give worth to an entity over time:
I suppose it’s a long shot for some of those, and I don’t know what is already available, but:
void registerLua(lua_State*)
would be called in the DLL).radiant.call
into either side of the game (via an API of some kind).ent:get_component('animation'):set_frame(12)
)ent:get_component('rig'):set_bone_rotation('post', Quaternion.Euler(0, 90, 0))
)Originally posted in the minor polishes thread, but I think it probably belongs here:
I remember there being a post about this from a while ago, but I was unable to find it. In addition to specifying a mod as “clientOnly” I’d like to be able to specify “serverOnly”. This would, when checking the client’s mod list against the server’s mod list, force the user to disable any mods specified as “serverOnly” that the server isn’t running. All three of my UI mods fail when the server doesn’t have them loaded (because they rely on server mixins/overrides), but because they’re primarily UI/UX mods, I don’t want to force users to use them just because the server is using them - they don’t affect actual game content.
This is a good one to do if we’re not getting access. I feel like this is one of the few things that would be an immense help if fixed up. Good thinking man !
12 posts were split to a new topic: Seasons: What Do They Do? Do They Do Things? Let’s Find Out!
I am still hopeful that there will be some universal way to identify the mod recipes / items originate from. This could be an icon that is called or even a simple mouseover that calls the mod name.
I bet there’s a super hacky way to do that with radiant.get_mod_list()
, radiant.load_manifest(...)
, and radiant.load_json(...)
to process through and try to find where something originated, but I agree that it would be nice to have things tagged with the mod name (and then you can look up the mod to get more detailed information about it). At that point it would be relatively trivial to add that information to tooltips, etc.
Here are some thoughts from my own modding experience that would make it easier for me to avoid monkey patching or large workarounds.
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.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.
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({
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 ])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:
It would be really useful for Template creators if the Template menu had some sort of categories or file architecture.
So for example you would have a list of parent categories such as:
Then selecting each name would expand the list of templates nested within. You could organise this list and what goes where via the mod menu so that even templates that are created by players in the game can be neatly stored away in the templates menu.
I mean, pretty please if we’re making requests
In general, I think there will be a vast amount of mods adding variants of existing things like furniture, windows, classes, templates etc. so ways to organise that vast amount of things would be much appreciated.
EDIT: I think it wouldn’t hurt anyone if the starting crop list JSON was reformatted a bit to allow specifying starting crops based on biome as well as kingdom, I’ve already made a mod making it possible and all it involves is slightly expanding one function in the farming service: biome_crops_mod.smod (3.2 KB)
There is an issue with traits which effect hearthling appearance, where the appearance changes do not get applied correctly when the hearthlings are created in the embark/new game screen.
Currently there is only one trait in the base game that does this and I believe this is why the magnificent beard trait is the only trait in the base game that cannot be obtained when embarking, only from new hearthlings joining the town. This will also effect any trait added by mods which effects appearance (shameless plug)
My hypothesis is that when a hearthling is created, its appearance is first randomized and then it’s traits are applied. However, when hearthlings are randomized in the embark window (but interestingly, now when they are first created even in the embark window) their traits are randomized and then their appearance is randomized. This has the effect of undoing any appearance changes made by traits.
If this does not get fixed, then if anyone finds a work around to this I would be very excited. Perhaps by having a handler that triggers when appearance is modified, which can immediately set it back? (although this could cause an infinite loop if two traits both affect the same element…)
Adding to @kaimonkey, more control over traits as a whole would be amazing!
Right now we have the “immigrant_only” tag but I’d love to see something like being able to specify traits by Kingdom, by Roles (inside kingdom) and some sort of trait “percentage” factor so we could have super rare traits or - alternatively - a common trait of sorts (100%) to certain kingdoms and such.