Jump to content

Erik

Very Important Vintarian
  • Content Count

    198
  • Joined

  • Last visited

  • Days Won

    27

Erik last won the day on June 24

Erik had the most liked content!

Community Reputation

60 Excellent

About Erik

  • Rank
    Ironsmith

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. No, they wouldn't. Getting enough rocks or ore is not the problem, but building tunnels either for aesthetic purposes or to even get to said ore. I also don't see any gameplay reason for the chisel style mining, it doesn't offer any interesting challanges nor enables other interesting interactions in both Omegas original suggestion or AlteOgre's more refined one. I however like the "rubble" idea, think breaking stone would create gravel (which is effected by gravity) instead of dropping stone, which can be picked up with a shovel or destroyed by hand for stones. There would be a real gameplay effect with it which would balance the added grind and I feel it would be very fitting for the Wilderness Survival playstyle, however probably not the default one. I really, really like the "weak spot" idea. It doesn't make mining any more grindy, but even lets you mine faster (less grind) if you don't just blindly break blocks but pay some attention to where you are mining (more engaging). There could even be different types of weak spots to offer some diversity and player decision making: Break the block faster by hitting the crack or slower but have a chance to get a gem or nugget by hitting the glittering spot?
  2. While the breaking of the block may be solvable in the same time as before, the rubble and getting rid of it makes the whole process take a lot more time. Things that are already really grindy in the game, like quarrying for smooth stone, would become unbearable for most players. Mining efficiently for ore in Vintage Story is significantly different from what you describe, as prospecting above ground and looking for caves in or rich areas or digging straight down is the best way to mine, not building endlessly long tunnels underground.
  3. It is a sandbox survival game, not just a sandbox game. It should force you to do things. The default survival game mode should not have a completely skipable night imo, as it defeats a lot of the purpose of the night. Being just able to skip the night defeats the purpose of building up defenses, a simple fence and permanent light. It degrades the purpose of crafting armor. The bed is what ruined the Minecraft survival experience for a lot of people, as the game became too easy with it. And players can do things at night time, it's the best time to do the crafting and smelting, prepare food, decorate the interior of your base. Once a player crafted some basic wooden laminar armor, the night isn't even that scary anymore as drifters are not even a threat anymore. Quality of life features are generally a good thing, but this wouldn't be a quality of life thing, it would be a major gameplay change, that would also only effect single player. I'm however not against some world creation setting or mods that allow you to sleep through the night, this is just about the default survival mode.
  4. If you play hard mode, you get hard mode You can however tweak the difficulty settings at world creation to fit your liking, player health and damage can be individually modified in the customize world screen. As Streetwind pointed out, wolves in the normal mode are pretty well balanced. I still remember a time when wolves would be much more dangerous then they are now, a few major updates ago: Wolves wouldn't sleep/rest, they would be on the lookout night and day, they would spawn everywhere, hunt you down for hours and two hit kill you, for the entire game, because there wasn't any kind of armor. Now the only problem I have with them, is them making no step sounds, which can make them quite sneaky, but if you craft a set of wooden armor and a weapon, you are able to easily kill a wolf, if you dodge some of its attacks.
  5. Assuming trees generated by the world don't grow and there is no natural reforestation (i.e. trees planting saplings without player input), the performance hit would be limited to world generation only. Only player planted trees would cause a performance hit, but that should also be fairly manageable, as the trees would grow quite slowly, probably taking a few ingame years come close to the size of "naturally" generated trees. The difficult question is how to efficiently handle a tree as a entity. Having one "tree entity" assigned to every tree seems to be the most straightforward option. Trees generated by the worldgen don't have a tree entity, because they don't need it, they don't grow. The tree entity itself would be stored inside the block that was originally the sapling. The entity would store the positions of all blocks belonging to it and would only update those the tick before a growth tick or the tick when part of the tree or part of the tree is unloaded. Tree destruction should still be done by an algorithm on the axe and should not utilize the data structure on the tree entity, as that would require the data-structure to store the coordinates of the tree blocks in a tree data structure instead of a simple list and the tree entity belonging to the chopped tree would still need to be tracked down by an algorithm on the axe, as well as trees without a tree entity still having to utilize the old search algorithm on the axe, so the whole endeavor would not be worth it. The one tree entity per tree approach however comes with some negatives, like having to check the tree positions every now and then, at least before the growth of the tree, as any of them could be destroyed/removed. Finding and updating the tree entity whenever a tree block is destroyed is also a possibility, however there may be ways to exploit this, such as possibly just moving blocks with pistons in the future or using save game editing tools. Then there are always the problems that could arise with trees lying in more than one chunk, being partially unloaded. Another way to handle tree growth would be to have multiple moving tree entities on one tree. These "tree runner entities" would only simulate growth at their position (and maybe surrounding blocks for leave generation). On a growth tick they grow the branch and move to the next further from the root until they hit reach the end of the branch and then either extend/grow the branch or grow branching. A runner also deletes itself when it reaches the and of a branch or a branching, however at a branching it also spawns new runners for each of the child branches. A new runner entity would be periodically spawned at the root/origin of the tree. They would essentially allow running the tree growth algorithm over multiple ticks, preventing stutters at growth ticks that would maybe be possible with a "one tree entity" model, when it has to check the positions of all blocks. It also has the added benefit of having a lower memory impact, as the tree block positions don't need to be stored on the entities. The downside of this approach being that there is some additional overhead, as there are a lot more block entities that need to be taken care of. Block entity visualization would also be needed to allow efficient debugging, but this also allows for much better debugging of the growth algorithm and modding of custom trees as they would visualize the growth algorithm itself. Problems with multi chunk trees and unloaded chunks can also be handled quite efficiently, as loaded runners can run as usual until they are either destroyed by reaching the end of their branch or hit the border of an unloaded chunk, when they would, instead of deleting themselves, just wait until the chunk becomes loaded, potentially stacking many runners at the chunk border to be released and quickly running in a single tick when the chunk gets loaded. I personally prefer the second approach, for its more intuitive solution for issues with partially unloaded trees and being less prone to lag spikes.
  6. Make a pickaxe and a hammer. When there are copper rocks on the surface, there is always copper ore underneath. With a bed, you can sleep half the night.
  7. Admittedly, the list is quite big and should probably be split up into separate more fleshed out suggestion topics, but things like the list for flora and fauna seem to be a good place for the devs to draw inspiration from imo. I'd suggest to reorganize this thread to be a more organized list of those, maybe with a little more info about each one, highlighting the interesting or very common ones. The other suggestions should then go into individual threads once more fleshed out. This would make the whole thing a lot more readable and prevent single suggestions from being overlooked as well as allowing for better, more focused discussions about the suggestions.
  8. I've been playing "theHunter: Call of the Wild" a bit recently, which is as the name suggests a hunting game. I think a simplified version of its hunting experience could really fit VS. However, for allowing hunting to be more fleshed out, it needs to be more rewarding. Alchemy ingredients are one thing, like Kealty already suggested, another could be bigger meat and hide drops. I however think trophies don't fit, as I see it being rather unfit for a survival game thematically. Hunting should also imo be required for hunting down any creature, not just some "elusive creature" which only spawns if you have been following tracks for long enough. Creatures in general would be much more shy, running away at seeing the player. A simple stealth mechanic would be required, which would be effected by the players stance, immediate surroundings (i.e. is he hidden behind a tree or in a bush) and the sounds he makes, different ground types producing differently loud step sounds. I think the best use for a tracking mechanic would actually be for tracking down damaged animals who flee a great distance. Rather than just regenerating health over time, they would have an bleeding effect that causes them to loose health over time till they die. While doing so they loose blood, allowing for easy tracking. This tracking is especially rewarding because there will be a price at the end of the track, but the track might also lure in predators if not followed immediately. Full tracking of undamaged animals would probably be a lot harder to implement (How to generate animal tracks in newly loaded chunks, i.e. players would only come across tracks of animals they scared away, because they would have no tracks prior to spawning) and a lot less useful as a gameplay mechanic, even if animals are very shy. Some need zone system for finding animals without only sneaking when hunting would be a much better fit in my opinion, where animals return to certain areas, like their sleeping place or drinking spot. Animals just returning to their spawn position would probably be enough though.
  9. You underestimate the work required to implement your suggestion quite a bit. It would not be terribly hard, but just changing some recipes is always done in a matter of minutes. However, I've looked a bit deeper into it and how the recipes are setup and just changing a number on them isn't possible, because the durability consumption for tools is hardcoded in the api to 1. For removing durability from Tools, Collectible.DamageItem() is used, which thankfully has an optional argument for the amount of durability to damage an item. The method gets called when Grid-Crafting with a tool by the method Collectible.OnConsumeByCrafting() and in the code for the BEAnvil.OnUseOver() for smithing. A simple solution would just be to add an exception when grid crafting with a hammer by simply adding something like: if (stackInSlot.Itemstack.Collectible.Tool == EnumTool.Hammer) { stackInSlot.Itemstack.Collectible.DamageItem(byPlayer.Entity.World, byPlayer.Entity, stackInSlot, 100); } else { stackInSlot.Itemstack.Collectible.DamageItem(byPlayer.Entity.World, byPlayer.Entity, stackInSlot); } replacing line 558. It would obviously not be an elegant implementation, but recipes would not need to be changed, including modded recipes. Replacing to tooltip would just be a visual thing that would indeed be a bit harder to do and is not exactly required. However making a special case for the hammer in the tool code is not something I would like to see. To be entirely honest, the best and simplest way to fix the problem is by modifying the smithing code rather than the item code, like you suggest. However, instead of involving chance and storing data on the hammer, but by having the "entropy counter" stored on the anvil and always changing it by a set amount. So every hit the counter gets decreased by one and the hammer only uses durability when the value reaches 0, which also resets the counter back to a hardcoded value describing how many hits it takes to lose one durability. To avoid exploits, the counter is set to 1 after the anvil has been placed, to always have the first hit cost durability. A similar thing is already in the game when it comes to clay consumption by clayforming where AvailableVoxels is used as the counter.
  10. While an interesting concept, I don't see a need for it to be used for hammers. A much simpler solution would be to just have the durability be higher and allow non-smithing actions to substract more than one point of durability. The extra durability could also be scaled down just on the tooltip by just dividing the values, so it doesn't seem higher than other tools, although it technically is.
  11. Erik

    Sifting Table

    I like the general idea, but instead of a sifting table, a sluice would be a better thematic fit, being a bit more realistic (sifting tables filter by size, not weight like panning or sluices). Mechanics could remain roughly the same, but it would also need flowing water.
  12. Erik

    Healing Efficiency

    I thing the healing efficiency debuff for armors is a good think, but I think it could indeed be better designed: How about making healing, aka using bandages, take more time. Like three to four seconds. And being attacked during the healing animation cancels it. Healing in combat would be a lot more tactical and the armor healing debuff could just make the healing animation slower, in turn making it easier to get interrupted while healing. That makes the debuff only really relevant when in combat, which I feel would be a good thing. Honestly, taking off armor should also take time and be canceled when interrupted, making mid combat armor swaps virtually impossible. With the introduction of stamina (as a combat only resource, i.e. used for attacking/blocking and only for sprinting when stamina is not full), the speed bebuff on armor could also be changed to a max stamina debuff. This would make the debuff also only matter when in combat and not punish the player so much for wearing expansive heavy armor outside combat.
  13. Currently, the ore distribution is not designed to suit building mining infrastructure like minecarts. I just think the game could gain a lot by having ore distribution that at least encourages and rewards building mining infrastructure. Ofc the game is currently working as intended, as there isn't any infrastructure right now, but that could change in the future, especially seeing as transportation (boats, minecarts) is a highly requested feature for 2020. More options are always great, but I think the game should focus on the more realistic, more interesting option. This isn't Minecraft, the target audience aren't kids, having Minecraft like ore distribution as a default would probably only harm the game, as it makes the "Minecraft-clone" arguments much more valid. Maybe a middle ground would work best, with most ores generating like they currently do (aka, small clusters with quality depending on the stone type and quantity depending on the ore map), but more advanced ores like iron or some types of coal generating in rare, long, thin veins with low quality ore that go on for miles and warrant construction of infrastructure, as iron and coal are very commonly used materials. It would spice up the system and give a good bit of variety. Maybe making only copper ore generation more like Minecraft would also help, as it is the starting material. It would certainly help new players, while not taking away from the prospecting, as any other ore requires it. Another supportive way of encouraging infrastructure would be to lower the stack size of ores and make turning ores into nuggets require an anvil.
  14. Please only post in English in the future, so everybody can actually read the thing. There will be more automation, according to the roadmap: https://www.vintagestory.at/roadmap.html/ Energy will however be limited to mechanical for now. A watermill is planned iirc, but will only come after the implementation of rivers, which will probably take a while. More ingame explanations will surely come sometime.
  15. Only true if time and monetary restrictions are not a thing. Nope, mods are a big sales point. Easy installation is just a bonus. And currently there just aren't many mods available. I'm not against CurseForge support, I think it's not a bad idea, as it provides free hosting and easy installation for mods. But making it out to be a "must-have" and a "valuable business decision" that has to be done "right now" is just plain false. Right now, new features and extentions/reworks of existing game systems is what the game would benefit most from, long term. When there are a few more mods available, it may be time to think about mod hosting and installation.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.