Stroam

Do you prefer the aesthetics of shop keepers or VS punk vending machines?

So you don't want the time player play to get in the way of trading but you want where the players are in the game world to be a factor. Any other conditions you want considered?

Does it have to be a chest? There's two issues I have with the chest. The first one is the minor thing that it doesn't feel immersive. The second and more important issue is that a player has to travel to the chest. To fix these, instead of a chest, what if a beacon could be acquired in game. This could be bought from a trader, or a broken one can be found in ruins that can be repaired with a temporal gear. Be as creative as you want. When this beacon is placed, a special type of traveling trader called an Auctioneer, will spawn within an ingame week replacing the beacon. When interacting with an Auctioneer you can view all the trades by everyone. You can also post a trade and the Auctioneer will hold onto the items. When a buyer wants to complete a trade they give the requested items to an Auctioneer after a certain amount of time passes based off the distance between the two traders, each person will be able to receive their items from the Auctioneer. If that's not immersive enough, to keep the Auctioneer from despawning they will have a food reserve that can be filled up by giving them food. If their food reserve ever runs out they will despawn. In addition, they will charge a nominal fee on every trade posted and accepted to cover "Travel costs and guild fees". Even without the additional immersion, it solves, my original two issues.

How would the climate rings be laid out? Starting with the center and moving out it'd be: Poisonous acid lake Hot desert Hot semi-arid Savanna Mediterranean Tropical Oceanic Humid continental climate Subartic Tundra Ice cap Dry Ice edge Some of these would have sharper transitions, regional variants, some might be missing or might not get added. It would be based on game play and game assets. If two regions don't look very different and play the same they might be combined or if there's enough conflict to justify more climates that would get split. Remember VS doesn't have climates in the since that MC does but has a range of attributes that determines what grows and spawns.

I've looked into worldgen from time to time changing my opinions as I went. I've now changed m mind yet again. I've wanted world wrapping where if one goes off one side of the map they come back on another. I wanted this to limit spread of players, make world generation easier, and balance out travel distances such that someone at the center of the map didn't have and advantage over others. Then I looked at the technical hurdles and decided that both north to south wrapping and east to west wrapping was not worth the time spent on the technical hurdles that happened at the corners. So I decided just east to west wrapping was fine and that the north pole and south pole could just go on forever. Then I studied the rationals behind flat earthers and other fantasy maps with a world edge. I thought about the gains to the gameplay of playing on such maps. I made the following list for what I was looking for. A variety of climates so as to provide enough diversity for player enjoyment Some sort of game logic that determines placement of the climates that players can understand. A map where the center is not an advantage. Resources tend to be clumped and not near each other to encourage diversity and trade. Encourages a variety of travel methods After all my research and considerations I came upon the notion that we don't need world wrap to make the center not an advantage. As obvious as it may sound, it took me a long time to come to the conclusion that by making the center a place one would not want to make a base it solves the issue without world wrap. This idea brought me back to the eyeball planet. There's several issues with the eyeball planet but it does tick all the items in the list which is why I think it's a good candidate. Just need to solve some of it's issues first. First issue is which should the hot or cold end be the center. If you look at several fantasy maps with edges, many of them have the outside being very cold. This makes sense for a couple of reasons but really we only need the most basic. If you place something hot on the ground you instinctively know the closer you get the more you feel the warmth. Then comes the issue of on an eye ball world the sun is always in the same place in the sky. This creates two issues. The light level is always constant in an area, and it means no season. To fix one part of this, just like the earth has a tilt the eyeball planet needs to wobble. The wobble causes changes in temperature and therefore weather and seasons. For the day night cycle we'll have to get more creative. If you've ever been to a point on the earth where it feels like the earth wobbles like the far north, during the summer the sun goes up in the sky and then behind the horizon but it never gets dark. At midnight it's like morning or evening when the sun is out of sight but you can still see light coming over the horizon. Conversely, during the winter it barely peaks over the horizon before going back down into darkness. Lets look at this from a gameplay perspective. It means at the edge of the map it'll be perpetual darkness and at the center it'll always be day. In between the closer you are to the center the ratio of day to night will skew more in favor of the day and the further from the center the more it'll skew to the dark. This can actually play to the games advantage by allowing the player to choose how often they want to deal with the dark.

You probably already have your answer but for future reference any world will use all mods currently enabled upon startup. The mods need not be present upon world creation unless they change worldgen or mob spawning like the Neolithic mod.

I have come across vast bodies of water that go as far as the game will render. However they are always ultimately circled by land rather than the other way round though I don't see that as an issue.

I think at some of these ideas were already on the forums some where and if not not they should have been.

``` I've been itching to implement some sort of "stat modifier or character buff/debuff" system, which could then also display currently hidden information. The comprehensive but complex and work intensive way would be to do it minecraft style and add such stat modifier support to all the characters subsystems. The simple way, less elegant, less inter-mod supportable yet much easier to implement would be to have the stat modifiers display detached from their actual modifications, i.e. player.ShowStatModification("+25% intelligence"); and let mods handle the actual stat modification for the former we'd also need to come up with a decent data structure for it so I'm looking for inputs from fellow modders and game devs The latter would also run at much greater performance, although performance impact should not exceed 1-4% in either solution ``` Assumptions stats are a base number modified by a percentage. both base number and percentage can be changed. changes to the base and percentages are additive such that +5 & +5% are canceled by -5 & -5%. My thoughts - Have each part do one thing that it does very well -Need to keep track of total for base and modifier. This is per stat. Sum storage Data Int base modifier Int percent modifier Methods edit base modifier edit percent modifier get base sum get percent sum broadcast base sum change - tells the new sum broadcast modifier sum change - tells the new sum Sum storage needs a record keeper for reporting. This helps in debugging. This is per stat. Record keeper Data Sum Storage Hash table to store record ID - is generated by the record keeper base modification change amount percent modification change amount Methods add record - returns record ID remove record - requires effect ID get all current records get base sum - from Sum Storage get percent sum - from Sum Storage get value (base * modifier) broadcast base sum change - from Sum Storage broadcast modifier sum change - from Sum Storage There needs to be a stat manager. The stat managers jobs are to make additional record keepers for each new stat registered, make sure there's only one record keeper per stat, relay information between the record keepers and everything else. Stat manager data hast table of record keepers hash table of manager records mod ID affect name affect description list of stat changed paired with record ID received from Record Keepers. methods Apply affect inputs mod ID affect name affect description list of stat modification - if listed stat does not exist, creates new record keeper to keep track of it. stat name stat base change amount stat percent change amount returns affect ID - generated by stat manager remove effect get all applied affects - returns all the names paired with affect ID get affect description get affect stat changes get all stat values get all stat base sums get all stat percent sums get stat value get stat base sum get stat percent sum get stat records broadcast stat base sum change - from Sum Storage broadcast stat modifier sum change - from Sum Storage I'm sure that I'm missing some and and I'm sure the broadcasts need to trigger other broad casts. The time keepers are utility functions since many effects are based on timers. There are two time keepers. One with a VS world clock and one with a real time clock. A time keeper is given a value and gives a timer ID back. When the time is up it then broadcasts that ID. Time keepers are independent from stats since they can be used for many things other than stats. There is no remove timer. Timers are automatically removed and if you don't care about that timer anymore then ignore the timer ID in the broadcast. The time keeper data storage - updates every item every tick time left timer ID methods add timer get all timers broadcast timer ID - each time a timer expires it broadcasts timer ID ```"stat modifier or character buff/debuff" system, which could then also display currently hidden information.``` For the actual displaying, I would add a separate system that works by listening to the broadcasts and then requesting the information needing to be displayed.

Please post your wiki username to be granted wiki edit rights.

It keeps the current tech progression. The only need for solid Rock is the quern and I wouldn't delay the quern further than it is. I don't have an answer for stake durability.

They used to split boulders by pounding a bunch of holes in a line, sticking dry sticks in them, and then pouring water so the sticks swelled and split the rock along the line. For game balancing though might go with the similar process of using metal stakes and a hammer.

I agree that perhaps a specific set of tools should be used for this. The tribute to TFC is nice but one thing TFC suffered from was none of the mechanics having anything in common so it was impossible to guess how one might do something and one would have to resort to looking everything up.

This would be an excellent small project for someone who is interested in modding the game.

How is this not a thing yet? It must have been an oversight and not added to the configs yet. You should add it as an issue on this github. https://github.com/anegostudios/VintageStory-Issues