Posts by Tallinu

Quote from Crasho666

My server Crash when I use the mod.
http://pastebin.com/itKt2S7E

We can't tell what's causing that just from the crash report. You have to post the ForgeModLoader log file from the server folder.

1.6.2 Beta version with working GUI textures now available below. We haven't had a chance to look into the charging bench energy issue yet, but that's next on the list.

Quote from GregoriusT

Found it. Even though it is really not an Error of yours, I know where the negative Value comes from.

Code

@SideOnly(Side.CLIENT)
	@Override
	public void receiveDescriptionData(int packetID, DataInputStream stream)
	{
		final int a;
		final boolean b;
		final boolean c;
		try
		{
			a = stream.readInt();
			b = stream.readBoolean();
			c = stream.readBoolean();
		}
		catch (IOException e)
		{
			logDescPacketError(e);
			return;
		}
		[b][u]chargeLevel = a;[/u][/b]
		isPowering = b;
		blockState = c;
		worldObj.markBlockForUpdate(xCoord, yCoord, zCoord);
	}

Display More

It seems that some other Mod sends out a Packet, which somehow gets into your receiveDescriptionData Function, and then causes Problems with it's random Data.

The question then becomes, how could another mod's packets be getting sent on our mod's packet channel, "kaijinAdvPwrMan"? And for the block coordinates where one of our mod's blocks happens to be placed?

Quote from Sinxar

So the bottom field is the total power (ie: 32 x 64 = 2048 - so you would put 2048 in the box)? or packets per tick (ie: you would put 64 in the box at 32 eu/t for 2048 total power)?

It's rated in EU, which means it's the total power. You'll find that the interface automatically limits the maximum value you can set in that field to 64 times whatever packet size you select. For example, 32 (LV) times 64 is 2048, so if you are using LV output you won't be able to set it to transmit more than 2048 EU per tick.

I hope that helps clear things up!

(The way the transformer functions is to send out packets one after another at the voltage setting until either nothing accepts the packet it tried to send, or the total amount of EU sent equals the transfer rate, or it runs out of buffered EU and can't send any more during that particular tick.)

Quote from plant

1. Sorry, I just meant insulated copper cable, that shouldn't be relevant though.
2. I didn't expect the order of output sides picked to effect the amount outputted, but it appears that it is.

Display Spoiler

Edit: Strangely enough, deleting everything then resetting it in the exact same configuration fixed the problem, with each outputting exactly 256 eu/t at 32 per packet. Strange.


Edit 2: Realized in original setup that one output has one cable then an mfsu, then the other has two. Setting new setup to this revealed same outcome. Is this intended, that EU split between outputs is determined by cable length?

Display More

Thanks for the screenshots. It's not anything intentional on our part, at least. We currently have no way to control which output faces the transformer emits energy from or how much goes where. What you're seeing is most likely an artifact of either the order in which Minecraft updates tile entities or of the way the IC2 energy network decides where to route EU packets.

For regulating power to evenly distribute between multiple destinations (or to force uneven distribution), you'd want to use one adjustable transformer per destination, with the transfer rate of each one set to the amount of EU you want going to that destination every tick. With multiple outputs from one transformer, there's no guarantee that energy will go where you expect, although as you've shown, it's possible to find configurations which generally behave in a desirable manner.

Quote from plant

Adjustable Transformer is incredible and awesome and better than I could have imagined it to be. The mod now fits its name with management. So cool. I love the configurable inputs and outputs.

I am no expert on EU networks so I'm not sure if this is some intended mechanic or a bug, but currently I have an adjustable transformer receiving 512 eu from an MFSU. It's outputting 512 eu into 32 eu packets. One is going south, the other east, each into 2x ins copper cables. The the south one was given output first, the east second. The south one is receiving around 344 eu/t and the east around 168. I can't figure out why that would happen unless its a mechanic of the transformer, because they both have two cables from them and lead to an MFSU.

Thanks, I'm glad you're enjoying it!

I'm not certain I understand the situation you're describing. Is it one transformer with two outputs hooked up, or two transformers drawing from the same input source? And is "2x ins" copper cable from another mod, or do you mean basic IC2 insulated copper cable? Screenshots would be incredibly helpful.

And when you say "south first, east second", are you expecting the order in which output sides are selected to have an effect on where the energy goes, like some kind of priority? Unfortunately, IC2's energy net doesn't seem to offer any functionality for picking where the output energy goes when it's being sent out - it expects all outputs to be equally valid, and they must be set ahead of time.

I had originally wanted to allow every output side to be independently configured in terms of output voltage and total EU sent, and spent a lot of time experimenting with the energy network interface. But the only way I could find to achieve that would be to remove and re-insert the transformer from the network multiple times per tick with a different output direction each time. And that's definitely not how it was intended to be used. I suspect that could wreak havoc with server CPU load, not to mention inviting all kinds of bugs. So unless the API changes to support it, there's no way to split power evenly or according to some custom ratio without using additional transformers to throttle each output cable independently.

Please let me know if that answers your question!

I too have been using BON to deobfuscate IC2 jars for use in eclipse, and with versions of Forge and MCP through around 666 and IC2 build 304 or 305, it worked fine - but with 696 and 309 I started getting NoSuchMethod errors on some recent rendering methods whose names were changed, whether I tried to use BON or left it alone. (Specifically, renderBottomFace was changed to renderFaceYNeg as were the other five like it.)

Having a fully deobfuscated version directly from the source will be extremely useful. Thank you for making that available!

It looks like the MCP updates somewhere between 7.44 and 7.51 changed those method names... I don't understand how these versions of IC2 are able to run (outside of eclipse I mean) on versions of Forge that were built with different mappings. Does the runtime deobfuscation give different results to different mods based on what mappings they were built with somehow? Is the release version still using obfuscated names after all?

Poll time!

I could use some feedback on the Adjustable Transformer's GUI.

Does anyone actually use, or see themselves likely to use, the +/- buttons for the voltage and rate settings? I don't think I've touched them since I added the x2 and /2 buttons in our development version.

I was given a suggestion that it needed presets for LV, HV, etc, and I think that's a great idea, but the control panel is already fairly crowded. I was considering replacing the +/-10 and +/-64 buttons with LV, MV, HV, EV buttons, at least for the packet size (so the buttons would be +1, LV, MV, x2 and -1, HV, EV, /2, for example).

An alternative to this would be to add these presets as a third row of buttons above or below the current numeric buttons. This would require making the GUI taller. I could do this for the transfer rate section as well. It's not like it doesn't have room to expand at the moment, but a more cluttered UI doesn't look as appealing.

For reference, here's how the GUI looks at the default launcher resolution:

Anyway, I'm hoping that people who try out the new version will consider this question and offer their opinions or their own new ideas for improving the mod.

Thanks, and have fun!

Okay, this version may end up being the release, if no bugs are discovered in it. Everything seems stable, and I've been adding more new features that I'm eager to get out to everyone!

APM 1.1.68-IC2-1.115:
Improved average tracker response time when EU rate drops to zero or a trickle. You can see it changing right away now!

Charging Bench GUI updated with four new display items: redstone power state, average EU input per tick, total EU required to charge current items, and estimated time required to finish charging (ETC). The last two take into account the effects of overclockers, and the ETC will consider the average EU input if the bench's stored energy is insufficient to complete the charging operation!

Adjustable Transformer block textures updated. Output sides now switch textures based on output packet size and show a single dot of the appropriate color. Input sides have four dots, one for each voltage level.

Miscellaneous code improvements and minor fixes.

Download here:

Good news: The test build will include the new Adjustable Transformer after all.

More good news: Here it is! Download is in the attachment below.

This version is for testing purposes, and may have unnoticed bugs. BACK UP YOUR WORLDS before running them with this build! We accept no responsibility if anything is lost or damaged due to inexplicably uncaught severe bugs. (It's unlikely, but you have been warned.)

It appears to run fine on Minecraft 1.5.2 using Forge 7.8.0.684, but most of our testing has been on MC 1.5.1 using Forge builds 666 through 679 and IndustrialCraft 2 version 1.115.304
If you find a bug, please follow the reporting steps in the original post. Reliable reproduction steps are important in helping us fix them!

Mods which have not yet implemented the vanilla ISidedInventory interface will continue to use the old slot access sides; Vanilla hoppers/droppers and mods which have switched to the vanilla interface will use new access rules for the charging bench and battery station. The battery station's input and output slots can be accessed from all sides, but the input slot can only have items inserted (and only valid battery type items), and the output slot can only have items removed. The charging bench's input and output slots are accessed either from the top or the bottom, following the same new rules as the battery station's (for all electric items), while the power slot is still accessed from any side.

Going from low-voltage to extreme-voltage and vice versa is now easier than ever! The new Adjustable Transformer is crafted using a HV-transformer, Advanced Circuit, and LV-transformer in a vertical line. It accepts any standard IC2 voltage (the max is set to 8192, which may allow input from some gregtech equipment). The interface allows you to control the output voltage (the packet size) and the amount of EU it will allow to pass through per tick (with a maximum of 64 packets' worth to avoid lag). It also allows you to control whether each side acts as an input or an output. The block texture shows red markings on output sides, which are absent on input sides. (The textures may get modified in the future, if we can think of improvements.) You can also apply a redstone signal to completely disable the transformer - it will not accept or output energy while powered by redstone. You can use this for a manual shutoff switch or to automate control of energy flow through your bases.

Remember, this is not yet a final release, just a public test build. BACK UP YOUR SAVES!

UPDATE: There's a newer version, two posts down. Grab that one!

I'd like to keep the max output packet size at 2048, which is the highest that any normal IC2 wiring can handle - but since it can spit out up to 64 packets per tick, that shouldn't be a problem.

I see no reason to limit the maximum input voltage, since this is intended to accept "any" voltage after all. I have to plug in some number though, so if you can tell me what the highest packet size his stuff can put out is, I'll set it to that.

Updated screenshot: Adjustable Transformer GUI The block textures are slightly different on input and output sides now, as well.

Quote from Geo Terra

Please tell me that it will be actually craftable?

Of course! This is simply a transformer that can accept any voltage and output any voltage, good for converting directly from HV to LV for example, especially for feeding rows of energy-hungry overclocked machines. The output rate setting will effectively determine how many packets of the desired size it will output per tick. Whereas normal IC2 transformers will only accept one packet per tick, limiting them to four output packets, which puts a choke on the energy throughput unless you install several in parallel.

I just got done implementing input/output toggles for each side (although it doesn't show up on the block textures currently - going to have to draw a new one for that). This means you can control which sides will accept energy and which sides will output energy, to avoid accidentally frying your lower voltage wiring and machines.

A redstone signal will shut it off (no input or output) so you can use logic to control power flow, or temporarily disable it to reconfigure it or your wiring without risk.

We may post a pre-release beta version for Minecraft 1.5.1 if our testing continues to go well.

Additionally, here's a sneak peek at a new feature I'm working on: Work In Progress - Subject To Change!

Note that this will probably not be in the beta prerelease and may not be in the first 1.5.1 release either.

To be clear, we really have no idea if the changes Pantheis made will have any effect on the loss of charging bench tile entity data during these server crashes. This is a stab in the dark just to see if it has any effect. We're thinking of trying to come up with a way to force a server crash in a way that replicates this problem, but that may take some time. Anyone who isn't having problems with server crashes or benches losing data probably has no reason to download the version in the previous post. But if you are, and you're willing to try to get it to crash a few times or run it long enough for it to do so, and can't reproduce the problem any more... that would be very useful information.

Additional information about the situations in which the benches reset would be very useful.

Is it only the charging benches, or are the battery stations or storage monitors affected as well?
Have the sources of EU for the benches been in the same chunk, different chunks, or either/both?
Does it happen to a bench which is placed all by itself in a chunk with no other machinery or player-made tile entities / blocks?

Also, what other mods are being run? Perhaps there's one we don't use that could be causing problems when used together.

If anyone is able to come up with a list of mods, config files, and a world save which frequently causes benches to reset, it would be of great help to us if we could get a copy of that information / files to test ourselves.

Quote from FunnyMan3595

YES. PLEASE. NOW.

That solves one of the more aggravating problems I've been having with SeedManager right now. The current wrench is extremely evil in the item it drops, because I can't configure it in any way without becoming the wrench myself. So the metadata bits I'm using to store information about the current machine state get preserved in the wrenched item, and the end user is left with a bunch of "different" stacks, because the machines were picked up in different states. I can't even swap out the metadata for the canonical one on removal, because that annoying bastard of a wrench caches the value before I'm told he's thinking about picking me up.

Also, this API "breakage" is utterly trivial. It's about as hard to fix compatibility with it as it is to fix compatibility with your average Minecraft release... and I'm talking 1.4.2->1.4.5, not 1.2.5->1.3.

Would this change mean there will be a specific location to perform anything that needs to be done WHEN a machine gets picked up via wrench? Because last time we tried to make APM work with wrenches, we found that it wasn't calling the normal method for when a player is removing a block (onBlockDestroyedByPlayer).

If wrenches were expected to call that method instead of simply clearing the block, it would make it a lot easier to have the machine drop any items it contained or do any other required cleanup, in an appropriate manner.

My point was simply that some choices in the pursuit of balance invite trouble more than others. Sticking to approaches which are less prone to trouble is, as a general rule, preferable.

Quote from FenixR

And just as a remainder, we should talk only about vainilla IC in here, because we all know that things like balance and sense will be thrown out of the window when another mod besides IC its mentioned.

While I understand that balance decisions can't take into account all the other mods in existence, IC2 does not exist in a vacuum. In the real world I think it's pretty rare to have IC2 as the only mod installed. Because of this, relying on a balancing technique that could be completely bypassed using quite a number of other mods seems rather foolish when methods that wouldn't be susceptible to that are also available.

Energy loss while in item form would be a difficult feature to implement *and* it could be bypassed quite easily even without other mods installed. That's two marks in the 'cons' column and I can't see any in the 'pros' column. Energy loss that occurs when the block is wrenched would be simply a matter of adding one math operation to the assignment of the block's current stored EU to the item's retained EU, and it's a balancing technique that other mods couldn't bypass. That's two in the 'pros', and while I suppose some might consider it unsatisfactory or insufficient and place a mark in the 'cons' due to that, to me it seems fine. And I'd rather have IC2 releases not be delayed by additional dev time to implement or fix tricky and unnecessary features.

As for adding that to Forge... Making all inventories capable of ticking items would require adding a lot of complexity to every entity with an inventory space, and that wouldn't even cover all means of storing items. Mods might need their inventory handling rewritten in order for it to work. The extra processing could put more load on servers and slow down SP games (A drop in the bucket perhaps, but every drop counts). Mods can already accomplish something like that in inventories they create, if desired, so the only reason to add a feature like that to Forge would be to enforce compliance on every mod. Just to let storage blocks' EU decay.

tl;dr: I don't think it'll happen. Just sayin'.

Quote from Mister_Omega

I, like a number of other Minecraft players (I'm assuming), watch Direwolf20's videos, and I had an idea when I saw the 'recharging' mechanic of the Thaumcraft wands.

My idea combines a few interesting thoughts I've seen floating around on this thread. Would it be possible to make the storage units act like RE-Batteries in the sense that they stack when COMPLETELY empty, but when the unit in wrenched, the player receives a "shock" from a configurable amount of EU lost from the unit (I'm thinking 5-15% at default and maybe 1.5 hearts of damage per 1000 lost?). The unit retains the remaining energy, but the amount of energy stored decays over time (I'm not sure about the decay rate, perhaps 1000 EU every second (20 ticks)? The EU loss could be configurable as well for the sake of server owners).

The EU loss would be nullified for quick moves, especially if the player misplaced it, but would definitely discourage using the storage units as a completely OP form of EU transport.

Could this work?

Display More

I see no reason to damage the player for wrenching an energy storage unit under any circumstances. This currently doesn't happen, and the fact that the unit might retain some of its energy instead of losing it makes that idea even more of a 'WTF'.

However, acting like RE batteries in regards to stacking when empty would be excellent. All it needs to do is clear the 'stored energy' item tag if wrenched while power is lower than one packet's worth. (Because unless you're carrying around a not-fully-charged item with which to suck the last 5 EU out, it's hard to get a storage unit all the way down to zero EU.)

Due to the way Minecraft works, I think it would be difficult to make the item do something over time without it being possible to circumvent this process (and 'freeze' the energy storage), for example by placing it in an ender chest or any portable inventory space and only taking it out again when you're ready to place it.

Losing a certain percentage of the stored EU would be fine, as long as it wasn't a huge amount. Even losing 10% of the stored EU would be sufficient to discourage its use as a portable recharging station - you'd lose a full lapotron's worth of energy the first time you picked it back up again. That seems like plenty of discouragement right there.

We're using Transformers 1.6 with APM and TE without any problems. First, make sure that the version of IC2 you're running is the one that your version of APM was built for.

Quote from huldu

Code

Caused by: java.lang.NoSuchMethodError: ic2.api.Direction.toForgeDirection()Lnet/minecraftforge/common/ForgeDirection;
    at snyke7.Transformers.TileICEngine.acceptsEnergyFrom(TileICEngine.java:138)

This line suggests that some mod is loading an older version of the IC2 API. Check your other mods that use it. Instructions elsewhere on the IC2 forums suggest deleting the IC2 API folders from the jars / zips of mods other than IC2 itself to make sure that only the newest version of it is loaded.

If you can't find the mod causing the problem, try making a test world with the setup you described, then start removing mods until it no longer crashes.