Persist ALL THE THINGS #16
Comments
|
Coca just always grows out. Should be easy to figure out. On Fri, May 29, 2015, 10:41 AM Travis Christian notifications@github.com
|
|
I wonder if the BlockChangeDelegate variant of generateTree will be needed to check for reinforcements. Hopefully it will just fire a growth event. Too bad it doesn't take a maturity level for the tree being generated. |
|
I'm interested, but I'll have to take a better look at the code before I can tell you if I can do this or not. Will report back. Also mushrooms, they have some specific spreading rules. |
|
Yeah, I don't think fully replicating vanilla behavior will be worth it. Hopefully that won't cause any problems. I can do it but I'd rather keep focusing on Factories/Contraptions if you want to take it. |
|
I was just thinking about the farms for these crops work: I think that this may still be better than AFKing it performance wise, but the there would now be sudden lag spikes if the farm is big enough. It may be worth exploring Contraptions to harvest cacti magically without performance impact, rather than creating huge amounts of blocks, break events, or itemstacks. The same goes more or less for pumpkins, melons, sugarcane and mushrooms. There aren't that many autofarms like for cacti, but they do exist. Melons, pumpkins and sugarcane can be farmed with pistons from an interval or BUDs, and mushrooms with washing them away in an interval. Ideas? |
|
Good analysis. Could the grouping of drop stacks be leveraged to reduce the performance impact by spawning dropped stacks instead of individual items? Also, given the expense either way, perhaps finding the nearest hopper connect by water on a Y below the cactus, unimpeded by other blocks, would be feasible. Then stuff the hopper and any connected chests with cactus based on computed output. |
|
We could group stacks yes, but don't count on putting them in hoppers - most farms collect items with water chutes into a central hopper. |
|
Yeah, that's exactly what I'm talking about, gipsy. Programmatically "follow" the water that's under the cactus source block, to the nearest hopper connected to the water. Etc. Just figured that such a system might be less painful to the server then handling all the entity spawns on chunk load; could pre-compute association of cactus source to hopper/chest stack on chunk unload, then on chunk load, fill the chests/hoppers with items based on the expected rate of growth during the chunk's offline time. |
|
that sounds like a job for a contraption, maybe an area collector contraption could be possible? Like a longer range hopper, but if we make them too easy to sue everyone will use them and we might negate our gains. |
|
Eh, I think following water flow is going down the rabbit hole too much, perhaps? You'd have to calculate that on each chunk load unless I'm wrong. Contraptions could support something like working together with RB to do basically the same thing sans following water flow. Maybe "absorb all potential offline cactus drops from above and in radius X" on chunk load. If RB can expose both chunk crops (cacti etc) and offline time to contraptions, this could make a good compromise. Existing farms could be adapted easily, just replace collection point with this contraption. BTW I have to post to contraptions repo 'cause I couldn't figure out ow to make them work at all :| |
|
I am not sure what state the contraptions code is, feel free to ask questions over there. |
|
@ttk2 I like that idea, it's a great thought for contraptions, although it's functionally identical to what I was suggesting. @gipsy-king Nah, you'd only have to compute it on chunk unload, then apply the computation on chunk load, after which point vanilla behavior takes over and the computed behavior is inactive. Since it's on unload, you could spawn a FutureTask to handle the computation based on a snapshot of the chunks unloading, and allow the computation to "eventually" complete, with early cancelling of the job if the chunk re-loads before computation is done. That said, I like the contraptions idea. The "benefit" of my proposal would be no alterations to existing farms, but obviously that's not a priority in the grand scheme. Also, the Contraptions approach would be basically the same, but I'd guess more persistent. Now we're getting into "wrong repo" territory, but with a contraption, you could suppress cactus growth and auto block break events (eliminating item spawn) and just have the item drop appear within the contraption. It should be relatively easy to define some system to mark out "area of control", but for the love of god don't make it a voronoi-style area-of-control; we're talking mechanisms, it should be a mechanically defined volume (placing lored blocks, "blueprint" loaded into the machine, something -- literally anything -- besides automatic subdivision based area control) |
|
How would RB and contraptions communicate if we wanted to do this. On Tue, Jun 9, 2015, 8:03 AM Daniel Boston notifications@github.com wrote:
|
|
I think we could just expose a simple API to look up rate by plant and block/biome, basically a shortcut to what the click event handler does, and let Contraptions derive its output from that. |
|
In the meantime let's do other crops one at a time. Getting something done On Tue, Jun 9, 2015, 8:56 PM Travis Christian notifications@github.com
|
|
Regarding plugin communication, @WildWeazel could RB emit a custom "chunk-load-harvest" event that contains data about how many blocks have been "spawned"? RB could then create these blocks, unless the event is cancelled by Contraptions presumably to fill the contraption. This would allow for a future implementation of contraptions while having persistence now. I'm going to start with melon and pumpkin, then sugarcane. I don't think that there are many auto farms for these, although I have a tiny BUD autofarm for melons. Sugarcane is mostly farmed at an interval I think. Cacti are a different story, because cactus farms are continuously dropping, so AFKing will always give more output than output from offline persistence, since the latter maxes out after the time it takes for all cacti to grow. I think cacti NEED contraptions, or players will continue to AFK cactus farms. |
|
Perhaps so but does that also account for the manual stick checks? Do they trigger a whole chunk update? |
|
@gipsy-king Although I agree you should go ahead and tackle melons and pumpkins, do note that there are quite a few auto farms for both, and some are quite massive. |
|
lets get what we can done while we discuss the rest. |
|
trees at least should be easy enough, ironically |
|
#20 for cocoa |
|
http://forum.civcraft.co/t/starting-soon-realisticbiomes-cocoa-persistent-crop-growth/457/2 I updated the jar and the config to the latest build. inb4 I borked something. |
|
it looks like Coco works, next? |
|
treeeees |
|
Good point. Perhaps a new chunk that fails the check should test if a runnable is already "queued" and attach itself to that runnable. Yay threadsafe coding. |
|
@WildWeazel @ProgrammerDan should I add mushroom persistance? The easy route would be to subsitute with huge mushrooms like trees and nerf small mushrooms to the point of being useless, but that would upset A LOT of players. Normally I wouldn't care but this is delicate in the sense of players trusting that what they build won't be rendered useless anytime. The upside would be that chopping down huge mushrooms, like trees, is very complicated to bot. Emulating the algo to grow shrooms isn't too difficult either. It has to be a 9x9x5 bounding box centered on the shroom, and in that box there can be max 5 shrooms, and a free spot requires to have dirt/grass/mycelium and low light or something like that. |
|
how much lag is mushroom farming? if its not much efforts may be better centered elsewhere. Then again if its easy do it now. |
|
The mushroom spawning isn't the lag source. The issue is that mushrooms are harvested with flowing water released by pistons on a redstone clock. The water and pistons in large farms will be a significant lag source. I'm not aware of any designs that pop the mushroom using timed light sources, although that would be possible (and likely less laggy than flowing water). So I don't see much value in persisting mushrooms, unless there's some means to harvest I'm not aware of, as the harvesting alone is the lag source, not the mushrooms. |
|
very well then, @gipsy-king we have interesting reports that they RB remove plant function might actually be removing random blocks. |
|
@ProgrammerDan the lag source we're targetting with persistence is AFKing. That is, chunks being continuosly loaded over long period of time with all their possible lag sources. @ttk2 that would be the block-update function, that updates the block(s) to whatever the plant's growth is supposed to be. When a plant gets removed (that is the spam log message from the other issue, fixing ASAP), it only gets removed from the tracking list of the plugin. |
|
@gipsy-king I know, I'm not making my point clear. My point is, collecting the plant is the lag source. That's going to be true regardless, your efforts would be in vain for mushrooms specifically. It doesn't use a fixed flowing water source for collection like cactus can or melons and pumpkins can. The water is flowed selectively... much of the lag is the infrastructure at harvest time, not during the larger AFK time. |
|
@ProgrammerDan but the target of persistence is AFK, not much else. If you want to make it less laggy, we can do it for example with disabling mushroom spread entirely and allowing giant mushrooms to grow like trees (I don't remember who proposed that, I think it was in the forum discussion). |
|
Ok, fair point. I concede. Perhaps my comments could be reframed as "set ttk's expectations" so he doesn't interpret mushroom persistence with any behavior or lag change, as it won't provide it. Just lets people leave their farms alone, but they'll need to return in the same frequency as their water-flow harvest mechanisms to keep the same rate of return, so I hazard they won't stop AFK'ing. |
|
@ProgrammerDan yea there is a veri big issue of people still AFKing because it either 1. already works fine for them or 2. to setup a bot that connects for 1-5min every N hours is more complicated than most AFK mechanism. Can we think of some way to penalize AFKers (vs disconnecting and using persistence), without penalizing farms that are near populated areas too much? |
|
We're working on it :P (Max and I). So keep your eyes on the AFKPGC mod, it's coming. We've got some good ideas to get people moving. |
|
@ProgrammerDan yea I've been watching the development, looks good! |
|
I think ideally we would rebalance RB such that harvests are only needed once or twice a day. Such that bots are not needed to harvest to maximum efficiency. Thoughts on this proposal? |
|
Now that compactors are in it's more practical to work in high volume, so I think that makes sense. Would that mean multiple drops per harvest? How does that affect people who are actually growing food? |
|
Maybe something to "simulate" fertilizer. Make the maturity time 24 hours for wheat. You can get more wheat only if you punch it with a certain block, which is consumed from the player's inventory. @WildWeazel I think people would just end up harvesting wheat as food less? I don't know how else you would prevent people from piggybacking on this change, though. |
|
Why not just have a 24 hour grow period? |
|
@ttk2 that would probably make people AFK less, since they just have to log in once a day. |
|
that's the goal, lets just balance for that, work out how to keep it from being too big of a pay cut and call it a day. |
|
@ttk2 the problem would be that food for newfriends without clay soil would take several days to grow, as WildWeazel pointed out. |
|
this is true, its not like they will find any mobs to eat either. |
|
@ttk2 if tried with something boring like cactus for starters, to set it to 24hrs, what would be the problem? Farmers will say "the output is way lower" and they'll be right, it will be 48 times lower. I don't think adding some modifier that doubles the output of a single plant is a good idea. Ideally we would have a contraption that "sucks up" as much as we configure, but contraptions aren't there yet. Cactus seems to have a huge number in XP recipes, namely 4 times as many as the cocoa requirement for example, simply becuase there is a huge output from farms. If we set the cactus requirements to roughly 1/50 of what it was before (or something higher for starters), I think everyone would be happy and we could reduce botting significantly. |
|
I don't have an issue with that for cactus, but what about food crops? should we add a bread factory to allow the creation of the same amount of food from 1/48th the wheat while we reduce the xp what requirements by a factor of 48? |
|
Let's start with cactus. I don't think it makes much sense to AFK wheat anyway. Harvesting bots aren't that common, and if you can make a harvest bot, you can just connect it every N hours, instead of having it idle between the "harvesting" program. |
|
Correction regarding wheat AFK: it seems noone AFKs wheat, but wheat bots usually work on fields so large, that when the bot has finished harvesting, it has already grown back at the beginning. |
|
closing this issue, if we need persistent mushrooms we should open a new issue. |
|
ok lets start with cactus then, it should be an easy change to make. |
|
@ttk2 I'm going to make a PR setting the time to 12h and explaining that it requires the XP recipes to be adjusted. |
Add more information to RB GUI
Add right click to auto replant
Trees: World.generateTree(Location, TreeType)
Sugarcane: reuse soil check to find height of plant, then check if block above is air
Cactus: same as sugarcane, also check for solid blocks surrounding air block
Pumpkins/melons: search for attached fruit, if none search for adjacent air block above dirt/farmland, remove stem from DB, add again when fruit is broken??
Cocoa: ????
Mushrooms: ????
The text was updated successfully, but these errors were encountered: