DanNetwalker

I think I didn't found the right words... I see redstone as an interesting toy to play with, but it's not what you would base your technology on if you happen to be developing dwarven technology for your small society. You need something more versatile, useful and reliable than some magic torches and red dust lines on the ground. The model of steam I designed is basically something I could both tinker with as a toy and I would use as the foundations of my battle base, even you could go McGyver with it. Being steam pressure the blood on it's veins, there's a natural limitation on what you can do with so much resources; big scale projects will need some serious engineering, as there is a lot of details that needs attention: steam leaks or exausts that will get trapped in the structure (and remember, it's hot and will burn players in their manteinance round), extra supports needed for long pipes, and the classic "how the hell do I fit this two things one near the other?". Functionally, it's a step forward from redpower, since it's an analogic system on heart. It could allow all the things that redpower let's you to do and far more, but at a cost that redstone doesn't have: you need to keep fueling the machine for it to stay alive. Even more than that, the pulleys, engines and such can be balanced so that they need more steam pressure to do a bigger job. There's a potential for too much automation? Not really... at the end, you stop doing the job the machine does, to start working on keeping the machine working. But maybe I'm biased... what do you think, people? Any thoughts on it?

Pipe size could go anywhere from a 1 block pipes that you join, to "I needed some serious steam production, so I digged this 5x5 tunnel into this volcano and got crazy". If we skip the steam pockets as part of the circuits, it would be just another IC but with steam instead of electricity. Maybe I thought of this too bigwise... It could need to interconnect with the mechanics system, too (axels, pulleys, etc), so it needs some serious features. You have to admit it has more potential than redstone... EDIT: no, seriously, I'm starting to consider learning java again and getting a moder to help me with this if it doesn't end up as part of tfc, so that technical mod minecrafters can give it a try. I see lots of potential... The servo valve, and it's sibling the pressure limitator, are kind of needed if this system is going to take the place of redstone. After all, this is something kind of analogic, so the redstone not gate equivalent has to be more flexible. We can't just give a "false if steam, true if not" thing, since we have a very long range of pressures. By mergin them with release valves we can create equivalents to the redstone relay gate, and even things that can't be done right now in vanilla. I just though of systems made of steamworks, and what could be needed, but I'm possitive I'm missing things... (pressure indicator blocks, like gauges? wistles?)

Ok, maybe I'm a little byased after playing long with industrialcraft 1 and 2, but let's try. Basics: IC2 uses packet size to determine if a wire carry too much voltage for a machine. With steam we should use pressure.A steam conduction will act as a whole; all the static steam blocks, end of pipe blocks directly touching a static steam block, steam pipes directly in contact with those end of pipe blocks and several steam mechanism will act as a unified conduction (they will share a "steam circuit id"). This means:all of the blocks that form the conduction will have the same pressure.A boiler pushing steam into a pipe will rise the pressure of the whole circuit.A valve releasing pressure from a pipe will decrease the pressure of the circuit.A hole in the circuit (a place where the steam touches air blocks) or a leak will make steam blocks to escape, releasing pressure too.Steam is hot. This means it should melt ice and snow, and should burn players if touching directly.Certain materials will only hold for a max pressure:Tunnel on solid rock: any pressure; the tunnel will fill with steam blocks.Rock block with a hole throug: high pressure, but it won't keep up it's own weightSteel pipes: high pressure, it will hold it's own weight for up to 8 block long pipesIron pipes: medium pressure, it will hold it's own weight for up to 8 block long pipesbrass pipes: medium pressure, it will hold it's own weight for up to 4 blocksClay pipes: medium pressure, it will not hold it's own weightSteam pressure functionality:Connected pipes hold the same pressure from end to end.Any boiler connected to a pipe will rise it's pressure as long as water and heat is provided.Any open pipe will release pressure, in a speed that depends of the type of open end, until it reaches 0 (meaning "same pressure as open air"). Open pipes would release "steam blocks".Pipes reaching more than 80% of their max capacity could show "steam leaks", meaning it will be visible a small graphic effect, and a small pressure release will occur.When a circuit' pipe exceeds it's max steam pressure, there's a probability of the pipe exploding, releasing pressure from the circuit and causing some maihem arround. Who said steam was safe?Steam block functionality:A steam block has a pressure, determined by the pressure in the pipe that released it.In contact with open air blocks, both moving steam bocks and static steam blocks lose pressure once each certain time; if it reaches pressure 0 the block will dissapear.A steam block falls up, like a sand or gravel block, but upwards. It will stop going up when it hits a solid block or reaches build limit height.When going up, if a steam block hits a stopped steam block, it will "join" the "steam pocket" by placing itself next to it. This means joining both it position and in pressure:position: it will look for all the stopped steam blocks touching the one it hit. Then it will try and find an air block touching the top face of one this steam blocks; if not found, then it will tryone of the sides of the blocks in the upper layer, then in the next, then in the next, until it finds a position with air touching the "steam pocket" or no place is found.pressure: all pressures of the steam blocks sums up, then it's divided by all the blocks the steam pocket ends up with. For example, a pocket of 7 steam blocks is reached by a new one. The pocket has pressure 4 in all the blocks, and the new block has pressure 10. So, the new pocket will be 8 blocks in size, with a pressure of ((4 * 7) + 10) / 8 = 4,75. If there were no room for the new block, then the steam pocket would end up with a pressure of ((4 * 7) + 10) / 7 = 5,43If the solid block is removed from a position touching a steam block, or if a steam block joing a steam pocket ends up with an air block over or next to it, it will take the position of the air block and start "falling up" again, and one of the steam blocks of the pocket with a lower coordinates will take it's old position a moment later. This allows for a steam pocket to leak entirely through a hole in the conduictsteam pipes and related:normal pipe: it's just a conduict, nothing more. It's part of a circuit, but it can't release steam except for the leaks when over their safety capacity.end of circuit pipe: same as normal pipe, but with a square border the size of a block that acts as a isolation junction. It will release pressure creating steam blocks"crossroad" pipe: 4 or 6 pipes from 2 or 3 different steam circuits can join into this block will cross withough joining the circuit. This means, the circuits will stay appart even when they share this block. Graphically could be seen as pipes going arround one of the other.Steam mechanisms:valve: esentially splits a circuit into two, and controls if the pressure is shared between the both or not. it may be operated by redstone signal or by hand"servo" valve: same as valve, but triggered by the steam pressure received in a control inlet. the player can configure a minimal open pressure (that can be 0) and a max open pressure (that can be "whatever you can hold"); this way the player can tune it into a "open when receive pressure", "close when receive pressure" or a mix of both like "open when pressure between this two values". by connecting the same circuit to the control and the origin inlets it can be used to prevent a pressure too high is sent to the destination circuit, or as a one way only pipe (steam equivalent to diode).pressure limitator: similar to a servo valve, but it's configured for the destination circuit pressure instead of the origin circuit pressure. It can be defined a min and max pressure, so that the steam crossing to the destination circuit will stay between that limits. Allows to disable a circuit if not enough pressure is on the main one, a kind of analog to digital converter, or to feed a low pressure circuit from a high pressure one (kind of like a IC2 voltage converter)release valve: like the valve, except it's one way only (there's an origin and a destination circuit) and it works automatically; the player configures a max pressure, and the valve stays open, releasing steam pressure to the destination circuit as long as the origin circuit has a bigger pressure than the configured limit.pressure detector: this mechanism generates a redstone signal when there's pressure in the circuit it's attached to. both minimal and max pressure is configurable the same way as a servo valve, to allow for similar functionalityboiler: it increases the pressure in a circuit. it may be active (as a vanilla furnace, with room for water and fuel), or passive (takes water and heat from the world blocks; any heat source and water source touching the boiler block is converted into steam pressure)engine: turns steam pressure into mechanical power. for example, moving a forge bellow. there's room to connect here to the mechanisms idea, or...third party integration mechanisms (possible but not needed, maybe as a plugin):air pressure pump: creates bc energydinamo: creates ic2 energyEDIT: had to reedit; the thing got crazy and html tags appeared all over the text... wtf!?

As hard or easy as having two new toys: a steam valve (turns redstone signal into steam force), and a "steam level" (some kind of steam controlled level). Seriously, Crysyn is right; this needs to go in it's own suggestion... everybody with steam ideas, please redirect to this post: http://terrafirmacra.../topic/5-steam/ I've started one of my concept analysis, this time about how I see steam system working (bottom of first page). Care to check and discuss anyone?

The firestarter is cheaper than iron and flint, so I whould recomend it. Also, I must insist only unprotected torches should burn out.

Like that was a bad thing... besides, all that noise means this topic may be more interesting than we thought to begin with. For example, I didn't saw a good thing to force by code to migrate. But, what if it's the player actions' consequences? This evening I got a flash of an idea: certain actions could modify the type of biome. If a player burns down a tropical forest, the sucessive rains could erode the grass under it, removing the dirt and turning it into a desert. Land filling the sea could turn an ocean biome into a plains biome. If a player takes all the water out of a swamp, it could after a time turn into a taiga. All that kind of things. With such a functionality in place, a careless lumberjacking player could force himself to look for another forest. Or to repopulate a plains back into a forest. It could be a matter of counting how much trees, water blocks, sand blocks, etc, are in an area to get certain numbers: humidity, heat, vegetation cover... I haven't made the maths so I don't have a clear idea of what the algorithm should be, but I see potential.

Look, there's a difference between "I turned down the extra lightning because my computer can't handle it" and "huh? other people can see my torches while I raid their castle? how? a mod you say?". I'll say something inapropiate, but here in Spain there's an old saying: "o follamos todos o la puta al rio" ( = "either we f*ck everybody or the b*tch goes to the river" ). It's simply not fair some people get that edge, when it could be easy and a great addition to put it in the mod. Kind of choosing between having no law and waiting for someone to put their own rules, or writting our own law so that everybody has the same rules. And besides, there's no server side lighting for the torches in hand. The server already tells the client what object is holding in their hands each player and their coordinates, and that's all the information the client needs to add a new light for each player. Just one for each one. Nothing compared with those 200x200 castle with torches all the way arround the wall...

Correct. The server tells the client "there's a light source at coords x, y, z, of this colour, this strong", and the client does the maths. By clientside, I think Jivix means static sources of light, like placed torches and such. The thing is, there's really no difference between two or two docen players. The server already tells the client what object each player is keeping in their hands. The client just adds the relevant sources of light to the list of light sources to render, and that's a job for the graphic card. At the end, the real problem I see in smp is not the 20 torches the players are sporting, but the 2000 torches placed on the castle's walls.

If there's a single mod where a realistic texture pack has sense, is this one. And your work looks great! Keep going, please!

So we are going to push for having steam technologies, brewing... I can see how this is turning more of a dwarven fortress simulator. If things keep this way I expect a steam equivalent to redpower request soon! :D

Depends. What if the wood rot takes a realistic amount of time, say... three or four minecraft weeks. That's between 21 and 28 minecraft days, that amounts to, what? ( 10 + 12 ) * 28 = 484 minutes... that's about eight real life hours to get the enamel and place it over the wood. Sounds fair even in multiplayer, I think.

'Nother customer happy with the ending! :D Ok, I've been thinking of this mob behaviour thing for some time... As I see it, should we make both the mob behaviour and the migration thing and the nests system and all such, there would be a lot of data moving arround. But I realiced a little detail... individual mob decitions could be made just in the chunks loaded at the moment; the rest of the interactions (or, at least, the interactions between wild mobs) could be simulated by numbers, as total population blocks. For example, I could say "there's 15 wolves and 7 sheeps in this sabanna biome chunk; then in the chunk just north, is a plains chunk with 30 sheeps. I throw some dices for randomness and I get 5 sheeps are hunted by the wolves this minecraft day, and tomorrow they will migrate north, both the wolves and the sheeps, because there's way more food up there". BONUS TRACK: I must think harder about this thing -and I don't have time right now-, but maybe this could be made for biomes too. As in "there's 50 trees in this forest biome; chop half of them and it turns into a sabanna biome. Chop them all and it will slowly turn into a desert biome (eacht time it rains it will degrade the soil)". Or the reverse, irrigating a desert biome into a sabanna, or planting enough tropical trees into a forest to turn it into a rainforest (very very slowly, I'm thinking of several game weeks or more).

So, there's going first a list of desired animals, then you will figure out what can be usefull of them? Then I suggest you to check atmosmobs mod: http://www.minecraft...s-finally-here/ Many interesting creatures to get inspired of... ( I want owls in my forests! )

10 feels like too little, but I like where your idea is going. Maybe we could simplify by grouping the thing into "vitamins", "proteins", "fat", "carbohidrates", "water", "fibre", and give each one of those a bonus and a penalty. Too little of the thing, you endure the penalty, enough of the thing, you get the bonus. Then it's easy to give one or more groups to each food item. ( Hell, if they feel crazy, they can give an integer value for each category for each food item, as in "the content of this bread is 50 carbohidrate units, 10 fibre units"; then each certain time, those numbers are decreased. Even, why not each time a player does something, a small amount of those are "burned" away... ok, this is starting to look scarily close to my diet plan )

honestly? the click mining isn't very easy to exploit in pvp, so I don't see it very important. However, that dinamic lighting mod IS fairly exploitable, because: it's client side, and only for the people that has it. if I throw a torch down a mineshaft to check if there's someone down there, I can see the increased light as it falls, and the sudden darkness as another player picks the torch. th other player has a harder time noticing the trick, if they ever notice it at allthe bright item list is client side. nothing prevents me to add the swords or the bow to the list of things that make you bright in the night, which suddenly turn you a little more inmune to night ambushes and make you more aware of other player's movements See? too much room for exploiting... this should be inside the total convertion, factory tuned for the right list of items, and not configurable by the player. Only that way the feature is fair for all the players

I could bare something like "too many bites from spiders or zombies make you sick, and you will need some antidote". BUT ONLY (and that's a big only) if you would get inmunized for some time after that, the infection heals itself after some time -instead of being forced to look for an antidote-, it's just a small nuisance instead of a common game over condition, AND it's toggleable in the difficulty configuration.

Oh my godness don't tell me this is serious... status bars for all that info? We are going to need a bigger screen, timmy! No, seriously... why as bars? Can't we make an icon, the height of the hunger bar, appear next to or over the hunger bar? Or on the left/right side of the screen. I'm thinking on something like the hazzard icons back to Halflife 1 gui. You are cold out there in the tundra, then a "cold hazzard" icon appears, or a "hot" one for places like the nether or deserts. You know, bars for all that is a little too much info, makes it too complicated to use. EDIT: and as Watsisname said, this is an information overload, since a lot of that is allready achieved by immersion in the game ( players doesn't need a "I'm happy" feedback, since they are already feeling happy themself... adding it would remove value from the game, rather than increasing it )

Ok, I've think about the progressively challenging enemies and the concept of nests for a pair of hours (my girl took the tv set hostage again, so nothing of interest to shut down the head with), and I think I got a model for the nest idea. Care to take a look and elaborate the details? Each nest needs several data: ID: the nest number, assigned when generating the world map. "The first nest, the second nest, the third nest...".Position: it's location in the worldPopulation limit: a nest can unkeep a max number of mobs.Adult population minimal stock: it's the minimal number of adult mobs needed for the nest to keep producing young mobs.Adult population limit: it's the number of mobs expected to stay near the nest. Exceding mobs will randomly go away from the nest.Mob type: I bet no skeleton archer will want to share the nest with a family of wolves. Extreme case, but you see where I'm going to.Each mob type whould need this extra data:Age expectancy: how old are the mobs of this type expected to live before dying or despawning.Age of maturity: how old this type of mob needs to be before turning adult.Each mob should have some data too:Nest id: the number of the nest the mob is attached to. It may be the nest where it was born, it may be an abandoned nest the creature took as a home. Mobs sharing a nest id are in fact the same "family".Age: how old is the mob.Max age: it would be the Age expectancy, randomly modified on spawn (some mobs will have less, some will have more). When a mob reaches this age, it will die or despawn. Certain effects like poison or burns could decrease this number, or increase in case of healing or similars.And this would be the new behavior for the mobs:A young mob stays close to the nest. Don't wander more than three or four blocks from the nest block. Once the minimal time for adulthood is reached, the mob turns adult.Once per minecraft day, each nest with enough adult mobs and enough room for more mobs, a certain number of young mobs will be spawned. The number depends of the type of mob.If a player attacks a nest, all the adult mobs attached to that nest run as fast as they can to protect it. When close to the player attacking the nest, they surround and attack the player. Ok, maybe surround is a behavior a little advanced, just all the nest attacks the player, at once.If a player attacks a mob, all the mobs of the same family closer to a certain distance will attack the player.If a mob has no nest assigned, it looks for a nest of the right type or an abandoned one (zero population); Choose the closest nest with spare space (the one with bigger difference between population and population limit that is reachable and go there. Once the mob reach the new nest it gets assigned to thas nest.On map creation, nests are deployed. Each has a unique id, a random number of adult mobs, and a random number of young mobs. Each day, a random number of young mobs spawn in the nests, as long as there's room for them (max population not reached), and young mobs die if there's no adult mob assigned to the nest (this allows the player to "slay the fathers to destroy the nest"). If max adult population is reached, the exceeding will migrate away. Mix all of this and you got a pretty realistic system. Mobs will stay alive for a time, then die, in a less predictible pattern than the "wait xx minutes". Since they appear on the nest and then spread, the location of the creatures look more natural, and a bigger mob density will hint for the existence of a nest. Fighting players have the chance of purguing a nest, but not as easy as filling the place of torches and running away for a while: you have to kill all the adults, and either let to die the young or slaying them too, and that doesn't prevent the nest from being repopulated. Mob spawn limit whouldn't be decided globally for the chunk, but from the sum of the nests' max populations, so there's no way to tell how much mobs there are out there withough looking at the debug info (maybe there's one nest, maybe there's two docens). Of course, a particularly jinx player could manage to anoy enough nests to get an army after his blood. And once every certain time, or when speciall conditions are meet, certain types of nests could get angry with the player. This allows for undead assaults on new moon, spider attacks when too much charcoal pits are burning at the same time, wolves attacking if too much raw meat is stored or transported...

Tell me when you want to start translating to spanish, too.

So, let's say... The game should store how much food items a player has eaten.A sum of the total items is stored, too. So that it can be known what percent of your diet is each food item.Each time you eat a food item, it's checked how much percent of your diet is that item: less than 25%: extra half food marker. Placebo effect due to an exotic food, I suppose...between 25% and 50%: normal effect.between 50% and 75%: the food replenishes a quarter less food markers than normal.more than 75%: the food replenishes half as food markers than normal....hmmm, careful, the food items list can get big fast, and this data structure with it, too.But it looks like a good idea, though. You should have some feedback, as if the player where thinking "oooh, bacon again? damm!"; no clear idea of how to do this, anyway...

I got one word for this: Standardization This is something that everyone should have. Specially when the first PVP servers come arround, since it can be an edge over the other players.

Ok, I stand corrected. These have a good potential in the game, and I see the "shouldn't fit in the chest" may work better. Maybe the "planks crate" could store the equivalent of, say, 4 log blocks (since they have a more regular shape, they shoud store in a more compact space).

Sorry, I have a tendency of speaking native computerish from time to time... I hope that has some meaning to the right people, though.

Good point, Antice. BTW, the "nest block" doesn't even need to be visible, since the actual feedback of "there's a nest here" will be the young mobs and the queen or alpha pair that stays there.

LOTR big spider nest.... hmmm. I knew there was something missing. The behaviour I designed fits perfect for mammals, where any adult mob could spawn young mobs, but for a hive type of mob this would be incomplete: we need to mark what adult or adults are the "spawning" ones (the queen and/or king or queens of the hive). And if you want to improve it even more, some of the adults could go a little away from the nest for different roles as hunting, gathering, finding resources... imagine a giant ant mob where some goes out of the nest to find sugar cane and recolect it. Your farms will be in danger if they reach! And an encounter with a wolf wouldn't be forced by AI, but a direct consequence of the wolf looking for food for the nest. I see opportunity of emerging behaviour in this one... And there's the little detail, it should be needed to mark somehow who are the "spawning adults" and differenciate them somehow, both in behaviour (those can't leave the nest no mather what) and in looks (maybe a subtle change in texture, maybe a bigger or different model).