dreadicon

So, I've been working on a project for some time now for use with TFC. The problem is it's a rather....large project.I am building a plate tectonics map generator.Why? Because it produces realistic, interesting, dynamic, logical results.-Use real-world geology to find rock types-Explore massive plains, coastal mountain ranges, volcanic island chains....etc.-Biomes which are dependent on geology to create deserts, forests, jungles, etc.-Rivers which flow downhill, meadows in forests, mountain lakes, etc.And what does this require of Bioxx/Dunk? Nothing! (per-se).Because tectonics pre-render the world, this can be done entirely independent of the game, in a program written in any language. It COULD be written in Java. Or C++. Or C#. Or Javascript.Now, obviously TFC could add aspects like meadow grass, meadow biomes, and so forth, but it's not inherently necessary; this could just plug straight into the map format!Back to why I am making this post: Plate tectonics aren't easy, simple, or efficient. They present many coding challenges. Working with one colleague we put together a proof of concept program which implements a C++ plate tectonics library, exporting the result to a minecraft map. It's only vanilla stone & water, but the results were very promising. mountain ranges, island chains, prairies, and rational continents were formed, and stretched as far as the eye could see. unfortunately, my colleague is unable to work with me on the project any more (though he's still available for the occasional question concerning it). While I will finish it eventually, it would do wonders for my motivation and productivity to have someone to work with.I was just starting to port the project to C#, but if a C++ guru were to pop up, I have no qualms about keeping it in C++.So, if you are a programmer, or know someone who is and would be interested, please let me know! I have a design document and an old github repo for the last iteration before I began my rework. Can provide any details requested!Some heightmaps generated with the proof of concept are attached; I will attach some in-game minecraft pictures later.(credit goes tohttp://sourceforge.net/projects/platec/ for the original proof of concept and images, though I was building an entirely new codebase to accommodate things like rock layers. I have also run unit tests after building his code myself. It runs surprisingly fast (2 minutes for 512x512)here is a link to the Design document:https://docs.google.com/document/d/1ZKugZXUvFdJRVa5lZAMPg7Z9OK2vr87MtSgHFXtEsVQ/edit?usp=sharingYou may feel free to comment; please leave your name or handle if you do so!(likely) FAQ:Q:"If you make the map in a seprate program, is the world still as big?"A: In short, no. The world has to be pre-generated, therefore it must be very finite compared to minecraft's procedural generation. However, the maps generated with this program would take 24 hours to walk from one side to the other. Before starting on this concept, I asked many players who spend most of their time exploring, and found that few wander beyond a certain distance. The map will be double that distance in all directions, and have a sheer cliff with empty blocks all around ('end of the world' style). Perfect? No, but IMHO trading a 1% edge case for an improvement to the game overall is worth it.Q:"Will it really be that much better? Tectonics seem excessive."A: Well, that depends. Personally, I see the fractal patterns, the artificial boundaries and shapes every time I play minecraft. It just doesn't feel right. But even that aside, there are some thing in nature that fractals just can't simulate, or are very difficult to simulate. The feature list I placed above is a few such things.Q:"Is this really possible?"A: yes. it will take a lot of work, no doubt, but it's definitely possible. I've run unit tests and theoretical numbers; everything says this is possible. Heck, I've already got one that creates a real minecraft map.Video demo of PlaTec in action (the program used for the Proof of Concept build, see pretty animations!): Some stats for PlaTec in smaller scales which were run by the creator of PlaTec and verified by me on a similar machine (Core 2 duo 2.5 Ghz, 4GB RAM Laptop I have lying around). Columns show the size of the heightmap, and rows show the number of plates used. The code is also not as optimized as it could be. Source:http://www.theseus.fi/bitstream/handle/10024/40422/Viitanen_Lauri_2012_03_30.pdf?sequence=1

Just poking in here to let everyone know I am still alive, and I have not given up on this. More investigation has revealed obstacles which, while they can be overcome, will take time. Additionally, I have been very busy lately between my job and ongoing dental work. Sorry I don't have much more to report.... Oh, I did settle on a language; due to my lack of time to learn advanced usage of C++, and the fact that I have only heard back from one C++ coder, who more or less is waiting on a functional prototype before he jumps in, I will be coding the generator in C# using Xamarin for cross-platform compatibility, and will eventually look at a static compilation for optimal performance (yes, C# can in fact be compiled completely to machine code) Hey Dunk! That's awesome! As mentioned, this will be a separate application, but it will be designed to use TFC blocks as output. What would be awesome is if once initially completed, I could work with you both to make better use of the features it generates. That way, you could add real prospecting where the player follows clues and geology to find where to dig, compared to now, where it's slightly educated guessing. It would be intuitive too; find ore in a river? follow the river upstream to find where it came from! Euphoric up to your bothersome pragmatism I see I understand that this will be hard, and with my limitted time it will take quite a while. But I am a firm believer that computers can do almost anything with enough ingenuity. Terex, solid points. To that end I am building out a very general and 'good enough' macro scale generator, so I can put equal or greater work into the micro scale. Thank you all for your support!

Popping in here to let everyone know I am working on this slowly; for the past week I have been moving with my wife into our first apartment, but I should be able to resume more substantial development soon! I also had an idea for prospecting in Genisis: riverbed blocks as a unique block which contains the ID of the river from which it came, and you can pan for minerals based on where the river has been, but in doing so the river bed blocks become gravel/sand/dirt eventually, and the existing chunk-based prospecting takes over. This would be a bit complex to implement and require an actual minecraft plugin, but would make prospecting interesting and unique, and give a reliable way to find ore. By panning for minerals, and following the rivers to their source, or until you are no longer getting the mineral, you can find areas, then use the prospecting pick from there. But for now, my actual focus will remain on the actual terrain gen. Thanks again for all the support! In brief reply, as to THUNDERGROOVE's concern, the 2048x2048 render will become more like 32,000x32,000 once finished. The initial simulation produces a rough map which is then refined to much higher resolution. Tsuarok, I expect it to be at a fractional scale compared to earth, 1/4th or 1/10th, generally, as that is minecraft's vertical scale. View distance is an issue, but Optifine (which I consider more or less part of core minecraft at this point) allows for substantial increases in view distance and performance. TyronX, those maps are a small step up from fractal gen, but remain somewhat underwhelming in my experience. They still have very random shapes and mountains are still uniform and bland. As to the developer project, I took a look and most are still fractal-based. But never the less, I appreciate your support! And don't let my comments stop you from suggesting anything else! Euphoric, I am currently looking into several different possibilities for how to manage the data size. It is definitely an issue, but one I think can be overcome. I am investigating the viability of an ECS coding model, possibly using RDBM to hold the non-active data (rock layers would not impact the simulation generally, so it need not be held in memory at all times. most of what is done to the layers are writes, not reads.)

@Euphoic -OK, point taken about the optimization consideration. One such scenario which can (in a few circumstances) achieve 10-20x better performance is utilization of GPGPU + multithreading, but that is a major overhaul and typically only gives about a 1.5-2.0x increase.I've set the 32000x32000 @ 5 hours as the only target number, and even that is still up for debate. As to data size, the raw memory usage is theoretically only about 250MB for a 4096x4096 map of 64 bit integers. I think there is some memory leakage and/or other bloat that could be worked around/fixed/optimized to bring it more in-line with the space it would actually use. I have also been toying with methods of getting better performance and rock layering. One idea was to use courser grained simulations (such as 512x512 or 1024x1024) for the plate tectonics, and increase the up-scaling at the end. You proposed such a method, and I have been toying with the idea for some time. I would still want to track the individual layers, however. Additionally, simplified data could be kept concerning things like cumulative erosion from wind/water, and other such markers for use in a new additional phase where a more advanced interpolation takes place (applying interpolation followed & intelligent noise weighted by said metadata). Once this phase is complete, it would then be polished as normal. Ultimately, more tests will have to be done before exact expectations can be set performance-wise. @Tsuarok - Thanks for the support! Euphoric may be rather discouraging, but he raises some valid points. In the end, if the full render takes over a day, I would still call this project at least a partial success. And that actually raises an interesting idea: the reason for the target of <5 hour rendering time was because inevitably you will get maps which have a boring or bad layout. It just happens when you use randomized generation; real life can often have boring landscapes too. But here's an idea: what if the program was to have a 'stripped down' version which only runs the macro-scale, and only tracks macro-scale impacting aspects, then gives the user an image and the seed used to create the world. This should run almost as fast as the current PlaTec implementation, and let you know (very generally) how the world will look. Once you have one you like, just run the program again with the seed, and this time it will render the whole thing taking much longer. This would help solve the issues with long render times more generally speaking. Thoughts? Final note: I re-ran some tests. Most of my quoted stats were from memory (4096x4096 stats excepting). Some stats for smaller scales which were run by the creator of PlaTec and verified by me on a similar machine (Core 2 duo 2.5 Ghz, 4GB RAM Laptop I have lying around). Columns show the size of the heightmap, and rows show the number of plates used.

Ah, I see. I wasn't aware the pieces needed were already present. In that case, yeah, I see no problem with it. It will take more balancing, but it's managable.

In short, yes, it's ambitious. But I have been doing my best to begin breaking it down into smaller, more manageable stages, each of which provides a tangible result. The design document is meant as a very high-level view of the code. I could outline exactly how PlaTec (the proof of concept code we found and modified) did everything, but many of the methods involved were hackish, difficult to extend/modify, or just confusing.As this is an amateur project, odds are one day I will move on (I intend to see it through at least to completion & maintain it, but you never can say what life will bring). If I want the project to go on after that, it needs to take less than several weeks of painful pouring over the code and reading documentation for others to get the gist of it. The PlaTec code took me over 60 hours to glean how it works, and that much again before I could actually start thinking about changing it without breaking something. I want to build a maintainable code base so if I have to leave this for reasons beyond my control, some one else could carry on my work.But to offer the best answer I have to your question directly:PlaTec uses algebraic arrays (y * stride + x), which are (typically) very efficient. Each plate is stored separately in it's own array, which is a fairly brute-force implementation, but it works for PlaTec's purposes. There are methods which translate from global coordinates to plate coordinates, and for expanding/shrinking the array. There is a global heightmap which is created using the individual plate heightmaps, and rendered after each pass (that's where the pictures attached to the original post come from). In our implementation, we made the rendered heightmap optional, to improve performance (net improvement was small, but noticeable).As to the method of data storage used for our purposes? That is still up in the air. 2D arrays, vectors, algebraic arrays, RDBs, and hashtables have all been discussed across both C++ and C#. There are functional and performance benefits and drawbacks to each. The path I have been playing with recently uses 2D arrays as placeholders for later optimization (they are easy to implement, but have poor performance), but I have not done much yet which relies on them. The tentative plan was to use 2D now, algebraic later.Finally, you asked which item between the following is the target:-Avg. gen time (using recommended specs) for a 32,000x32,000 world of ~5 hours-Avg. gen time for a 64,000x64,000 world of ~2 hoursThese are the targets at given priorities. 32000x32000 at 5 hours is higher on the priority list than 64000x64000 at 2 hours, thus the first target performance level is the #1 priority once all the criteria above it have been met, followed by the other features below it, then near the bottom the second becomes the new target priority once everything above it has been met. I apologize for any confusion; Till this point only myself and one other have been actively working with this document, so it may not be as clear yet as it could be. I will be taking time this weekend to revise wording, add description, and give more details. Moreover, until the project has picked up more momentum, everything here is open for debate in one capacity or another. I decided to post about this and open the document for public viewing/commenting in hopes of not only getting some collaborative coding, but some conceptual discussion and review as well. Changing architectural aspects is much easier now than it would be later.EDIT: to specifically address your concerns about memory, the 4096x4096 resolution PlaTec simulation consumes about 3GB of ram using 64 bit unsigned integers for the points at peak usage. When interpolating and performing operations on the 32,000x32,000x256 finalized 3D voxel data, only a portion of it needs to be loaded into memory at any given time. Once the opperations finish, the entire structure is compressed into the Anvil format, which actually has pretty good compression rates.

ROFL, I have to laugh, because that's more or less the initial model we had used when we started. It's not entirely off the table, but it doens't seem to me like the implementation of layer tracking in the tectonic process would be more than a x2-4 performance hit, especially if done correctly. None the less, this idea definitely isn't off the table. It's worth while to at least re-visit with new eyes.

@oldmanmike - I definitely see some overlap, though we have slightly different solutions to the same problem.From the design document:"Simplified, quantifiable objectives, in order of importance are:-As-good-as-vanilla micro-terrain(looking at scales of up to ~40x40 blocks) with caves -Realistic ore and mineral generation via geology -Rainfall/temperature based on geography -Modular coding(core), so it is maintainable and extendable -Minimum hardware requirements of dual-core CPU & 4GB RAM, recommended specs of quad-core CPU & 16GB RAM. -Avg. gen time (using recommended specs) for a 32,000x32,000 world of ~5 hours -Linux & windows compatibility -Realistic rainfall/temperature/climate based on geography, meteorology, and flora -Better-than-TFC micro-terrain using erosion -Better-than-TFC biomes/trees/plants and soils based on climates, geology, etc. in large regions. -Better-than-TFC caves based on rock type & geology. -Avg. gen time for a 64,000x64,000 world of ~2 hours -Misc unique features resulting from unique erosion (flood-based, glacier-based, wind erosion, etc. resulting in features like the grand canyon, Yosemite valley, sand dunes & rock arches, etc.)" That said, I am not completely set in this list. I've actually decided to at least temporarily open up the design document for public viewing via a link (it's on google drive). I am also allowing comments for now, we will see how that goes. The link is here & added to the original post: https://docs.google.com/document/d/1ZKugZXUvFdJRVa5lZAMPg7Z9OK2vr87MtSgHFXtEsVQ/edit?usp=sharingIf you comment, it would be preferable if you were to leave a signature of your name or forum handle.@Euphoric - OK, so I perhaps did not cover these specific points of execution as well as i could have. I honestly wasn't expecting as many programmers to pop up as have! (Not that this is at all a bad thing! Just pleasantly surprised.)iirc, the furthest an explorer in TFC & Minecraft has roamed from my poll of about 30 explorers (players who specifically love to roam and explore) was +/- 90,000, with only 2 above 30,000. 30,000 blocks takes a full two irl hours of walking completely unhindered in a straight line. In practice, even with horses, it will take at least twice that time.I have also run unit tests as high as 4096x4096, which does take about two hours to run. However, the intention actually never was to use the tectonic heightmaps in a 1:1 implementation. Rather, they would then be interpolated (from our initial tests 8:1 works fairly well). At 4096x4096 with 4 pixels per square chunk (for an 64:1 block:pixel ratio), you have a world which is over 32,000x32,000. Only hardcore explorers would roam past the edge of this map. Moreover, is it really so bad if you find the end of the world? I think of it more in terms of "Have you run out of places to explore?" Note also that the unit test did not utilize multithreading or GPGPU technology, and have plenty of room for more optimizations.The exact method of interpolation is still up for discussion, but bi-linear with falloff was looking decently promising from initial research. Once interpolated, a micro-scale erosion operation would be done, either using a single advanced pass or multiple simpler passes. This is also when trees and flora would be populated precisely.Funny you should mention Voroni diagrams; the proof of concept code I use implements a variant of them to generate the plates' shapes initially. But no matter what noise you use, there are some things it just can't do. Uplifted strata? mid-continental and coastal ranges? metamorphic rock placement? Granite plumes? mass-scale erosion? (tectonics important for uplift compared to erosion rates being miss-matched). I'm not completely opposed to noise and fractals, but I think that Tectonics produces results which they have not yet matched.Erosion is DEFINITELY a very, very major aspect; the plate tectonics just give good data in, so that the subsequent erosion can give good data out. Erosion is what players will conciously see, so it is important. But it is also easier; there are lots of erosion algorithms and code. Comparatively there is very little for plate tectonics.Thankyou again to all of you voicing and offering support! I will follow-up with another post once I am off work giving more thoughts on what i have so far, and how you all can fit in!

Ah! Thankyou both for your support! @TowerOfGlass - Sounds great! I'll be sending you a PM shortly so we can discuss things like methods of communication. I too have actually loved the idea of plate tectonic/realistic world generation since long before minecraft! It wasn't till TFC that I really felt driven to make it a reality (also, wasn't till the last couple years that I had sufficient coding experience to think about it either xD). I look forward to talking more in the near future! @Tsuarok - Thanks, encouragement always helps! I can keep you updated as the project matures if you are interested in helping test things out. Interesting that you mention World Machine; I think the erosion procedures in that program are among the best there is. Thanks for reminding me of that! I wish I knew some of their equations, or maybe some way to pipe the output into World Machine and have it apply a few universal filters or such. If anyone has any questions or comments just let me know!

Hashing with the player name and not using the seed would solve the issue, but then make it the same every time. Hash the player name with the seed and you only prevent sharing of seeds, not re-rolling. And, as mentioned before, you have now added another level of complexity to the implementation by developing said name retrieval and hashing, in addition to the base requirement of the taste system and personal taste variant system. Not saying it can't be done, or ultimately that I personally care if you want to minmax RNG. I'm just saying 'one step at a time.' So Taste system first, then personal tastes IMHO.

@AllenWL - As mentioned, the numbers are off slightly. Now that I've had a chance to look up all the food types available, you would have to MANUALLY set values for all other ingredients with each ingredient. this is 55 value ranges set by-hand for 55 ingredients, which is around 1500 values you have to set by hand. The next ingredient you add to TFC will need 55, the next will need 56, and the next will need 57, etc. In the current system, no value ranges for anything are set by-hand; a code blindly, randomly crunches out if a combo is good or bad. The model I propose would take 275 value ranges, and the next ingredient will take only 5 more, and so on. Also, note that TFC devs (and many players) actually very much like that recipies are not fixed; you cant load up a new world and look for meat and potatoes every single time. This is just part of TFC, and asking it to be different than that isnt really on the table right now as far as the devs are concerned, and I more or less agree.I'd like to also point out that TFC marginally benefits you for using common knowledge. But advanced knowledge will give you a great leg up (how do you shape metal? What rocks do you find iron in? how do you make leather? etc). Similarly, how everyone in America would know steak and potatoes go well together, few would know WHY.@Kittychanly - good to know about the 4-ingredients. Ultimately though, I don't think the issue/suggestion is concerned with the difficulty to find good recipies, but the lack of interesting mechanics attatched. Even if the slot machine pays out 50/50, you still are just pulling a leaver, not using your brain As always, let me know if I could be of help in making this a reality, should Bioxx/Dunk approve of it. I am an experienced python/C++/C# coder, but am rather inexperienced with Java. Never the less, I do have experience modding and working on game design documents and indie projects.

@chocmerc - while it's true everyone has different tastes, this is usually cultural, which is a good case for randomizing based on seed at least. I just don't want to over-complicate the system is all; one thing at a time, you know? @trancengopher - As above, I can see where that would work, but I'd call it more of a bonus feature than a good base line feature. It would be far better to balance the taste experimentation in general first, then move on to individual preferences and moving targets, no matter how minor. @AllenWL - My described system is mostly complicated when looking at how the computer handles it; it looks like massive arrays of numbers and boring statistics. It would play out not unlike the system you describe in practice. I'm open to other ideas, but giving every food a compatibility with every other food? You do realize that's somewhere around 380 value ranges total, right? Assuming 20 ingredients, with 19 values each, that is. Under the system I recommended of 5 fixed tastes, that would be 100, and as new foods are added, it would be scaling linear as opposed to exponential. Another thought; it was brought up before that player-specific preferences are a highly exploitable aspect; why not re-roll till you get a common food type or combo attached to you for example? Player-taste is a whole extra set of new code over what we have now, whereas seed-varied recipes based on a taste system would be relatively little coding, and mostly design work (which us non-java-literate moochers can actually contribute to with research and number-crunching). Honestly, I'd just like to see Taste-based cooking period. And knowing indie development, we honestly should be happy with that for now (This is nothing against Bioxx/Dunk: this is coming from someone who has done mod work in the past for other games; it takes time and effort, of which very little is really 'fun', so I always try for 'better' first, 'ideal' later, and am appreciative of whatever I get, no matter how small). Personalized taste is an extra layer on top of the proposed system functionally, and would require more code. You may notice that most ideas which actually get implemented in decent are the ones which add the most to the game, with the least amount of work. (also whatever the modder likes most, which, it's their time, so I think it's completely appropriate). I'd like to avoid 'feature creep' as we call it in the biz, lol. A final note: I call it Taste rather than Flavor because Flavor is scent-based, and Taste is what you sense with your tongue. There are over 25 known scents which impact taste perception, so yeah. That's also why loosing your smell kills your perceived sense of taste usually. EDIT: wow, am I a broken record much? Sorry, I'll have to re-write this later to be less repetitive...

Hey Bioxx! Glad to hear your feedback on this! Yeah, it would be a LOT of numbers & playtesting. If the numbers could be altered in a config file (at least for development purposes), volunteers could work to find and balance numbers, I think. I certainly would be willing to put in a good amount of research and testing. As to the individual tastes, those could, in theory, set the target numbers. The problem you face then is that you are trying to hit a moving target with changing darts. Generally, I have noticed individual taste tends to be a preference more than a major thing, especially when a skilled cook is making the meal. It also would make it harder for a community to have dedicated cooks, as it's very likely that an excellent meal to one player could be a terrible meal to another.

This sounds like a fun idea for an add-on, but not so much for the main game. too detailed and complex, with too little purpose. none the less, if someone made an add-on of this, I would use it! xD

Animals make good food sources, but iirc, they don't respawn in TFC. So yeah, killing wild animals gives a good bit of food, but they aren't renewable. I think it's a fine tradeoff, and plenty realistic. Though raw meat really should require preserving of some kind within 2 days or it will go bad; I agree with that idea. Even just having to cook it immediately would lengthen it's shelf life to a good bit more, depending on climate (irl, anyway).

I like both the idea of jarred/bottled preserves and dried fruits. They could behave more or less the same as normal role (maybe with some minor drawbacks, or not), so no increased complexity; just preserved. +1 to this idea!

In regards to Nutrition changes;While less accurate, I am actually totally fine with the existing protein, fruit, vegetable, grain, dairy set-up. Generally, eating a good balance of 4-5 of said food groups will give you all the nutrients you need to stay healthy.Accuracy isn't really what TFC is about. I originally thought this, but honestly, too realistic of a game becomes "why not get up, go outside, and do it IRL?" From what I have experienced firsthand of the mod and heard from devs, they make it realistic-like in most cases so that it's intuitive and fun, not just to be realistic for realism's sake.For that reason, I think the 5 food groups are adequate, at least for now. I would much rather keep focused here on how to make food prep intuitive, dynamic and fun, as opposed to it's current state of slot-machine gambling.In regards to the original topic of food prep:I think the best solution would be to use the 5 taste types, and make simple combos the easiest, but the most limited. for example, sweet + sweet = sweet. this is usually fine, and hard to go wrong with. salty + savory(umami) is also generally safe. But then you have Sweet & sour, Sweet & savory, sweet & salty, etc. These are more tricky and difficult, and where the idea of making your cooking skill provide margin of error.A detailed example:Lets assume the following:Plumbs & apples have a sweet range of 60-100%, 5-40% bitter/sour, 0-20% salty/savory.Oranges are 40-70% sweet, 50-160% sour, 20-100% bitter, and 0-20% salty/savory.Beef has a range of 60-120% savory, 0-60% salty, 0-20% sweet/bitter/sour.Potatoes & squash have a range of 20-60% savory, 0-50% salty, 0-20% sweet/bitter/sour.Milk has a range of 60-120% savory, 10-50% sweet, 0-30% bitter, 10-30% sour, and 0-20% saltySugar Cane: 100-200% sweet, 10-30% bitter, 0-20% savory/sour/saltyLets say in a particular world seed, the stats are as follows:Plumbs: 90% Sweet, 20% bitter, 10% sour, 5% salty, 0% savory.Apples: 60% sweet, 15% bitter, 15% sour, 10% savory, 0% salty.Oranges: 50% sweet, 30% bitter, 120% sour, 20% savory, 10% salty.Beef: 10% sweet, 15% bitter, 5% sour, 90% savory, 40% salty.Potatoes: 5% sweet, 20% bitter, 0% sour, 30% savory, 40% salty.Squash: 20% sweet, 0% bitter, 5% sour, 55% savory, 20% salty.Milk: 30% sweet, 10% bitter, 15% sour, 80% savory, 10% salty.Sugar: 170% sweet, 25% bitter, 0% sour, 20% savoury, 5% saltyNow, lets say we got all these in our minecraft world, and started experimenting! You aren't much of a cook, so when you taste them, you get this:Plumbs: "these taste sweet"Apples: "These taste sweet"Oranges: "These taste sour"Beef: "This tastes savory"Potatoes: "This tastes bland"Squash: "This tastes savory"Milk: "This tastes savory"Sugar: "This tastes sweet"Like the prospector's pick, you can get somewhat inaccurate readings. But unlike the prospector's pick, you can't try again till you have more skill! To compensate, it's never completely wrong.Moreover, 'salty' and 'savory' are often indistinguishable to those less perceptive. this could also apply to 'bitter' and 'sour' too. Thus they get lumped together at lower skill levels.Now, given this information, you know that sweet things usually go well together, so you make a sugary fruit mix!(4x sugar + 2x apples + 2x oranges + 1x plumb = 1030% sweet, 210% bitter, 280% sour, 140% savory, 40% salty) And you taste the dish....."This is terrible! Too sweet!"Because it had over 900% sugar (meaning more than 100% per ingredient average), it's become a sugary mess! You don't know the numbers, but you figure sugar is really strong usually, so you first try swapping that with something else.You swap sugar and oranges, and try that:(4x oranges + 2x apples + 2x sugar + 1x plumb = 650% sweet, 220% bitter, 520% sour, 140% savory, 65% salty) And you again taste the dish...."This is bad. It's sweet & sour, but not quite right."This time it was a poor dish because the sweet and sour tastes were high, but not perfectly balanced. It was too sour for a purely sweet dish, and too sweet for a sweet & sour dish. It's also slightly better than the last dish; the combo should work, and with enough skill this dish would be OK.At lower levels of cooking, the margin of error is harsh for multi-taste foods, so you need +/-50%, and both need to be above 500%The player doesn't know what level of taste his foods are at, so it's very hard to get it just right. But you weren't going for that anyway, so lets swap plumb and orange, cut down the sour.Lets try plumb, sugar, apple, orange, because we don't want it sour.(4x plumb + 2x sugar + 2x apple +1x orange = 870% sweet, 190% bitter, 190% sour, 80% savory, 40% salty) And you taste the dish once more...."This is ok, a nice sweet dish!"Success! you're still not a skilled chef, but some brains got you an edible dish, which is better than the sum of it's parts.This happens to be a really good combo, at just the right sweet level without going over.That was but one example.Why do I propose this? Because this is more or less how real cooking experimentation works. You can either randomly throw things together like a child, or you can combine, taste, adjust, taste, combine, etc.Over time you will learn your ingredients, and just kindof 'know' what things will probably go together well.Obviously there would need to be lots of numbers tweaking, ironing out details of what the good combos are, balancing the randomized values to make it so no seed is too hard, etc. But I think this would be exceptionally fun!

While I like this idea, I don't know how much it would bring to the game. Once Alcohol is introduced, that was generally used as the preferred water source of ancient cultures (or watered down alchohol), which is made with fruit or grain and water. I personally think that would be enough. If it's just a line or two of code though, sure, I'm all for this!

Would just like to add a bit to this suggestion and concept.I must echo sentiments of the posters, but elaborate a little on a good alternative.Cooking should follow a loose fixed system; for example, IRL, there are 7 taste types which we can perceive:sweet, sour, bitter, salty, umami (savory), pungent, and metallic.If the game had these (or even just 3 or 4) the amount of each per raw ingredient could vary seed to seed. (This is just an example; not saying the game needs to mirror real life perfectly or necessarily at all)For example, fruits would always have a 'sweet' aspect, but would each have pools of possible other tastes (possibly with weighted likelihood).This is much like how ore probably spawns in several given rock types, but digging around in just one area doesn't guarantee results.Then, by adding a 'taste food' operation somewhere, you could see what the ingredient is like. The accuracy could even be based on your cooking skill!There could then be fixed targets for cooking with certain ratios much like metallurgy.The quality and margin of error could improve with skill as well.Without rhyme or reason, it is a game of slots now, and not even an interesting one any more.Before, there were all kinds of effects which rewarded you for playing the slot machine. Now you simply find something relatively common to what you have, and meets the food groups, and call it good.I don't think anyone is asking for cooking to be the same every time, or for something overly complicated. Just for some kind of puzzle as opposed to 'combo 1, nope. combo 2, nope. combo 3, yep.'What are thoughts on this direction?

Just wanted to pop in here....I love TFC, and I think 3 months is fine. Really, whenever you feel like it is fine. But, I would like new builds within 6 months. After 3 months, I usually am pretty bored with the current TFC/Minecraft build, and ready for something new. But I dont mind just taking a break for a few months either. We're not paying you for this, it's your hobby! As much as I would love to harass you for updates, it's just not fair to do so. That's my thoughts, just wanted to say again, thanks for such a unique and epic minecraft mod! Truly, it is how minecraft should have been.

So, honestly, I love this mod. I love how difficult starting out is, I love how particular farming is, I love how you have to build real mines, and how your inventory stack sizes are microscopic (compared to normal minecraft). BUT. I have no love for world generation of iron. I have dug for over 1500 blocks in each cardinal direction from my home town at elevation 60, and found 8 deposits of cinnabar 7 deposits of saltpeter, 4 deposits of talc, and one small deposit of Hematite just enough to make two anvils. I am all for hard. finding fruit trees is hard. making it out of a cave alive is hard. Finding iron is just plain frustrating to a degree which rivals MMO grinding. I have mined through about 3000 blocks of rock which can contain all the iron clusters, and 3000 blocks of igneous rock which are said to contain hematite. In addition, I have explored (at great risk and determent to my health) 4 cave systems. I am a believer as much as anyone in a 'realistic, difficult experience', but this isn't realistic (there are ways to identify likely locations of iron, and it is fairly common. In fact, it's common nature is why cultures moved from bronze to iron, because it was more common. And further, I don't see spending 40+ hours digging in a straight line as a 'fun' mechanic. Am I doing something wrong? Or does the world gen sometimes just screw you over beyond recovery? I've seen the ore generation numbers before (no, I wont post them), and cinnabar is about half as likely to spawn as the iron ores. What gives?

I just wanted to pop into this thread and mention some of the things I have encountered in my THaumcraft & TFC endeavors. First, I am using the Essentia Everything add-on for Thaumcraft to add native essentia values to most things TFC (will share when done in a week or two.) Second, and more importantly, there are a couple portions of Thaumcraft that are broken, and far as I can tell, can't be fixed. First and foremost is Aura. I know it's getting reworked/removed from the next thaumcraft, but that's then, and this is now. Aura nodes do not generate, even with node regeneration enabled. This is nice in that you don't have to deal with flux, but kills the top-tier things which work directly with the aura. Third, and second broken aspect, is damage. TFC weapons deal about 40 times base Minecraft damage, which Thaumcraft is scaled to. this means that both thaumcraft armor and weapons are about as good as your fists and being naked. Fourth, things like the hellfire furnace serve no function in TFC, as the vanilla furnace is removed, which they are based on. I post these problems not so much saying Thaumcraft will never work with TFC, but rather hoping someone comes up with another brilliant solution like was proposed here. If anyone has a solution, particular in the realm of armor/damage or aura gen, please let me know.

So, to share some insights into farming (if this is not something the devs want posted, please feel free to delete this thread.) First, I have observed that when the temperature falls below 0, crops die, usually in winter, but occasionally you can get a early spring/late autumn freeze which kills them. The crop death isn't instant, Second, If no one is on the server near the crops during the freezes, they will not die. Third, crops have wildly different growth times. corn takes what seems like millenia to grow, while onions seem to take a month or two. Fourth, crops seem to not grow when the temperature is too low. But more importantly, they still consume nutrients. So, even if your plants don't freeze in the winter, they will have no nutrients come spring to grow properly. Now, with that information, I was able to put together a very nice farm with 3 tiers, plant in the spring, harvest in the summer and fall, and do reasonably well with my farms. Use that knowledge as something of a guide, if you will. Now the real anomaly to me is how some plants like tomatoes and bell peppers remain after harvesting. this seems doubly pointless to me, first in that by the time plants reach maturity, they have already depleted the soil of nutrients, and second the fact that they will die in the winter anyhow. Perhaps I am missing something? or maybe this is for planned uses of gypsum and other minerals which really are only used in agriculture AFAIK. Just thought I would post some of my various thoughts on the matter of farming. Overall I love the realism and detail put into farming, and look forward to more features such as depleting water levels, and fertilizer options. One thing I do hope for that probably isn't planned at this time is that perhaps some day we will be able to build a greenhouse which keeps plants alive in winter. Well, that's about it. Hope this is helpful to someone out there, and I didn't violate any forum etiquette about not spoiling stuff from the game.

Just wanted to say thanks for an awesome add-on! It has inspired me to start coding some add-ons of my own.

-please delete this accidental post-