Posts by Myrathi

I had an emitter block mod in the works, for exactly that purpose, so you just saved me a bunch of work! Go you! Have a !

(yay for the benches, too ;])

Quote from Kane Hart

Wonderful mod and it seems to work flawless. Well publish for a first mod here or maybe ever I'm not sure your experience hehe.

Here is a video for the people in doubt and feel free to use it in your thread =)

http://www.youtube.com/watch?v=oPopxKzZ7OA

Glad you're finding it useful. Added your video to the main post. Cheers!

Quote from DreadWingKnight

Screenshots showing the interfaces of the machines as well as them in use would be helpful.

Those are in progress. :] (though the GUIs are actually based upon the BatBox/MFE/MFSU, with the top slot "permanently in use by the emitter circuit" - so everyone should already be right at home using them).

Quote from Appleblomb

Get them pictures up, I had thought about doing something like this a while ago but never did. You sir are a hero. Now instead of spending forever charging my lapos I can just hold them all and walk away from my computer and come back to them charged.

For the moment, the pads only charge what you're actually "holding out" (i.e. in your currently selected slot) and whatever you're wearing (if chargable). Charging up anything/everything in your hotbar will, however, be an upgrade (which is already on the TODO list). :]

Quote from billjoehobo

If I may suggest change the recipes of the top two tiers to include the item of the lower tier. So you can't jump straight to tier 3.

I'd considered that when I first worked them out but figured that requiring the actual storage items for the relevant tier in the recipes, themselves, meant that you had to BE at that tier to even consider making them. You can't just skip straight to making the lapotronic pad unless you're already AT tier 3 (since you have to be able to make advanced circuits, carbon plates and an MFSU). They're really just meant to be a useful utility-extension to the storage blocks, themselves, so the stepping-stone concept seemed a bit much?

However, you've hilighted a valid issue: making the next tier of pad would effectively leave you with a lower-tier pad that you've little use for. So, perhaps having a way to upgrade an old pad to the new tier is in order! (that and nattering about this on IRC brought up a nifty idea that having to physically pick up the block to upgrade it could be annoying, too, as you'd lose all the stored EU... soooo, to borrow a concept from IronChests: in-place upgrading via an emitter toolkit, perhaps? I see no reason that's not viable - replacing buffer corners and circuitry shouldn't be THAT hard... so long as you're prepared for the occasional shock if you do it to a fully powered pad. >:])

*adds stuff to his TODO list*

Quote from F4113nb34st

nice, this will definitly be useful
(p.s: grats on your first addon!)

Good to hear - and thanks. :]

Quote from m157

This mod is PERFECT!
4.5/5

Woohoo! Diamonds! ;D

ChargePads is an addon that provides new blocks which, when stood upon, will recharge IC2 items that are held in your hand or worn (like batpacks or parts of a nanosuit).

ChargePads is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License. Appropriate restrictions are waived for the IC2 team as required by their publishing notes.

Quote from RawCode

just do what you want, none trolling here (this thread).

I love the "this thread" bit... heh. ; )

Quote

Case 1: you dont know how block works and does not have source, so you not able to implement anything inside it's class, but want to debug this block:
А) You code something generic and execute it, this possibly will reveal data you want.
B) You hardcode params you need from block into your debugger and debug. (CURRENTLY IN IC2)
C) You implement your own "interface" and allow user to map data into it via config or runtime. (HOW BUKKIT AND FORGE WORKS)

I'm well aware of how forge works (though, I'll admit, I've completely avoided bukkit), but I think I now see what you're actually getting at and the functionality you're seeking (and why).

What you're suggesting could (would?), indeed, be useful but that's totally not what I'm looking to achieve with this Suggestion. : )

I'm seeking a very simple interface that's very specifically useful "for the block you're developing within your own mod." This interface shouldn't care about other blocks or other mods; it's purely for accessing a status/debug message in a test environment. It's as simple as it is because that's all it has to do. The "extraneous boolean test" is actually exceptionally useful, as it allows *your code* to choose *at any point*, whether you want a message (or not) for your block, and no-one else's.

That last, italicized part is the most important: this interface is not to allow hooks into other blocks or code! It is purely and simply to allow one item (the debugItem) to show a message when it's clicked on the block the interface is implemented on. That's it. Nothing more. It's that simple. There is not meant to be any mechanism for hooking into anything.

Regarding the boolean method: I suppose it would be just as easy to signal "no message," at any time, simply by returning a null or an empty string from the getDebugText() method (and the debugItem's code would ignore both) but I like to be explicit in my usage tests and it makes the supporting code look much cleaner (in my opinion).

The support/functionality you're looking for would, I think, deserve its own Suggestion, entirely, as the scope for that is much larger and would require significantly deeper hooks into IC2.

Mine is deliberately designed to be as simple as it looks: easy to implement on both the IC2dev and mod-maker sides.
I suppose it could just as easily be called IDebugItem since that's all it's designed to be: an interface into that item. : )

Apologies for being so harsh by way of response - we were definitely looking at entirely different "levels" of debugging support. ; )

Quote from RawCode

*we* can do anything, there is no limits, two possible methods exist:
add debug code into TE code
add debug code into Debug code

I fail to see what either of those have to do with this interface and its use with the debugItem. If I want to dump info to the console, I can already do that in a multitude of ways. This interface is very specifically for allowing the "debugItem" (the little purple-squares thing) in IC2 to output a "chat string" to the item-user, in exactly the same way that it already does for existing IC2 blocks (that are hard-coded into the debugItem, in various ways).

For example: not every op or admin user on a server is going to have access to the console or logfiles and, therefore, it can't be guaranteed that those people will be able to check for your "console debug messages." This makes the debugItem the perfect tool for providing 'status debug messages' to them.

Extra example: when you're developing an IC2-reliant mod, being able to just click your item and get a status message right there and then, instead of having to "do stuff in the client" while simultaneously watching the console like a hawk, is exceptionally useful. As is having a helper/tester do something to a block WHILE you're clicking it with the debug item, right there in the client/world.

Quote

add eventhandler and register debuggers inside it, on execution enumerate every registered debug handler

That's complete overkill for something as simple as "showing a text string when you click a specific item on your block." You're overcomplicating things and suggesting an idea that could add significant overhead to using a single item on a single block.

Quote

3rd method is best, since you may register debug code for one class into other class, ever inside addons, without any need to edit original TE code.

This has nothing to do with addon or class debug and everything to do with a block relaying its immediate "status" when clicked on by a specific IC2 item. Again, you're massively overcomplicating something that's meant to be exceptionally simple to implement (as two interface method definitions).

Quote

without interface method class implementing interface WONT COMPILE and wont return INSTANCEOF

That's why they're abstract: you MUST define them. Are you being deliberately obtuse?

Quote

there is COMPLETELY no reason to check isDebuggable after checking instanceof

You're completely wrong: implementation of the interface simply informs the debugItem (IF it's clicked on the block) that "the block it just clicked MAY have a status message". The debugItem then tests the isDebuggable() method return and, if it's true, gets and prints the status message; if it's false, it can safely ignore it and continue on its merry way (for that click).

The isDebuggable() method exists so that the BLOCK can choose when IT WANTS to pass a status message to the debugItem, dependant entirely on its own internal state. Sometimes, it may want to provide a message; sometimes, it may not. Whether it does or not, may depend upon a config entry for the mod; it may depend on the status of something else, in the mod, entirely. The point is that such a decision has NO place in the debugItem's code itself and is best left to the mod implementing the interface: which is exactly as it should be.

I fail to understand how any of this is anything but clear. If you still don't get it, I'm just going to assume you're trolling.

Quote from RawCode

it actually already implemented as interface, just hardcoded into base class.

The internal code checks for very specific interfaces and TE classes and outputs very specific data dependant upon what it finds. There is no "generic debug interface," as such, which is why this suggestion exists. : )

Quote from GregoriusT

Btw, How did you got the Codetags working?

The code tags seem to be extremely particular about the line-endings that are pasted into the block, especially if you're using "Editor" mode. I switched to the "Source code" tab, to edit my text directly, and no longer had a problem.

Quote from RawCode

I would implement something like this to allow much more flexible CustomDebug method.

The check for a non-null TE should be done within IC2's internal debugItem method and is beyond the scope of my Suggestion. That check would (should?) be done long before it even gets to the small block of test code that I supplied - if the TE was null, the code would complain at the first of its own checks. : )

That aside: the point of the IDebuggable interface was to make it so that the *block* could decide if and when it wanted to return a status message - if it wanted to, at all; if your block is inactive and has no status - isDebuggable() would return false and the process ends; if the block is active, it returns true and getDebugText() is polled for a string to send to the player using the debugItem.

If you always want to return a status, it's as simple as always returning true from isDebuggable().

Some people may not want their blocks to return a debug status at all times. Your method, unfortunately, lacks that functionality... and your method name isn't exactly clear as to its purpose.

Quote from RawCode

If block lack CustomDebug interface, we can list EVERY field also we can do this with method invocation without use of API or interface, but at cost of speed.

Actually, you can shift-click use the debugItem and it switches to a different mode that does exactly that, when used on a block (displays all of the block's interfaces, fields and TE fields) - it's useful but exceptionally verbose and not very useful for a one- or two-line status message as it currently works on existing IC2 blocks.

Name: ic2.api.IDebuggable

Description:

It would be useful to have an IDebuggable interface available that would allow mods using the IC2 API to output their own message to the player when the debug item is clicked on their block(s).

Implementation on a mod's own tile entities would follow the same approach as any other interface in the ic2.api package.

Recipe:

The interface:

package ic2.api;




/**
 * Allows a tile entity to output a debug message when the debugItem is used on it.
 */
public abstract interface IDebuggable {
	/**
	 * Checks if the tile entity is in a state that can be debugged.
	 *
 	 * @return True if the tile entity can be debugged
	 */
	public abstract boolean isDebuggable();




	/**
	 * Gets the debug text for the tile entity.
	 *
 	 * @return The text that the debugItem should show
	 */
	public abstract String getDebugText();
}

This could be implemented in ItemDebug's right-click function with this:
(the sendChat function is obviously just for demonstration)

TileEntity te = world.getBlockTileEntity(x, y, z);
if ((te instanceof IDebuggable))
{
	IDebuggable dbg = (IDebuggable)te;
	if (dbg.isDebuggable()) {
		sendChat(player, dbg.getDebugText());
	}
}