Implement block-level climate factor variation #15
Comments
|
I don't really feel like this adds anything to the game. It almost feels like it attempts to do what RB already does, but not as well. If it wasn't linked to biomes, kinda like flux in tekkit, then it might work. The current map is not designed with this balance in mind. The map is way to fragmented in terms of biome spread. There are deserts biomes right next to ice biomes, for example. So it will just fell kind weird, imo. |
|
I have a few ideas on alternate XP production that would achieve functionally what Crimeo proposed, without requiring an RB re-write. I like the idea of what's being proposed here but it's late in game for this, and feels very much like the Haven and Hearth "Nodes" concept which isn't very fun (you basically have to just, as you walk around the world, "try" digging or picking or whatever, and note the "quality" of the soil where you dug; eventually you find "nodes" of concentrated high-value raw materials. It's arbitrary and not fun). |
|
maybe we could provide other indicators? On Sat, May 23, 2015 at 9:22 PM Daniel Boston notifications@github.com
|
|
Well, the RB feedback mechanism when holding a seed would be a good place to inject some indication of "quality" of the soil. What other kind of indicator were you thinking of? |
|
Sadly the built in temperature and humidity are useless for this, as they just report the static biome values. We might be able to combine them with some kind of hash of the coords to get a reasonable variance at least. |
|
The question is how complex we want to make things. On Sun, May 24, 2015, 11:36 AM Travis Christian notifications@github.com
|
|
Is it possible to run a script across each chunk of the map and detect its distance from ocean/river biome? A one-time run script that gives a "distance value" to that chunk. Each time a player gets wheat drops/melons/pumpkin/carrots etc, the distance value acts as a multiplier for how many drops you get. I think the basic logic of the script might be to start at the chunk and count how many "chunk rings" there are until you get to water. For example, pretend the dark green block is the chunk the script is checking. It reads the chunk and parses out the Biome IDs ( http://minecraft.gamepedia.com/Data_Values#Biome_IDs ) to check if the surrounding blocks have an ocean/river biome in it.
In this case, the dark green block is a plains chunk, and the blue is a river/ocean biome. The script checks the chunks around it (black ring). No ocean/river. Goes to the next level. The second ring (colored white) has an ocean chunk in it, so the script assigns a distance value of 2. Now see this example: The dark green block ends up being 7 rings away from river/ocean this time, so the distance value is 7. Idealistically, this chunk would be worth more and drop much more crops than the chunk with the distance value of 2. Of course, this could be scaled to be an exponential or linear increase in drops. In the end, you'd get a beautiful gradient of productivity with something like this.
The darker the block, the more crops it drops. Whether this could be extended to mob drops, I am not sure, but it could add a massive amount of depth to the geopolitical aspect of the server. I don't know if this can be stored in the chunk itself or a separate reference file/database. OR it could be the opposite-- with the chunks NEAREST the water being the more valuable. |
|
"Sadly the built in temperature and humidity are useless for this, as they just report the static biome values." Are you sure? As in, has this been directly tested in game? Humidity is used for leaf coloration and grass colors, and I am pretty sure that those often vary continuously within biomes, though not 100% sure. If you are correct, then that is very sad, and I can't immediately think of any other not-super-labor-intensive way to make a plugin show variations that actually map to the real map in game in a logical way. (There are still options that ARE labor intensive though, like admins manually indicating a center of mass of any reasonably sized biome in a fully revealed private admin map and then using interpolation between) The method suggested above is fairly easy to implement, but seems massively biased toward people who happen to live in the few giant biomes on the server, such as the BlackCrown / Breslau region's gigantic plains. It'd be nice to be able to temper that a little bit somehow, but that's probably labor intensive again to hunt for exceptions. edit: I guess you could do "bands" of prime land. Like a little ways from water but not too far, thus not giving too big of an advantage to either islanders or giant plains dwellers. or something like that, could work. |
|
I guess the best way to solve that would be to make it "opposite" and have crops grow better closer to an ocean. I guess that mirrors real life in a way while still maintaining the essence of the modification--making people compete for land. |
|
Couple issues with oceans:
There might very well be some variant of these sorts of ideas that could work though! |
|
Could we step back for a minute and ask, what exactly does moving farms On Thu, May 28, 2015 at 5:36 PM GavJenks notifications@github.com wrote:
|
|
It's not the edges of biomes in particular. The goal is merely "SOME sort of more exclusive, smaller subset of land being especially productive, to increase specialization and trade and possibly conflict, etc." The edges thing was just a consequence of what seemed like the easiest way of doing it -- by using humidity and temperature values. Which I'm still not actually sure we confirmed wouldn't work. But any other system would be fine, as long as it is principled and based on the actual map somehow. |
|
It's not just moving farms away, it's giving more value to land by giving I also think I've convinced myself the opposite (moving farms to the coast)
|
|
ok then, how do we make sure this land is scarce enough to matter? the map also this is another change that ties in directly with the need for a On Thu, May 28, 2015 at 6:29 PM hlprimm notifications@github.com wrote:
|
|
The map isn't just "too big no matter what" -- it depends on the algorithm and changes made. I mean, depending on how its done, it could be anywhere from 1 single block up to half the map that has the higher productivity. Whatever we code in there. The particular plans outlined above are probably still too big. But there are many other potential ways I'm sure that would be sufficiently restricted. I am pondering it. And no I don't think this has anything to do with compactors, necessarily. It could be done with them in mind, but it doesn't HAVE to be. The drop rate merely needs to be relatively higher in one place than another, but the average and the recipe requirements could be roughly the same as now, i.e. not requiring meaningfully more bulk than currently. For example, a potato plant drops on average 2.5 potatoes, *220% with fortune III = 5.5 potatoes - 1 to replant = 4.5 potatoes yield on average per tile farmed. If a small subset of land produced yields of 10 or 20 potatoes per tile, but not enough of that land to meet global demand, and then the remainder of land was LOWER than now, like 1-2 yield per tile, then we could potentially still have about 4.5 potatoes on average per tile farmed on the server, and keep the XP recipes unaffected, and have no more need for a compactor, etc., despite still meeting the goals of conflict/politics/population centers/etc. |
|
My point with the compactor is that now people find it too tedious to On Thu, May 28, 2015, 7:01 PM GavJenks notifications@github.com wrote:
|
|
Yeah that's a fine argument, and a compactor may be a great idea. I'm just saying that neither compactors nor this suggestion depend on one another or require the other coming first. They are orthogonal issues. To the extent that compactors are good, they are probably equally good with or without this and vice versa. |
|
I doubt this would work as intended unless trade was made easier is what I On Thu, May 28, 2015 at 7:31 PM GavJenks notifications@github.com wrote:
|
|
shrug I think 8x higher yield here vs. there is plenty motivating but I could be wrong. |
|
ah, so higher, not nerfing existing yeild? stuff is already a little cheap. On Thu, May 28, 2015 at 7:35 PM GavJenks notifications@github.com wrote:
|
|
I think this does go hand in hand with compactors, actually. If people specialize enough they'll have way too much on their hands. The compactors help them get their items to the market. Heck, if the items can be put in item exchange chests that'd be amazing (but that's a whoooooole another topic).
well, instead of a gradient, we could just make the closest 3 chunks or so to water biomes drop like 20x the drops. everything else just drops the normal amount. there are also so many dang rivers that maybe checking distance from ONLY ocean biomes would be a better method. doing so would severely limit the amount of chunks that would be affected by such a change, further driving up their prospective scarcity/value. |
|
I was thinking both higher and lower yields (higher in the ideal spots, lower in other spots). Such that the average ends up about the same as now (or if you think it's too cheap, maybe a little lower, even). This is a suggestion about pattern of distribution only. Pattern of distribution can be entirely divorced from the matter of the average yield. |
|
@hlprimm, you do not need to restrict yourself to chunks. The whole world is only 700 million pixels or something. And the one time algorithm could be run offline. You can do quite a LOT of calculations per pixel for only 700 millions pixels, when you have hours available to do them in. That's not a problem I think we have to worry about. If you want to search every single block to the nearest block of river, that would be fine. Etc. |
|
@GavJenks Yes I tried it myself with some logging added to RB, the values were exactly the same across all blocks of a taiga including boundaries, then exactly the same across swamp, etc. |
|
Well, nuts. Okay, how about this:
The scaling on the drop spreadsheet, or how much of a difference each point makes can then be changed as needed to yield desirable results. The points also don't even have to be linearly interpolated. They could shange drop rates logarithmically based on points or whatever. tl;dr: Combine several of the above filters. Any one of which would be too much land, but by overlaying them might be exclusive enough. |
|
For example, for cacti, they would gain more advantage in desert and less in nether. Then would thrive best near rivers in deep desert country. So there are only a few places on the map then with the best conditions: such as the river bend just SE of goodsprings and MA, the river area SW of requiem, the area east of Intis, and two slightly less good areas right next to New Leningrad and west of Balkania. edit: some crops could flip and use oceans instead of rivers, to not screw over island nations, everyone has a potential nearby niche (goal is not leaving people in the cold, but encouraging specialization more so) |
|
I feel like it would be nice if variations of existing crops could be grown (i.e. different types of cactus, different types of wheat) depending on what region of the map you're in (i.e. very deep +,+, the bottom-left part of -,-). |
|
I haven't gotten through all this yet but I wanted to point out that we have an unused option for proximity to river water (specifically sea-level water source blocks in a river biome), and that block-to-block biome search over multiple chunks is going to get VERY computationally expensive without some fancy tricks (n^2 to distance per crop) |
|
@MonsieurWTF That's what I originally though of, but then we get into creating an exception in RB where only a lore crop grows in a certain area. But to do that we'd still have to start with the block/chunk-level climate variation. That's why I was thinking doing it by chunk might be faster and better (and keep the overall square-ish shape of farms). When you say unused option, do you mean there's a function in bukkit or another plugin? |
|
@hlprimm Other side-thought; what if instead of these 'sweet spots' giving higher yields, they gave resource variations as a sort of 'exotic' good? (Not sure if that's also what you meant in your response, but just putting this out there since my previous suggestion was more coordinate-based than based on the **climate variation.) Edit: ** |
|
I'm thinking of how we can realistically execute/script this. Maybe start with a mineflayer script that teleports an admin player to each chunk, notes the chunk number and biome into a grid file. A second mineflayer script references this file and sees if there is water within 5 chunks of the chunk by running a pathing algorithm. If it does find water, it runs worldedit and changes that chunk's biome. We can make it into one of the unused 1.8 biomes and assign jaw-dropping drop rates to it through RB's existing config. This is the easiest way I can think of doing this. Thoughts?? @MonsieurWTF You should see the factorymod git. This is for realisticbiomes. There's also some stuff in the changelog on reddit For the exotic goods, I also thought of that (like a lore wheat that is crafted from 9 regular wheat), but that adds another level of complexity. I don't think there is necessarily a demand for"exotic" goods more than they just want more cooperative production and more of a trade-based economy. |
|
@hlprimm The exotic goods should only be acquirable when the wheat block is broken, and in no other fashion, so that only few areas can grow it. Precisely. However, at the base of this, most cities and groups tend to not need trade because they don't need to get involved with other people. They don't want to have to deal with middle-men and transportation and fluctuating rates or trade deals outside of their friend lines. Exp production, as it stands, may seem difficult to the people that need it, but is so incredibly easy after the farms are set up. Of the three main factors that determine how hard one must work to produce Emeralds (Time, Materials, and Complexity), the Materials factor is the only one that really comes into play. The emeralds are made almost instantaneously, and it only requires one factory for a city to produce stacks of emerald supplies. Time needs to play a larger factor in the factories involved with exp-making. As for complexity, it is my belief that more of these bundles of raw goods need to at least be refined before they're put into the final step parallel to the making of Bastions. Both of those routes give boosts to the time and complexity that is required to make emeralds, and decreases the massive impact farming bots have on the equation. If you want to go with climate-segmenting certain resources to have higher yields, I feel it is only necessary that the above alterations be considered. |
|
@hlprimm https://github.com/Civcraft/RealisticBiomes/blob/master/src/com/untamedears/realisticbiomes/GrowthConfig.java#L136 |
|
Oh nice, I wasn't aware of that multiplier!! I was worried someone would ask that! I've been thinking of a solution but I can't quite think of what it would be. To my knowledge there is no bukkit plugin out there that can selectively replace a biome with another one (replace only plains with X rather than a blanket setbiome for whole chunk), so I'm not sure. We could just wing it and do it by chunk still (overwriting some river/ocean). It would make some waterfronts look blocky once people build their farms, but I don't see much harm done that way. Redneck fix would be to give massive drops to beach biomes? Not sure how rare beaches are, though. |
|
@WildWeazel, n^2 to distance per block is not a big deal if you run it offline once for 8 hours one day, and then you're done. Biomes don't change in game, so you would never do this during gameplay, you'd generate the data lookup and then just look it up later when actually harvesting. |
|
@hlprimm I am very confused why anybody is talking about wanting to overwrite biomes in the first place, what? @MonsieurWTF tech trees like bastions are really bad on civcraft. The point of tech trees in popular games is that for SHORT TERM gameplay, where you start over and replay through many times, a tech tree forces you to choose one of several partial branches which allows for interesting strategic decisions and compromises. In a long term persistent game like this, though, it is not a good feature. Because any one group will simply eventually build ALL the branches, and it's not strategically interesting, and ends up being nothing more than a few extra layers of tedious clicking to run through 3 layers of factories instead of 1, which is no fun for anybody. Complexity is a good goal, but layers of factories is not the way to do it. A good kind of complexity is in the form of required social organization. For example, the batch size proposed for repair factories needing 52 tools at once is a great example of this. Not mindless clicking, no one solution, but open-ended social interaction complexity that some people will do much better than others. If tech trees would ever make sense, it would have to be a situation where you CANNOT make all the branches of it. Such as two factories that are mutually exclusive to build within X radius of one another, and both of which are needed to do some important thing. But even then, it's less elegant to provide two fixed options than it is to come up with open ended social puzzles. |
|
spread out factory requirements do encourage specialization in the send The fact of the matter is Bastion factories have worked better than almost On Sat, May 30, 2015 at 2:54 AM GavJenks notifications@github.com wrote:
|
|
I'm not saying that we need to add the same intensity of factories that are required for producing Bastions. I'm just saying that the time that needs to be invested into producing emeralds and the complexity towards preparing them needs to be increased slightly, and that would be with the route of even adding 1-2 recipes in existing factories (just like Bastions), and adding a time component to some parts of the design. Keep in mind, this is 'FactoryMod', not 'instantly make 10 stacks of emeralds per run of a single factory'. The longest part of the assembly line for making XP is on the gathering end, and the assembly takes mere minutes to run through.
Social organization is only really needed when the complexity or time involved in a task requires more than one person managing it. As is present, the only social part of emerald making is collecting all the materials from bots or certain things between cities. After that, it only requires Player 1 to fill up his inventory with the right balance of ingredients, putting them in the chest, and then spamming stick second after second, rather than half-minutes between run. Factories being able to instantaneously make products without needing time is, in my opinion, a very overlooked flaw that only adds in to people not needing to buy basic goods from others. |
|
I agree very much with that. On Sat, May 30, 2015 at 8:29 AM MonsieurWTF notifications@github.com
|
|
Here's a semi-radical thought on re-inventing the production flow of exp that can probably even allow for a more open-ended social approach, while adding complexity to the final product: (The following ingredients in the diagram are just to convey how such a system would work, and are not directly parallel to the final form)
If we look at the existing 4 diamond recipes, there are a few ingredients that overlap with at least one other recipe. Using that, we could 'break down' the diamond cauldron ingredients so that they are staged, starting with 1 at the Wood cauldron, 2-3 at the Iron Cauldron, and the remainder at the Diamond cauldron. At each stage, the inputs produce 'packets' that can either be converted into that Cauldron's amount of experience bottles, OR use it on the next tier cauldron, like a 'Value-added' approach. Wood cauldron makes the stone 'packet', that then goes into the Iron cauldron to make the next better 'packet, which can then be used in the Diamond cauldron to make the final packet. On top of this, the packets could be traded between players, so if you want, you could import the Wood cauldron/Iron cauldron packets from other cities that don't have diverse crop variety. Just a thought. Any opinions on this? |
|
very cool idea, I would like to see it discussed more, probably on On Sat, May 30, 2015 at 9:31 AM MonsieurWTF notifications@github.com
|
|
@GavJenks I'm just thinking of the easiest way to have super-productive plots of land (whether by chunk or by block) while making sure these plots aren't so plentiful that anyone can get one! It would be nice that they are sources of contention and compromise between neighboring towns. The biome replacement is just a suggestion to further this, while the n^2 distance per block script could also work, albeit a little bit more complex since we'll need to make a radius-counting algorithm. |
|
do we want to try and move this to discourse? probably better here for now On Sat, May 30, 2015 at 12:57 PM hlprimm notifications@github.com wrote:
|
|
@MonsieurWTF That's clever design, but conceptually, I think it pushes us further away from ttk's desired cooperation goals. Having it tiered and being able to "hop off the train" at each level and being able to swap things out, etc. adds more flexibility to the current proposal, and even more total than we have now. Flexibility in recipes is the opposite of cooperation, because more flexibility means that I can choose a recipe that matches exactly the biomes I have nearby me already and thus never have to trade or interact with any outsiders. If the goal is to shift the status quo to more rewards for cooperation, we want LESS flexibility, and more mandatory variety. Which would mean fewer tiers available as choices (namely getting rid of wood cauldron was a good move) and fewer options in recipes within each tier. |
|
I strongly recommend this issue be closed and the discussion moved to On Sat, May 30, 2015 at 4:10 PM, GavJenks notifications@github.com wrote:
|
|
forum.civcraft.co On Sat, May 30, 2015 at 4:27 PM, MonsieurWTF notifications@github.com
|
|
I'd like to try my hand at this myself on a single player map. If I generate a map for 1.8, anything I'd script for that would work on the server, no? |
|
I guess it should the map is converted to 1.8 format. On Sat, May 30, 2015 at 8:34 PM hlprimm notifications@github.com wrote:
|
|
hlprimm, a number of new biomes were added in 1.8 I believe, and the biome generation script changed significantly, so it would not necessarily still work. It shouldn't be that hard to make it, but you should double check anything you're relying on in the code to make sure it hasn't changed. |
|
Closing this as there has been no consensus, and it would look very different for 3.0. |
Fix growth time when breaking column plants or adding blocks to them
https://www.reddit.com/r/Civcraft/comments/36xyz2/crop_quality_proposal_supplementary_to_various/
The text was updated successfully, but these errors were encountered: