WishIhad? Lovetohave? At least that is what I think when I’m missing decos or furniture in vanila.
Have fun, Kyth.
I’m splitting the Plant Lore into separate components and I’m not sure if I should make vanilla planters (window boxes) and their counterparts harvestable for herbs and fiber. This would make them more functional and I think we like functional elements. Plant Lore planters producing plant specimen will stay in place, I’m also planning working on them a bit more.
Should decorative planters be harvestable?
- YES: decorative planters should be harvestable and yield corresponding resources
- YES: decorative planters should be harvestable and yield plant specimen
- NO: decorative planters should not be harvestable
0 voters
After some consideration… I think I like it. How about the logo?
4 Likes
OK, so my exams are over (at least for now, this exam session was a true horror so I am mentally prepared for a sequel). Now it’s time to work on updating my mods for A23. The order I planned:
- creating window & door margin removal mod for A23,
- porting new vanilla-style items from Finetems to Lost’Ems,
- updating and splitting Plant Lore crops and Herbalist-maintained planters into two separate mods, probably adding some new planters as well,
- finishing my so far unreleased garden items mod which was planned as a part of Plant Lore,
- sitting down to Archmod (this will take some time).
probably also: 6. creating A23 doorway mod because doors got a revamp in A23 and jomaxro’s doorways are no longer fitting the vanilla ones.
Also: I have to rethink the way plant resources and plant specimen are handled because there is no way to make plant specimen undeployable and usable in recipes at the same time without running into severe issues. The mechanism I introduced in Plant Lore was a bit chaotic. An optimal way requiring extensive coding would be to allow Herbalists to simply uproot crops in their pre-final stage, yielding specimen which are not ready for harvest yet.
8 Likes
Guys, an important update. Take a look at this:
http://www.stonehearth.net/release-notes-789/
Needless to write Plant Lore porting progress is stopped for now. As far as I tested all A23 mods work fine on the latest unstable A24.
3 Likes
HA! Thanks. Is it that bad that I thought that was just something I had missed in the A23 stable release. I really should pay more attention. I do love the seeds though. Unfortunately I get to about 23 hearthlings and my lua sits at around 60+ %…and the hearthlings loose their minds.
After some consideration I decided to make a pivotal change in my modding approach for SH. Instead of improving the vanilla content which undergoes constant fluctuations I decided to focus on adding original new content:
- all the A22 mods will not be updated for A23 if they haven’t been updated yet (if you have any particular feature you’d like me to port don’t hesitate to write here though, I may have forgotten about something smaller but useful - I just don’t want to waste time porting things people do not find valuable);
- Plant Lore becomes discontinued except for the technical functionalities (Autoharvest and Biome Crops) because of the upcoming A24 plant interaction changes;
- much like @BrunoSupremo I’ll launch my own biome mods; they will be focused on representing realistic environments with non-fictional fauna and flora;
- I’ll try my best to provide functional seasons mod (this was already started) but providing support for existing biomes may be painful so it will start as a feature extension of my upcoming biome mods;
- Cartesian kingdom is slowly becoming a reality. The first iteration won’t feature much except new graphics and reworked class tree. Goodbye, Mr Cleric.
These require a lot of work and I need to learn some new stuff (UI, animations). Don’t expect them to be released anytime soon.
4 Likes
Before the huge stuff though: an intended part of Plant Lore I started working on in A23 and which is quite advanced and I will probably release it were detailed flower models. Here’s a little example of what I mean:
Flower models normally use scale of 0.2, so I multiplied their models by 5, added details and shrunk their in-game scale to 0.04. The result is 1 Qubicle model voxel is 0.4 in-game voxels so more subtle details are possible.
5 Likes
Looks great ^.-
Guys, a little poll. What big project should I focus on next?
- cooking mod
- weather and seasons mod
- new biome mod
- new kingdom mod
0 voters
I thought you may like this little teaser… (purple is of course the technical colour because the hair material map uses it)
6 Likes
I Voted for cooking because a game need (i think) rebalance food quality and enter a food buffs
2 Likes
Food buffs would be the hardest part together with maturing foods. With the new container filters I think I found a way to automatically fill wells with water buckets so it is no longer necessary to order Lings to collect water. I’ll also experiment with liquids being stored as stacks like coins so they take less inventory space.
Just threw this error - not sure what it’s trying to do:
release-784 (x64)[M]
…rce_node/pawel_renewable_resource_node_component.lua:286: attempt to index a nil value
stack traceback:
radiant/modules/commons.lua:46: in function 'report_traceback’
radiant/modules/commons.lua:57: in function <radiant/modules/commons.lua:51>
…rce_node/pawel_renewable_resource_node_component.lua:286: in function ‘spawn_resource’
…rce_node/pawel_renewable_resource_node_component.lua:179: in function ‘renew’
…_resource_node/renewable_resource_node_component.lua:264: in function '_fn’
radiant/controllers/timer_controller.lua:95: in function 'fire’
radiant/controllers/time_tracker_controller.lua:86: in function <radiant/controllers/time_tracker_controller.lua:86>
[C]: in function 'xpcall’
radiant/modules/commons.lua:66: in function 'xpcall’
radiant/controllers/time_tracker_controller.lua:86: in function ‘set_now’
…hearth/services/server/calendar/calendar_service.lua:422: in function ‘_on_event_loop’
…hearth/services/server/calendar/calendar_service.lua:46: in function 'instance’
radiant/modules/events.lua:291: in function <radiant/modules/events.lua:285>
[C]: in function 'xpcall’
radiant/modules/commons.lua:66: in function 'xpcall’
radiant/modules/events.lua:285: in function 'trigger’
radiant/modules/events.lua:398: in function '_trigger_gameloop’
radiant/modules/events.lua:446: in function '_update’
radiant/server.lua:62: in function <radiant/server.lua:59>
1 Like
I just found a case when the code is a bit nonsense but it is unlikely to be the source of this error. In line 286 I ask to set a saved variable in autoharvest component whenever RRN spawns a resource but at the same time I prevent autoharvest component from being created if RRN is set to spawn resources immediately after renewal in line 179. This results in attempting to index a nil value whenever a spawn_resource_immediately RRN entity is created.
@Auryanna: this has the above issue fixed (checks if autoharvest component exists before attempting to index the value), but I don’t expect it to fix the error you posted (unless you have some RRN spawning resources immediately in your game) so please try it and report back if it worked: autoharvest_mod.smod (25.8 KB)
Weather is kinda tricky. I know I need to have temperature and humidity for my new crop growth system (so they grow faster when humidity is high and temperature is optimal for specific crop/plant and don’t grow at all when there’s severe drought or harsh winter; when daytime length varying over the year is implemented it will take it into account as well). The problem is whether they should vary and determine the weather or the weather should determine their values. While the first seems more accurate the latter would be easier to code:
- clear sky: humidity drops, temperature rises at day and drops at night
- cloudy: conditions return to average values, temperature doesn’t drop at night
- rainy: humidity rises, temperature drops at day
- snowy: humidity drops, temperature drops at day
Probability to have certain weather condition would be affected by season and snowfall would replace rain if temperatures drop below water freezing point and vice versa. Such a design allows to skip wind/air pressure in the calculations because their changes are represented by weather condition (which would have to fit air pressure if atmospheric parameters were dictating weather, what would significantly complicate the system).
Below is the Markov model scheme I have planned for weather determination. No factors included because they are not constant. I don’t know if it should be possible for rainy/snowy state to return to cloudy.
Another issue is visual representation. Clear sky disables cloud rendering, cloudy/rainy/snowy enable them but for rain and snow I think I’d need some cubemitters at least imitating raindrops/snowflakes.
@BrunoSupremo: would I be allowed to copy the mist over water from Swamp Biome for this mod so I can enable it under certain conditions (high humidity, temperature between certain values)?
6 Likes
The mist is just the undead crypt effect with a different color.
2 Likes
Currently, an in-game month has 30 days. Fortunately the game doesn’t use the concept of a week, so it is quite possible to shorten months substantially. @BrunoSupremo’s season mod (currently on hiatus) offers an option to change seasons more frequently by making them shorter (1 month per season instead of 3, what gives 30 days instead of 90 with 4 seasons per annual cycle) what is a brilliant idea because it is possible to experience all seasons in one game.
Now, when I look at the speed at which crops grow and buildings are built, the concept of SH time seems a bit odd, I rarely play one game lasting longer than a year and it takes less than a year to construct a gigantic castle and a city around it.
The Hearth planet is not the Earth anyway because the year as of now has 360 days and all month have 30. If we assume the star around which the Hearth orbits is significantly smaller than the Sun and the Hearth’s orbit radius is also smaller than the Earth’s, it would be possible to make the year shorter without any further consequences.
Therefore I think the best solution, instead of stuffing several annual cycles into one year, would be to make months shorter: 10 days instead of 30. It would also make code much simpler, because instead of worrying which variant of the annual cycle the user chooses and adjusting the (already somewhat complicated because of the varying daytime length) calculations the whole problem would be reduced to changing one time constant (days_per_month to 10).
Now, because I would rather work on the weather system and variable daytime length/weather conditions rendering the first versions of the mod will feature the 10 days per month solution. The question is: should it be changed in the future?
- keep one cycle per year, make months shorter
- keep month length, fit several annual cycles in one year
0 voters
Thing which must be set constant in the mod is the number of months per year (in this case 12) because it would be impossible to distribute seasons evenly if there were like 7 or 13 (prime numbers, yuk!) months per year and the code would be much, much more complicated if it was subject to change.
2 Likes
Meanwhile, there was some significant Archmod progress. I hope placing items on top of other will work well because I’d like to have modular columns so their height can be changed just by stacking modules.
22 Likes
Beautiful 