Omicron

Alcohol Battle Mechs? I love battlemechs!

(I am extremely sorry, I just couldn't resist!)

It's generally a good idea to make yourself some knives from your first few rocks and then just cut grass as you run along looking for food. That way you may be able to afford shelter even on the first night... even if it's just a 2x2 thatch heap

That might be a little difficult though to present in a 16x16 texture.

Which makes me think, didn't there used to be plans to potentially convert all of TFC to 32x textures? What happened to that?

Locking game progression behind a repetitive point grind is a terrible idea. TFC has the beautiful aspect of being fairly player skill dependant; if you introduce your suggestion, you put player skill on the backburner in favor of a virtual skillpoint system.

Also, this post should really go into the suggestions forum.

From what I could see and what Bioxx said, I'm fairly sure the graphical representation of skill bars and levels is just that, a graphical representation. Using a progress bar helps maintain suspension of disbelief better than the raw numbers we get to see right now. However, progress bars only work up to certain point values before you stop seeing any meaningful advancement - you may just have gained 30 points from harvesting a large field, but if the bar contains 10,000 points then you're not even going to see a single pixel in difference. Therefore, skill tiers are added, which lets you reset the bar to zero every X points, ensuring that the player always gets a clear indication of his or her progress.

There is potential to tie game mechanics to the skill tiers, but that's an option, not a requirement. At its most basic, it's simply a good way to design a user interface.

Harvesting crops doesn't take skill, planting seeds doesn't take skill, animal husbandry doesn't take skill, digging a charcoal pit doesn't take skill, a pit kiln doesn't take skill....the list of necessary activities in TFC that require no player skill is quite a long one so I don't know that is a valid argument against

I wasn't making an argument against having a game system that is not skill based - and some of your examples could be argued anyway, considering the reliability with which "my charcoal pit won't work" threads keep popping up on the forums over time, for instance

I was making an argument against the argument that making you spend extra time to remove the tree stump would somehow make gathering wood more difficult, as several posts in this thread claim (and in fact cite as the reason we need to have this feature). This is clearly not the case. Woodchopping would still be a fully straightforward, pres butan receiv log affair even with the tree leaving a stump. All it adds to the game is a higher time requirement to clear building space.

A certain level of abstraction is necessary to make a game; it's part of the nature of the videogame medium. Compared to digging a cubic meter of dirt or stone with a shovel or pickaxe, for instance, woodchopping requires a ridiculous amount of time already even with the proper tool equipped. This is, as we all know, a balancing factor for needing to only chop a single block to bring down the entire tree, as opposed to having to chop every individual block. The act of chopping that single wood block is an abstraction of the concept of felling a tree. It can be seen as a stand-in for the entire process of splitting the trunk, watching it fall, clearing off all the branches, clearing off all the foliage of the branches, cutting the branches into usable pieces, cutting the main trunk into usable pieces, and clearing away the stump.

I thought health regeneration only happens when the food bar is at least 25% filled? The wiki says so! In that case, you wouldn't get health regeneration while starving.

I somehow can never have enough sticks. Just prospecting for ore, I use SO MANY LADDERS. I tend to have too many saplings instead from punching leaves.

The point is to make it challenging. 'Survival' isn't fun when you make it easy. That said, It shouldn't be so difficult to clear a forest that it isn't worth doing. A balance needs to be met

Sorry, but I disagree - making an already tedious process more tedious does not make the game more difficult, it just makes it more tedious. There is zero difficulty involved in woodchopping. None. Nada.

Game systems in TFC that add difficulty are, for example, smithing and prospecting. Those require player skill, in that you need to react to the feedback the game gives you and make choices on how to proceed. Felling a tree, however, has no player skill component. In fact, if it wasn't for the terrain, you could place something heavy on the W key and the right left mouse button, go AFK, and come back to a full inventory of wood (provided the axe didn't break yet).

Making the game force you to spend twice as long to remove a tree completely doesn't change that fact. It just makes players more likely to desire a bogus way for AFK farming like that because doing it actively becomes a disgusting chore. Especially since even now, farming wood and sticks is quite possibly already the thing that takes up the largest percentage of a typical player's ingame activity.

Pigsplosion in T minus 4 months... 3 months...

I think I read somewhere that this mod works with Industrialcraft...

You may simply have misread and/or misremembered. There's no support for Industrialcraft, not even unofficial... so yeah, the client might launch but the gameplay would be shot for at least one, if not both of the mods.

However, there IS support for Buildcraft: http://terrafirmacraft.com/f/topic/3864-164b7817buildcraft-tfc-crossover-mod-wip/

And far from a mere tweaking of recipes, this is a very in-depth conversion that smoothly integrates everything into TFC's progression flow. Yes, you can have a quarry - if you manage to cough up the Red Steel for the gears Of course, this is 1.6.4 Buildcraft, meaning it sadly doesn't yet have the Builder and all the fancy stuff SpaceToad's been adding recently.

There's also a similar project for Carpenter's Blocks, although it hasn't been updated for B78 and will crash if you try it anyway.

Minecraft allows floating point Health values for all mobs (including the player), so maybe TFC could rescale back to Minecraft levels and still get the same damage resolutions. Could help with compatibility.

So would you like to upgrade your 1.74389 damage sword to this 2.11416 damage sword?

Game systems tend to be a lot more interdependent than you think they are, and floating point numbers make for a terrible user experience in general.

The team has stated that there will be no more Build 78 bugfix releases because the continuing progress into Build 79 makes maintaining two versions and cross-porting between them more and more impractical. And honestly, 78.17 doesn't have any major bugs remaining.

As for actual content releases? Well, take a look at this:

Build 75: December 30th, 2012Build 76: April 3rd, 2013Build 77: August 19th, 2013Build 78: April 10th, 2014

TFC has always had its content updates in very rare yet very big packages. A poll conducted earlier this year revealed that a majority of the community is okay with major releases taking three months; although the most often chosen singular option was "whenever [the devs] feel like it".

Come to think of it, actually, I am curious how the poll was received by the dev team, and whether or not it influences the development of Build 79. Is it "business as usual", with the release being finalized when both Bioxx and Dunk agree that it "feels complete"? Has there been an internal target set? Maybe an influence of some other kind? Note that I'm not even asking for any dates, I'd just like to know the thoughts the poll inspired.

Silly Dunk! Gonna try and keep that in mind.

What Visitor meant is that the thread was mislabeled.

I don't think it was, it's just that the only thing that was actually open to discussion (why there are not more than 2 people working on TFC) got effectively closed directly afterwards, so now there's nothing left to discuss

Multi-harvest crops have been removed for 79. To harvest your bell peppers and tomatoes, you'll have to break the plant just like everything else.

Interesting, thanks for the info. That does bring everything in line in its own way.

I should note that this isn't actually a suggestion aimed specifically at the prospector's pick.

I just wanted to suggest a potential use for a mining skill. I came up with a number of possible options, and this one seemed to be the one with the least impact on existing balance paradigms. Therefore it struck me as the one with the best chances of being implemented.

If changing the prospector's pick's mechanics is undesired, there are other options for a mining skill, many of which have been mentioned above by others. For example a minor increase in mining speed (though honestly that wouldn't really be a mining skill as much as it would be a rocksmashing skill), or minor chances to drop a second identical ore piece, or minor chances to drop an ore piece of one quality tier higher instead. Of course, these options have balance implications.

Are you sure that it does nothing? Dunk mentioned in his current Let's Play series that skills need a certain minimum number of points before they start giving bonuses. Maybe you simply didn't have enough points yet to reach that minimum threshold.

...if that is the case, though, that fact might be worth noting on the wiki

Considering this is Minecraft, and that procuring ore is such a large part of the TFC experience, I think it would make sense to have a skill tied to mining.

Skill increase condition:

Everytime you break a block of ore or mineral with a pickaxe. Normal rocks don't count.

Skill bonus:

Reduced chance for false negative results when using the prospector's pick.

Justification:

The concept is nice and simple, makes logical sense (as you get more familiar with the ore while digging it, you will have an easier time locating it in the future) and avoids messing with ore amounts or values. An experienced miner will be able to pin down the location of an ore vein with ease regardless of whether or not the prospector's pick will yield false negatives; might as well reward the player for his dedication to the profession of mining by incrementally lessening this minor annoyance. The reward of this skill is therefore valuable without causing side effects, like for example an increase in the ore value from 25 to 26 units would.

Unfortunately I am not sure how much effort it would be to implement in this case.

I found a mod that can increase daylength.  I'm not sure how this will mess with decay and all that, but I think for now a slightly longer day will help me for the first days.

That will severely screw with a lot of things. TFC itself had it as a config option for a while but it was removed due to the number of issues it caused.

Yeah, many mods don't directly support MCPC+. That said, I encourage you to trial it anyway; admin plugins aside, the performance advantage over vanilla/stock Forge is gigantic. Especially on longer-running servers, which will continually lose performance over time to a phenomenon called chunk leaking. This doesn't happen with MCPC+.

Example: I ran a 1.6.4 server last fall on my own computer. It has a state of the art 4x 4.2 GHz Haswell CPU with 16 GB RAM and only SSD storage. I loaded up all sorts of mods, including Alternate Terrain Generation which produces landscapes that are just as performance-hungry as those of TFC, if not more so. With maximum serverside view distance enabled (15 chunks instead of stock 9), and four people online in completely different areas, I started off at 9 ms world tick, thanks to the raw power of my CPU.

Fast forward three months, and the same machine couldn't stay under 50ms world tick with more than 2 people online at the same time, regardless of server view distance. Even with nobody on and no chunks loaded, it sat at 25-35 ms. Nobody on the FTB forums or the official Minecraft forums had any idea what was happening, only that yes, that happens sometimes. Or rather, that's what the FTB guys said. The vanilla guys said that their Bukkit servers are totally fine and it must of course be the mods I run that break things. And yet, Opis showed that the total serverwide load from tile entities (the stuff that many mods go crazy with and which is usually the first suspect for lag) was less than 4 ms per tick. Or in other words, less than 10% of my CPU time went into mod content. The rest just vanished into thin air. After running a JVM profiler, I discovered that all that CPU time was sitting in vanilla functions for biome checks and mob AI simulation. Even on a completely empty server with no chunks loaded. What the heck was going on?

That's when a google search randomly led me to the old Spigot project and a discussion about chunk leaks - a vanilla bug where a chunk is not properly unloaded, so that despite it showing as unloaded it still takes up CPU time. Spigot fixed that. And later it integrated into Bukkit. Which brought me back to the fact that nobody running a Bukkit server seemed to have these issues I kept seeing...

So I backed up my world and threw it on MCPC+. I expected issues, because with IC2 and Thaumcraft, I had at least two mods which explicitly said to avoid MCPC+ because of possible incompatibilities. Much to my surprise, there was not a single issue, not even a log message. And the world tick? 6 ms with 4 people on. Boom. I was downright shocked - that was a third less on a three month old map than what the stock Forge server needed on a completely fresh, empty world!

I'm definitely going to keep hosting my servers on MCPC+ in the future, unless an incompatibility forces me back to stock Forge. Thankfully I haven't seen one yet.

There are more people working on TFC than just Bioxx and Dunk... Kittychanley comes to mind, Emris_Morath has a long history of bugfixing, and there might be others. It's just that these people don't carry "official" developer tags because they're volunteer helpers who don't have any responsibility for keeping up development or much in the way of influence on the theme and direction of the mod.

Really? Is that a relatively new feature/side effect? Because in a b75 multiplayer world, my friend and I had a white cedar tree farm because we were south of the southern treeline and still wanted large amounts of wood and sticks. The saplings were planted in a large grid with 2 spaces in between them, which meant the leaves were touching each other all around. Probably around 6x12 planting spots in total, and they usually all grew within a day of each other. In the beginning we farmed all the leaf blocks for sticks for ladders, but after establishing our mines we chopped the trees with leaves intact.

Chopping one did most definitely not fell more than one tree. We played for quite a while and always had to chop each tree on its own, no exceptions.

Gonna have to try Biletooth's douglas fir trick next time, if the trunks touch I'm fairly sure it will chop it all in one go.

No, he is asking for the exact opposite - he wants something that does let you skip the night but does not reset your spawn.

Chopping one will also not chop them all even if the leaves touch. The game knows that they are separate trees.

As for charcoal pits, don't bother being too fancy. I use a super simple design that has worked every time, without fail, that I used it. First, I dig a 3x3 pit two blocks deep into the ground. Then I place log piles 2 blocks high into it, leaving the center empty. I can then stack dirt blocks on the log piles without the dirt falling into the middle if I place the corners first. I place all dirt blocks except for the center and one side block, so I still have comfortable access to the middle. I throw sticks in, start a fire, place the last log pile on top and plop down the remaining two pieces of dirt. I know when the pit is finished when the dirt blocks fall in.

The "Configuration" section on the Protection Meter page refers to 3x3 chunk areas when they should be 5x5 areas.

Also, the numbers in the descriptive text above don't always seem to match up with the config numbers ("6 months maximum" vs. "maxProtectionMonths = 10").

Might also be worth checking the Configuration page itself to see that what's written there matches.