Rather than all players, one option is to send the sound events to a square of chunks, and when a player crosses a chunk boundary, check if the newly added row (of the, say, 5x5-chunk active sound square, not the far larger player view/chunkload square!)) has any active sounds in it. The client would be in charge of the final radius check for whether a sound is actually audible at the moment, and for discarding the sound source when they cross a chunk boundary out of its update square. That also gives players a more-or-less intuitive way to fix ghost sounds, if any future bug or poorly-timed exception could ever leave one around.
Your idea about the stack size limit is great, but I think that the accept limit is better to be (64 - N) * one craft, and the output threshold (63 - N) * one craft, otherwise only 1 upgrade is enough.
Each upgrade reducing space makes sense if you assume that a) the upgrades are less expensive than letting one extra input/output accumulate in a single machine, and b) that the player knows about the upgrade and is willing to go to the trouble to make them at all. If the incremental advantage of a single upgrade is too small, it would never advance beyond a very niche feature. So I figure that the common case should be one upgrade, and allow multiple as an advanced option. It's also easier to reason about how much space there is when you have 5 upgrades and a recipe like 1*A + 2*B = C.
Players generally don't like the idea that if they set up a component production line, it will consume inputs until every machine input and output along the way has a full stack of intermediate products. As a result, they tend towards overly-smart logistics networks like AE, where the network is in charge of putting exactly the right inputs in so that nothing gets wasted, but I think that it would be nice to have the Factorio-like option of letting full inputs produce natural backpressure with an acceptably-low overhead, so everything can pull directly from storage.
So, I suggest a "stack size limiter" upgrade. If N > 0 are present in a machine, then it will only accept N * one craft items in each input, and will not process if any output has more than (N - 1) * one craft items. Having modes to only affect input or output would also make sense.
I don't know how best to handle cases where different recipes take different counts of the same input item, perhaps a "recipe lock" upgrade would also be useful.
(There are a few old topics on similar ideas, but none of them are in the suggestion forum. They are also old enough that I feel re-visiting the idea might be worthwhile)
Unfortunately, a nontrivial portion of people playing IC² are only doing so because it's required to progress in a modpack that they are playing. Many of them are used to being babied by other mods, do not care to RTFM, and then go whine to each other when stuff breaks because of their lack of knowledge, creating a negative impression of IC² to players who might otherwise enjoy the mod but haven't tried it yet.
I propose that when you first place machines down, they *don't* draw power yet. When you first open the GUI, there is a slot with an angry-red background and a bubble of text explaining the situation (and giving a moment to shout RTFM! to those players that didn't):
In order to connect the machine to whatever wires touch its casing, you need to insert a fuse (or fuse substitute):
- A fuse, but for gameplay reasons those are fairly expensive (especially at higher tiers). Still cheaper than having a machine explode, but not something to take lightly, especially since the fuse is completely destroyed in the act of saving the machine.
- An (un/insulated?) wire of the appropriate tier. Far cheaper than a fuse, but because it's enclosed within the machine, there are no guarantees that it will burn out fast enough. 50% chance of saving the machine, and the text can hint that in-world cables are a better alternative to fuses.
- Any metal item. If you really just need EU to flow, and don't mind the occasional shower of sparks coming from the GUI while it's open, you can stick any metal item in the slot. Absolutely no protection, though. Maybe there's even a chance that the current flowing through will weld the item into place, making it hard or impossible to remove? If you want to cause havoc for somebody else, throw a literal wrench in the works, then crank the voltage!
The fuse slot would only be accessible to players, so if they mess up they will have to go to every affected machine and insert a new fuse. As a small bonus, it might encourage structure designs that put some thought towards maintenance access.
Well since Aka left just before I wanted to ask him if I did something wrong with starting the server with mcpc+. Here are the results:
[spoiler'd stack trace removed]
I go back to my crops now.
EDIT: I got 2 other reports from players that loading gregtech into mcpc+ is an insta crash
That crash is caused by CCC, actually. It is trying to modify BlockDynamicLiquid to enable finite water, but MCPC+ has already made its own, incompatible, changes to BlockDynamicLiquid. Disabling infinite water through MCPC+ instead of CCC would probably fix it, though there may be other issues due to MCPC+.
Although, maybe GregTech is enabling CCC's finite water which is causing the crash, so it might still be indirectly due to GregTech.
Vanilla 1.6.4 already has the scoreboard sidebar GUI, so it might be possible to make an entirely serverside mod/plugin for it. (for example, quietly /playsound a few notes, pop up the sidebar with a list of players currently recording for 10 seconds, and send a chat message stating who just started recording)
As people have pointed out so many times before, unless you find some naturally occurring antimatter, you will never get more energy out of it than it costs to create the antimatter in the first place. Unless GregTech physics aren't like real life physics, which seems unlikely considering the machines and products it adds.
You probably have some loss in the cable, so by the time it has used 200k EU, the internal energy storage has run out. Try using cables with less loss (with a single MFE, you want 0 EU/p loss when processing bauxite), or add another MFE or a batbox to the line to cover the missing EU/p.
They aren't the end users, they never agreed to the EULA...
You could also set up a batbox outputting to the same line as the MFE, so that even if you lose a few EU/p, the machine will remain fully charged. At least, until the batbox runs out...
If you watch the changes over a few weeks, it's quite clear that a lot of the less useful things (like the large variety of cells) are slowly getting more uses. New ways to craft things (silicon plates and electrum ingots for an alternate advanced circuit recipe), new uses in recipes (better resource yields in the grinder and blast furnace if you use certain previously useless cells), and even new machines(sawmill, implosion compressor, industrial electrolyzer). If you are thinking about the recipe changes, those are there for balance.
If you are still using the old FTB version, it's REALLY missing a lot of content which makes GregTech even more interesting.
It might be useful for components to specify the power they output multiplied by 360 (2*2*2*3*3*5, making 1/5, 1/8, 1/9, and 1/10 possible, among other fractions), and store the remainder in the reactor block to be added next tick, so that any fractional amount carries over.
The purpose of scaffolds is not that they are cheaper than planks, though. They seem to be designed to be, in every way, perfect for temporarily accessing areas too high to reach normally.
First, you can make more of them out of planks. This is reduced by GregTech because, since they burn, it was a significant exploit that makes all other wood processing worthless.
Second, when you need to clean them up, you only need to break the bottom block.
Third, you can climb them somewhat like a ladder (can't use shift on them, you have to be right up against them rather than just in the same block)
Finally, you can left click anywhere on a scaffold tower with a scaffold in your hand to put it at the top of the tower.
So, it still has three of the four benefits, and is still cheaper than ladders for a climbable block. And this way, charcoal is still a useful fuel, using a railcraft coke oven to make charcoal is still an upgrade, thermal expansion and gregtech sawmills still further upgrade your fuel per log. Each regular log fuel upgrade requires more and more advanced machinery/resources, but the scaffolds mean that the ultimate fuel increaser is a crafting table, literally the first thing most people create.
A config option might be nice if there isn't one already (disableRecipeExploits=true?), but the scaffold change gives multiple machines from multiple mods more purpose without affecting the rest of the game very much, so is a very good idea, in my opinion.
Have you understood what he meanted ?
He was complaining about OP recipies for Forestry Bronze, and you ... are thinking he's request is already implemented ? Let me laugh
Oops. I thought I had looked and saw that it didn't work for some armors and tools. Turns out that what I had actually seen was that the metallurgy bronze armor couldn't be macerated to bronze dust, and that the forestry bronze couldn't be directly macerated, and therefore assumed things and got the wrong conclusions.
I'm fairly sure that's intentional, as the forestry bronze recipe has double the output, so you could easily exploit your way into infinite tin and copper (since you can separate bronze dust back into tin and copper dust).
To create IC2 bronze, you need to combine dusts, rather than ingots, so both recipes most likely work, giving different numbers of different types of bronze, and for the armor (or anything else that can be processed back into dust), you'll specifically need the more expansive IC2 bronze.
I've seen that "hurting the end user" argument thrown around a bit, but people using it always seem to overlook that taking a mod author's hard work and then using it in the way they are trying to justify hurts the mod author, too. When they see their work being distributed without permission (or even specifically against their wishes, if they clearly stated on the download page that they did not want it included in a mod pack), it can hurt their motivation. Perhaps drive them to make bees into creepers, or even make them not want to develop mods anymore!
If you help the end users by giving them lazy access to someone's work, but the author quits one month later as a result, is the end user really better off, considering that mod, which was good enough for people to want, is no longer being maintained or updated? Worse, all of the end users who downloaded it manually, or got it through an author-approved source are now hurt as well...
Plus, even if it is designed to interact with Minecraft, a mod is still the unique creative output of its author(s), so I'm sure that, in some countries at least, it is protected by law, and redistributing their work contrary to their clear statement otherwise is therefore illegal (I am not a lawyer, and I do not know a thing about the laws of most countries. However, most mods these days include absolutely NO code from Minecraft, their source at most containing the MCP-generated fake names (the output of the mod source and MCP's recompile process may be a little bit more questionable), and many mods include a LOT of effort. I feel it is safe to assume that some, many, or even most countries have laws that protect their work).
Except you can craft lava source blocks from UU, then process a stack of those to get tungsten dust...
Would you mind if I added support for displaying GregTech macine recipes to CraftGuide?
Since IC2 apparently doesn't provide CraftGuide recipes itself anymore, would you (assuming you, the one reading this, are part of the IC2 team and can actually make this sort of decision for the mod) mind if I added that functionality to CraftGuide instead?
I believe imbis made his mod work better with RP/BC in a recent release, so try updating or just hooking a pipe up to the table. I also noticed that Eloraam put some of the new block IDs square in the middle of BC's range. Open up redpower/redpower.cfg and edit the offending block ids to new numbers.
Actually, RP2 will, the first time it's run (or if you change a certain configuration setting) wait until the other mods have loaded, and then pick from the unused block IDs. You might still have issues if you install something later, but there probably was a gap in the BC IDs, and RP just filled it.