The mod does not work on A22.5 just because it’s more work to get it compatible with multiple versions. I am still unable to reproduce the error people are getting after the Achernar dialogue, but I’ve uploaded a version without the animations that might work for you:
https://drive.google.com/file/d/1QcL6b21RJQYxKF7JFlM_AUaf0t44A1cJ/view?usp=sharing
1 Like
Anyone having an issue with using the Vapour Rub? Every time I try I get this
release-771 (x64)[M]
No matching overload found, candidates: luabind::object require_script(ScriptHost&,std::string const&)
stack traceback:
[C]: ?
[C]: in function 'require_script’
radiant/modules/mods.lua:11: in function 'load_script’
stonehearth/ai/lib/consumables_lib.lua:20: in function 'use_consumable’
stonehearth/call_handlers/resource_call_handler.lua:255: in function <stonehearth/call_handlers/resource_call_handler.lua:254>
release-771 (x64)[M]
c++ exception: lua runtime error
stack traceback:
On the other thread I attached my savegame right before the crash event and I could trigger it everytime I played that save. @max99x Did that not help find the error?
Will this be coming for this year again?
please say yes 
5 Likes
+1
4 Likes
yes ,please
I don’t plan on continuing modding Stonehearth, and Froggy has been a bit MIA lately, so I’ll guess it’s a no from him as well. Like last year, we have no plans to update or continue Frostfeast.
I also don’t think Radiant is going to fix/update it (if it is broken, I can’t really tell), so it’s up to somebody else.
2 Likes
I take it you wouldn’t mind if someone else did though?(Mod ownership and all that?)
1 Like
Personally, I don’t think that one modding ownership rule is going to be enforced anymore, and if it is, it certainly isn’t going to be in two months. But on these specific terms, Frostfeast was meant to be a community mod, and as an “official” holiday mod, I don’t think I or Froggy can claim ownership of it per se.
It’s fair to say that I’m disappointed how Frostfeast overall turned out, compared to what was planned, so my disappointment should be containable even if - worst case scenario - somebody else picks it up and butchers it.
For a pure, functional update to make sure it works anymore, I would appreciate it, so go ahead. Adding features, changing mechanics, and all that is a bit wonky though. I’m not going to forbid it, nor can I really, but I would like to see Frostfeast continue in the direction that it was heading.
2 Likes
Do you have any shareable notes on original concepts, plans that didn’t make it, etc? 
Core concept
The idea of Frostfeast was always a bit two-sided. On one hand, we wanted to have a jolly, nice festive mod that allows you to play around, decorate your town, and generally enjoy the festive, albeit chilly, time of the year. However, I always wanted it to be a bit challenging, but not in the way Stonehearth did it back then with scenarios/campaigns, which was basically just “Let’s throw stronger enemies at you until the village collapses or the scenario runs out of ideas”. So the two core concepts were:
- Lights! Festive! Jolly!
- A tad difficult and a constant battle against the environment
The latter shouldn’t be deadly though, or really difficult, but it should tie-in into both things. As in: By making things pretty and cheery, you’re also battling the environment. That’s how heat sources were born. You can avoid having your hearthlings freeze to death by putting up lights/braziers, making winter clothing and so forth. As a gameplay rule of thumb, things that give off heat should be “logical”, and the balancing is kind of made in a way of utilization: A chimney will give off loots of heat, a brazier will give you barely enough to stay warm. Because the first one is something you’ll head to to get warm again, the latter is just something you use to stop being cold. I think this is the most important aspect of Frostfeast: It should be a challenge, but a different one from the normal game. It should be cute, it should be festive, but it shouldn’t (necessarily) be a sandbox bit, because winter’s still dangerous.
Frostfeast itself had a lore, and I don’t know if it was ever published. The monument itself basically tells it in a visual way. I don’t know if I’m allowed to just paste the story here, or re-tell it, but the basic premise was a “christmas miracle” with people being saved from the cold. We’ve tried to tie the cultists into this whole thing by making them the baddies, by offering a - completely optional - challenge against them. You had all incentives to join them, but you’d face repercussions (mainly, it’s getting colder. A lot colder). Basically, the cultists want to summon their ice deity/monster/notquitedefinedyet, and by sacrificing gifts to them (instead of giving them to the CoP), you’re making the world a worse place and help them do just that. Basically, the monster feeds on non-festiveness. Later on, we wanted to have a titan-like battle against just this monster, in a way to tell you that “Well, that’s what you get for helping the bad guys”. We wanted to wait with that until titans were effectively implemented, so it didn’t make the cut for FF16.
GitHub Issues
These are the open issues from the repository, which includes ideas, bugs and other things from FF15 and FF16. Not all of them are 100% serious (I’m sure you’ll find out which ones aren’t), and not all of them are doable. It was a mix of “what could we do, reasonably” and “what could we do, maybe if SH allows it”. Not all of them are good ideas, not all of them were fitting, but they were tracked to be evaluated/looked on when we got the time. We didn’t. The following is the (nowadays incomplete list).
Enhancement: Move the firepit_listener from the warming service to the heat source
Currently, the warming service is listening to events to turn the heat source on/off. This is something the heat source should do itself, rather than abusing the warming service for it.
Ideally, the heat source should say whether it’s controlled by that or not. Currently, this is mandatory for all firepits.
Bug: First log put into firepit is taken out again and put into stockpiles
[insert x files theme song]
apparently only happens on the first log and the very first stockpile…
Idea: When warmth reaches a certain value, freeze the hearthling in a block of ice
If the warmth drops below a certain threshold for too long, the hearthling is encased in a block of ice and needs to be rescued by others (items like hot chocolate, maybe thawed by (special?) heat sources, or similar).
Could-have: Evaluate decay values for prepared food and jerky
So far, we’re only changing the decay values for decaying food itself, not for prepared food or jerky which has different values. Find out if/how we should adjust these values - and maybe if Frostfeast food should decay even slower. Note that with this year’s SH, we cannot adjust the rate of the decay anymore (it seems), but set an initial value.
Idea: Find some excuse to add Mexican Armadas #63
brad [11:19]
I’m good with including a Mexican Armada
Idea: Attachments
As discussed in the Slack, and already pitched as idea in 2015, it would be nice if entities could be “upgraded” with other entities.
Examples of such upgrades:
- Trees could be upgraded with lights to become frostfeast trees
- Windows could get shutters
- Doors, Windows could get decoration
Things to keep in mind:
- An entity should be able to define what kind of attachment to receive (i.e. attachments have some sort of type)
- An entity can receive multiple, different attachments
- An entity can define attachments to be mutually exclusive (i.e. you can have either
window_attachment_large,window_attachment_mediumorwindow_attachment_all, but not two or more). - Attachments should have some control over this too; maybe attacher and attachee can have some sort of whitelist/blacklist to define where they can be placed, in addition to the tagging.
- Attachments can define one or more tags that they identify as.
- The AI needs to have actions to perform this kind of thing; which isn’t a big deal, except I have no real idea how the whole scaffolding stuff works (yet).
Idea: Trojan Presento
During the encounter with the goblins, there might be a chance that they offer you a present, which can be denied. If accepted, the goblins will (peacefully) deliver a present to the edge of your town, where it can be picked up and placed somewhere. It’s a huge present, something that the player would definitely want to place somewhere central.
If placed, every few hours during the night the present will try to see if it enough hearthlings are asleep. If they are, the present will open (in a cartoon-style approach by having each wall “falling to the side” one by one), revealing a goblin raid troop inside with a few members (maybe 2-5, depending on settlement size). They head for valuable loot inside of crates/stockpiles, pick up some, and rush back to the goblin camp. If they are successful (present was accepted and opened, at least one unit made it back alive), the encounter repeats (with a nice “Sorry for last time, this time the present is empty, I promise” message).
This mechanic is totally abusable as some sort of training/hunting ground for clever players.
Concept
- Goblins offer players an oversized present, which is actually a trojan horse
- If accepted, the present spawns a goblin raid troop.
- If the raid troop is successful, the encounter will be repeated.
- If the raid troop is unsuccessful, the encounter will not be repeated, or only after a very long time.
- If the present is denied, the present will not be offered again.
To consider
- Visible building of the present in the camp: Can we get the goblins to “build” the present and show how a few units walk in?
Idea: Adding breathing effect to other units (such as critters)
Consider if the breathing effect could be added to other units as well, such as critters (sheep, rabbits), enemies (goblins, whateverelsethereisIamreallyoutoftouchrightnow)…
Enhancement: Consider creating a popup about the content of the gifts
Create a bulletin of some sort that displays the content of the offering that was just offered. Player requested feature that sounds useful.
Idea: Have daytime and stamina affect warmth loss
Daytime and stamina could affect warmth loss:
- High stamina (or body) could reduce the warmth loss experienced
- During the day, less warmth is lost than during the night
Wire up frostfeast:admire_warmth_adjacent to stonehearth:freetime
It would be nice/useful if hearthlings could gather around special heat source (heaters, for example) like they do for firepits whenever they have nothing to do.
SH solves this with a few actions and an observer; this pattern would have to be copied.
Indicate heat sources
Players should know what is emitting heat and maybe to some extent how much too, otherwise the warmth mechanic might be reduced to firepits and braziers, although a lot more entities are emitting heat.
Make ice transparent
This actually dates back to 2015, including Chris’ answer:
Other things that I could think of right now
- We’re not supporting difficulties at all, or start parameters. it would be nice if maybe things like the heat simulation could be turned on/off in a setting, or maybe tied in to the difficulty (easy having no/very little cold, whereas hard would freeze your hearthlings to death within two seconds).
- All the features from 2017 and 2018 aren’t implemented in FF at all. FF17 was just a feature upgrade, with very little (I think) added in.
- The balancing for worth and appeal are probably a bit rushed and mostly outdated.
- With the introduction of rooms, chimneys and friends could be effectively changed to just heat the room, instead of a sphere. This could allow for more “realistic” heating mechanics.
- The story could be expanded a bit more. We wanted to have Jenna/the CoP physically walk into the camp some day, at least for major encounters (first time/“You’re helping the bad guys!”). Cultists could do this as well (“Hello, my name is”).
- Instead of just “eating” the presents, a CoP representative/cultist should come and pick it up. Not sure if we’re actually doing this, I feel like maybe? Cultists should throw it into their monument and then burn it.
- The goblins play just a minor role here. With the trojan presento, this would be expanded. Integrating them into the present battle would be bad, because two parties is already more than enough. But maybe they could also get a reason to exist? Maybe they want presents/decorations/whatever and if you don’t do it, they’ll declare war?
- Although I don’t think it makes sense, it might be worth investigating whether Frostfeast can be integrated into the seasonal stuff. Have the cold reign when it’s winter, and have the tree die when it becomes spring. Reset the event every year, or maybe take over some things (such as the reputation).
- Additionally, “inside” such as mines, etc. might also have different heating mechanics. Currently, they’re all treated the same.
- Now with weather, there’s also the possibility to tweak the heat/temperature using that.
- The AI in general could maybe become a bit smarter. When it’s snowing, they’d rather stay inside/next to a heat source inside somewhere. And so forth.
Most things are written down in the FF writeups I did in my RepeatFeed in December '15/'16.
7 Likes
Well speaking for myself, a functional heat system would be a cool thing to have, even outside of frost feast. Once that’s up to scratch for the latest version, the rest could be made to work (again) where needed afterwards, I guess?
4 Likes
Permission question:
[Presuming I could figure out how to do so]
May I use the cold / heat system for my Mars biomes?
Either directly as a temperature thing (Mars is largely quite cold), or altering it into an oxygen/air based system?
Sure, feel free to use the heat_source components/the heat service. Shouldn’t be difficult to adjust it to other systems (oxygen etc).
4 Likes
sounds interesting! unfortunately i haven’t it tested out in older SH versions but sounds like a really cool system!
1 Like
Basically, there’s a few parts to it if I remember correctly
- heat_source is a component that acts as “whatever is within my range is getting X warmth per second”. Optionally can be turned on/off, e.g. used with the firepit
- the heat/cold service is orchestrating stuff like “is the system active right now?” and “what heat sources exist” (for AI reasons)
- there’s an observer which monitors the heat of an unit and applies debuffs, buffs and forces it to seek heat if necessary
- a bunch of AI actions that deal with “find a heat source”, “go to a heat source” and “warm up”
2 Likes
That sounds like something kittyodoom would want to use for her mod, the oxygen thing. How do we ping her if she doesn’t already know?
1 Like
For future reference, you can use @[name] to ping someone, although since Kitty has replied to this thread she’d automatically be “watching” it and get a notification anyway 
But I agree, with RepeatPan’s permission to use this system I reckon the Mars mod is about to get a lot cooler – both figuratively and literally! After all, as Kitty mentioned the Mars biome would naturally be colder as well as oxygen-scarce, and I can see the two conditions having very interesting interplay to make building functional/efficient colonies a more interesting part of the game. I would guess (knowing virtually nothing about proper coding as I do) that the same service could monitor both temperature and oxygen if set up to track them independently; failing that it should certainly be possible to run two very similar copies of the service to track both (I’m not sure which would be more performance friendly, but I suspect the former would be more elegant and cheaper to run.)
Once again, a big thankyou to RepeatPan for being so generous with time and sharing resources to help newer modders carry the torch
3 Likes
It will require some tweaks, not sure if it’s a good idea though. On one hand, you certainly have performance impacts - however, I did try to write this whole thing with performance in mind. Heatsources, for example, use the sensor system that’s also used for doors to track entities, because I believe that this engine check is likely a lot faster than doing manual computations.
On the other hand, you get clearly, logically separated units of code that you can re-use later on, instead of a “one size doesn’t quite fit anyone”. At least the AI actions will need to be duplicated, although you might be able to do fancy stuff using inheritance.
The service (warming_service btw, just checked the code) is likely the least of your worries. There are some possible optimizations (e.g. passing the attributes/warmth component in instead of fetching them all the time), but I think it’s a drop in the ocean with all the other issues SH has. You should worry more about the AI actions and the observer, those are likely expensive things running each tick.
1 Like