Jump to content

pantheis

Members
  • Posts

    28
  • Joined

  • Last visited

Converted

  • Gender
    Undisclosed
  • Personal Text
    Modder

pantheis's Achievements

Tree Puncher

Tree Puncher (2/8)

0

Reputation

  1. No immediate plans, but I'll consider it. As for power, is there an agreed rate of conversion between EU and MJ? There are a couple of conversion factors for them with one of the ones most used being from the IC2 Transformers mod. 2.5 EU = 1MJ.
  2. I'm not getting any such messages. What version of IC2 are you using, exactly? Are there any special circumstances under which it happens? I had a 463MB log file because of this error spamming over and over and that was with only about 16 of the IC2 Floodlights active. Forge 6.0.1.355 / IC2 1.108 beta, Greg's Lighting 1.5 for Minecraft 1.3.2. You can recreate this by placing a light down, powering it up (I used MFSU -> MV transformer -> LV transformer -> light with appropriate wiring in between each block. It should start generating spam on the server console in SMP. -edit- More information about this. I can duplicate this only when I setup an array of lights, at least 9, (but I have 25 of them). As I start turning them on, once I hit the 9th, and sometimes the 10th light turned on, this starts spamming in the log. The EU Meter on the one glass fiber line feeding all of them reports 25 EU/T usage, so this is really strange. It also happens that sometimes I can get 9 turned on without the error, and sometimes only 8. It depends on which lights I seem to turn on. I've upgraded to the latest version for Minecraft 1.4.2 (Greg's Lighting 1.6.2) and have tried removing and placing the lights down again. Same issues. So odd. I've looked over the source for the 1.6.3 version you have posted and as far as I can tell you've done everything right, so I'm really confused. -edit again- This seems to be a problem resulting from only having an internal energy storage of 5 eu, but you're asking for more energy every tick, which results in a whole lot of 1 EU energy requests and is overall very bad for the IC2 electrical net. I've fixed this in a copy of your source by making two small changes. In TEFloodLightIC2.java: line 10 maxEnergy = 64; line 24: return energy < 32; Those two changes will increase the internal buffer to 64eu and only request additional EU from the energy net when it's internal buffer is under half full. This happens prior to it determining if it should be lit or not, so it will refill itself prior to that, and will still operate on less than a constant 32 eu/t input as long as it can get 1 eu a tick, but the larger buffer allowed for energy loss over long cables to sometimes give it no energy in a tick. I was finding with a 32 EU buffer it was causing a large array of the lights to strobe. This change will reduce server lag and stop the spam at the same time.
  3. The "getBlock" referenced here is "getOrCreateBlockIdProperty" or something else? I've looked at various tutorials and the forge source (at least up to 4.1.1.251) and I want to make sure I'm doing this right. Conflicts suck.
  4. I'm trying to get my block to emit a strong redstone signal, controlled from the TileEntity, so that attached redstone wire, repeaters, etc, will light up and carry that signal. To troubleshoot my issues, I've looked at the base code for the lever, redstone torch, repeater, redstone wire block and even other mods online. I cannot figure out what I'm doing wrong. My block code is on github https://github.com/pantheis/StorageMonitor/tree/Working. It's a mess at the moment because of everything I've been trying to get this to work. From the debug statements it looks like only isIndirectlyPoweringTo is ever firing and only when another block is placed adjacent to my block. If I place one of my blocks down, place another block next to it (such as some cobble), then wire redstone to the cobble, the redstone is powered. Redstone wired directly to my own block is not. It's like my block is strongly powering blocks around it, but not itself and will not power redstone wire or repeaters hooked directly to my block. Any advice would be most welcome. I know I must be missing something really simple here, but it's completely eluding me. I have isIndirectlyPoweringTo, canProvidePower, and isPoweringTo simply returning true to try to troubleshoot the problem. [edit] I fixed it. It requires overriding these two things in order to act like a lever or redstone torch but still be a full cube, and to return true on isPoweringTo but false to isIndirectlyPoweringTo. @Override public boolean isBlockNormalCube(World world, int x, int y, int z) { return false; } @Override public boolean isBlockSolidOnSide(World world, int x, int y, int z, ForgeDirection side) { return true; }
  5. Forge != FML. FML is Forge ModLoader and should be used instead of Modloader or ModLoaderMP. And as others have said, any incompatibilities with mods using ModLoaderMP are because the mod author hasn't updated to Forge ModLoader (FML). Instead of bugging Forge people to break everything in support of a crappy standard, go bug the mod authors to abandon MLMP in favor of Forge and then their mods can be compatible with 99% of the modded stuff out there.
  6. You can take a look at a couple of the mods that I've written that have working GUI's if you want an idea of how to do it correctly. I'm at work at the moment so I don't have time to look over your code for any specific details or help. I'll try to get something more up here to help you out later. In the mean time, take a look at the mods below. The Charging Bench code shows off how to transfer variables from server -> client using the container and the Inventory Stocker has a full on GUI with custom packets implemented. https://github.com/pantheis/ChargingBench and https://github.com/pantheis/InventoryStocker
  7. If that's your entire code, you seem to be missing a lot of things required to code a forge mod. It looks like you aren't even using Forge. Are you wanting to use Forge?
  8. Woot! Thanks again LexManos! I should have figured it would be something like that.
  9. MinecraftForge.versionDetect("ModName", 3, 1, 2); no longer seems to work. I also cannot find a replacement function. The version checking outlined in http://www.minecraftforge.net/wiki/Tutorials/Upgrading_To_Forge_for_1.3.1 with the versionBounds = "[1.3]" // VERSION CHECKS! Does not seem to actually key in on the version of Forge, unless I'm completely not understanding how it works. It looks like it's a way for mods to make sure that the server and client version of a mod are compatible, not that a mod requires a specific version of Forge or newer. What happened to MinecraftForge.versionDetect?
  10. I just wanted to say that this worked perfectly! It looks like the proper function is named getAuxillaryInfoPacket() though, but I figured it out by looking at the TE code for signs and mob spawners. Thanks again!
  11. LexManos, thanks again! As always, you rock. I'll take a look at this tomorrow when I work on coding again.
  12. I can send packets updating the client with the proper data, that isn't the issue. I just don't want to be sending packets every 1/2 a second to every player in range of any of my blocks. On a busy server with lots of my blocks, that would be a lot of packet traffic for absolutely no use. There's got to be some event or method that I can use to send updated information to players that enter the visual range. Like when the server sends the chunk to a player...
  13. Thanks for the advice atrain. I'll look into that as an option but I'd rather not be responsible for tracking player entities in a range around my block. I wonder how mods like IC2, RedPower, Buildcraft etc handle it...
  14. My mod has a block that you can rotate. I have this working and am using custom packets to communicate the information to all players within a radius around the block so that their clients all update and show the new orientation. This only fires when the block changes orientation, which is a good thing. The problem I'm thinking I'm going to run into is if a player that isn't in range to receive that packet then comes into range of the block. That player will not have accurate information as to the block orientation and so will not see the textures correctly. I thought about using PacketDispatcher.sendPacketToAllAround in updateEntity with a tick delay of 10 (so fires every 1/2 second), but that seems like an awful waste of bandwidth. There's no reason to keep updating any player near the block if the texture hasn't actually changed. Is there a way to identify when a player has moved into range of my block and send just that player the correct updated information via a packet? I've looked through the Minecraft base source and a bunch of Forge files but I haven't been able to figure out how best to do this. I don't want my mod spamming a ton of packets.
  15. OP, Speaking as a modder who, while I haven't yet released anything, has a very nice working mod under 1.2.5 and is currently updating to to Forge for 1.3.2, I can say with complete confidence that you don't know wtf you're doing and whatever you are doing you are doing wrong. If you are under Windows, download 7-zip at 7-zip.org and install that, then use it to add things to the Minecraft jar. I've found that if you are using WinRar, it really messes up for some reason. There, that's my helpful advice. As to any whiners begging for ModLoaderMP to return...any mod still using ModLoaderMP is doing so only because the author has a stick up their ass and refuses to make the MINOR (in most cases) changes needed to bring their mod over to Forge and allow compatibility with a TON of additional mods. That said, I LOVE the annotation system in the latest Forge. Thank you so much for making my life hella easy! Now if I could just figure out the weird GUI issue I'm having LOL
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.