-
Posts
1689 -
Joined
-
Last visited
-
Days Won
1
Everything posted by SanAndreaP
-
Well, I think I'll stick with a short datatype, because I have some more booleans to handle than 8 ^^
-
I know how to use bitwise stuff, but thanks Yes, I think I'll stick with bitflags for all my booleans.
-
1. ups, I saw a tutorial somewhere for dataWatchers which said that 18 are occupied by the superclasses (EntityCreature->EntityLiving->Entity). I've looked into these now and occupied are, as far as I saw, only 0, 1 and 8. 2. I would never use so many if I need those, but I looked in some classes which send the dataWatcher and it seems the dataWatcher will be send completely with all 32 possible fields, so it souldn't be that horrible. Please correct me if I'm wrong 3. Here's a list what I have to watch: These are needed, because they will be rendered from the soldier, for example if it has a blaze rod, it renders a blaze rod in its hand. I could put all these boolean stuff into one [short] field and access them with bitwise operators, but I just want to test stuff out before I improve the coding. But thank you for opening me the eyes because of these occupied dataWatchers. For now I can use more.
-
I'm trying to port the ClaySoldiersMod to 1.3.1 incl. MP compatibility. For stuff which should be shown on the clay soldier (like the stick weapon) will be handled per dataWatcher. Now I ran into a problem: the dataWatcher instance from the entity supports only 32 fields and 18 fields are already occupied for vanilla stuff. But I need more than 13 fields for the little clay soldier. So I decided to make my own dataWatcher instance, which is called "clayWatcher". The problem is that the clayWatcher fields are only updated when they spawn with this code: I want to make that the fields are updated while playing, like the dataWatcher, but I don't know how to do that. I probably have to send my own packets, but I don't know how because I never worked with packets before. So if someone can show me what I have to do or where I can look, I would be very thankful. Thanks in advance. EDIT: I will use bitflags for my booleans now to decrease the amount of needed dataWatcher objects. Also the superclasses of my entity (EntityCreature->EntityLiving->Entity) occupy only 3 (instead of 18 which I thought) objects: index 0, 1 and 8.
-
You can check, if (Block.blocksList[YOURID] != null). If it's true, it's occupied. If not you can use it. EDIT: here's a code example: public int getFreeBlockID() { for(int blockID = 140; blockID < Block.blocksList.length; blockID++) { if(Block.blocksList[blockID] == null) { return blockID; } } } the blockID in the for loop is initially set to 140, because it would be senseless to check the vanilla IDs. they're occupied anyway.
-
[SOLVED] DISCOVERY/BUG Client-Server-Synchronization /closed
SanAndreaP replied to Lartsch's topic in Support & Bug Reports
does it work when you have the mod in both, client and server, installed? -
[SOLVED] DISCOVERY/BUG Client-Server-Synchronization /closed
SanAndreaP replied to Lartsch's topic in Support & Bug Reports
well, I don't know why the smelting recipe does work for you even if you don't have the mod client-side installed (probably has something to do that the furnace smelting is only processed in the server?), but I'm sure crafting recipes need both client-side and server-side mod to work. -
[SOLVED] DISCOVERY/BUG Client-Server-Synchronization /closed
SanAndreaP replied to Lartsch's topic in Support & Bug Reports
You need a mcmod.info file in your zip package. It should look like this: https://github.com/cpw/ironchest/blob/master/IronChests2/mcmod.info -
If it would be so easy I've tried everything now... - outcomment all code with "boundingBox" and "axisalignedbb" doesn't work - outcomment all overridden methods (such as onUpdate() aso.) except attackEntityFrom(...), which now spawns only the particles and returns super.attackEntityFrom(...) (the rest inside it is outcommented) - create a completely new entity, which spawns continously particles and isn't related to anything in my mod (except the spawn item) It crashes with the same error. - using the worldObj.spawnParticle(...) in the new entity, which doesn't crash, but doesn't spawn anything either. Has this something to do with the worldObj field? Because both particle spawn things uses it. This is the spawning item code, if it's necessary: https://gist.github.com/9088b8e72638205dd129
-
Where/What function has replaced MinecraftForge.VersionDetect
SanAndreaP replied to jamesscape2's topic in General Discussion
Look here: http://www.minecraftforge.net/wiki/Tutorials/Upgrading_To_Forge_for_1.3.1 Maybe it'll help you. -
Sorry for DP, but I played around and did some code-fixing in my mod and I can clearly confirm it is the method FMLClientHandler.instance().getClient().effectRenderer.addEffect( [new entityFX instance] ); I tried also following: Minecraft.getMinecraft().effectRenderer.addEffect( [new entityFX instance] ); With or without checking if it's client-sided or not. I get often (not everytime) the error in the OP. If it doesn't crash I can see the particles properly. If I use this instead: this.worldObj.spawnParticle("reddust", a, b, c, 0.0D, 0.0D, 0.0D); it doesn't crash but it doesn't show any particles either. Also I tried this whole thing on a dedicated server. It doesn't crash in any case with any method, but it doesn't show me particles either. So did I do something wrong or is this a bug?
-
I think you need a mcmod.info file in your package. Dunno how it works, because I'm not nearly done with my mods that I need it now.
-
Then try instead of this: LanguageRegistry.addName(Deeper, "Dig Deeper!"); , this: LanguageRegistry.instance().addStringLocalization("deeper.name", "en_US", "Dig Deeper!");
-
It throws an error, because you try to add a name to an object which isn't initialized yet. You initialize it first after the name register. Try this: @Init public void DepthLoad(FMLInitializationEvent evt) { Deeper = new WorldTypeDeeper(11, "deeper"); LanguageRegistry.addName(Deeper, "Dig Deeper!"); }
-
Here ya go: https://gist.github.com/f876fb64b62074d7791c it is HUGE and it's messy (I've cleaned that up since I overtook the mod from KodaichiZero a bit). There are 3 lines where I called worldObj.getEntitiesWithinAABBExcludingEntity at line 643, 1210 and 1627. Even when I outcomment the code which uses this method and it crashes anyway. Remember, everything is called twice (server and client) check if it's called in client world and don't execute the code in this method: on top of the code: if(world.isRemote){ return; } Well, it has nothing to do with the list stuff, nor with code which are called twice. I checked my code again and found the crash maker. It's this: if(FMLCommonHandler.instance().getSide().equals(Side.CLIENT)) FMLClientHandler.instance().getClient().effectRenderer.addEffect(new EntityDiggingFX(worldObj, a, b, c, 0.0D, 0.0D, 0.0D, Block.cloth, 0, teamCloth(getClayTeam()))); on line 2669 in the method attackEntityFrom(); Is there a similar way to spawn custom particles?
-
Here ya go: https://gist.github.com/f876fb64b62074d7791c it is HUGE and it's messy (I've cleaned that up since I overtook the mod from KodaichiZero a bit). There are 3 lines where I called worldObj.getEntitiesWithinAABBExcludingEntity at line 643, 1210 and 1627. Even when I outcomment the code which uses this method and it crashes anyway.
-
I have a bug with the actual Minecraft Forge 4.0.0 build 200: I've rewrote my mod to the new forge build. However, spawning entities, rendering, interacting and such does work properly now for me. The only thing I have problems with is, that when I kill one of my entities, the game crashes sometimes (not everytime when I kill these) with this error: Here's the FML client log file: If I kill the same entities on a server, it doesn't happen, neither on the client nor on the server. On client-only, it's the same error and I dunno what's causing it. Here's my mod_ file, if anybody needs it: https://gist.github.com/4e3d7b2b13bb339601b7 BTW: My entity type implements IAnimal and uses currently the attackEntityFrom(...) method from the superclass (EntityCreature). Instead of this, there's no method in my entity class, which will be called on hit / death. Some more infos: Minecraft ver. 1.3.2 (final) Minecraft Server ver. 1.3.2 (final) MCP v.7.2
-
[Solved]1.2.5 some differend metadata questions
SanAndreaP replied to Speiger's topic in Modder Support
If you don't know exactly how to use and understand bit manipulation (bitwise and bit shift operators), look at this: http://docs.oracle.com/javase/tutorial/java/nutsandbolts/op3.html or ask google. If you know how to use it, look at this code from me, carefully: https://gist.github.com/09f4f1fc4a1918d78b79 Notes to this one: - I use initially negative damage values (e.g. in the crafting recipe) to "hide" the damage bar on certain types. - I use 5 bits for the type, so I can make max. 32 types (code with [bit operator] 0x1f and [bit operator] 5) Explanation: You see in the constructor: super(par1, par2EnumToolMaterial); this.setMaxDamage((par2EnumToolMaterial.getMaxUses() + 1) << 5); I use the EnumToolMaterial to get the max. uses. With the 2nd line I shift the max uses to the left by 5, that means I increase the max. uses to get the first 5 bits for the type. I had to add 1 to the max. uses first because somehow that caused problems without. To get the first 5 bits, there is code like this: switch(par1 & 0x1f) { case 2: return 224; case 3: return 226; default: return (par1 & 0x1f) + 236; } With value & 0x1F I get the value from the first 5 bits which I reserved in the constructor. 0x1F is by the way 31, so I could also write value & 31. To set the actual damage for this type, you use this: par1ItemStack.damageItem(1 << 5, par3EntityLiving); in your onBlockDestroyed / onEntityHit method. 1 is the damage value, it will be shifted 5 bits to the left (like in the constructor) to affect the damage. If the item should be damaged by 2 (for my swords when you destroy a block) just use 2 instead of 1: par1ItemStack.damageItem(2 << 5, par3EntityLiving); The onUpdate method here is unneccessary, because I doubt that you want to repair the stuff automatically ^^ But there is something important: You can't use the vanilla repair recipe (you know, place 2 damaged tools together to get a repaired one), because it gives a shit about reserved bits. I didn't tried enchantments yet, do they repair items when enchanted? If yes, you can't use them either. If no then you can use them. Okay, I hope I could help you. -
[Solved]1.2.5 some differend metadata questions
SanAndreaP replied to Speiger's topic in Modder Support
Unless you know how to use bit manipulation. So you take one or two bits of the metadata as flag for your tool type and the rest of bits can be used to determine the damage. Useful would be a getDamage() method to return the shown damage in the inventory. What I mean is, if you use bit manipulation, there will be always damage shown (except for one type). If you have this method, you can "cut off" the type bit(s) and the inventory will show you only the damage for that type of tool. Note that the metadata of items have 16 bits = 2^16 - 1 (-1 because 65536 is broken) uses = max. 65535 uses. If you take 2 bits for the type (for 16 types, e. g. if you want multiple colored swords), you have 14 bits for the actual damage left, that means 14 bits = 2^14 - 1 uses = 16383 uses. EDIT: Also you have to take one bit away, because the datatype for the damage value is, like every numeric datatype in java, signed, so it needs the bit to determine if it is positive or negative (negative damage would be more uses, taken damage wouldn't be shown in the inv. until it goes to 0) That means: available uses w/o 2 type bits: 15 bits = 2^15 - 1 = 32767 uses available uses with 2 type bits: 13 bits = 2^13 - 1 = 8191 uses -
Look at the IronChest2 source located here: https://github.com/cpw/ironchest/tree/master/IronChests2 It helped me a lot so far.
-
There are lines in your latest crash report, which caught my attention: 2012-08-15 13:59:57 [WARNING] Failed to load mod class mod_IC2AdvancedMachines.class in C:\Users\Petar\AppData\Roaming\.minecraft\mods\mod_advancedmachines-client-3.1.1.zip 2012-08-15 13:59:57 [FINER] THROW java.lang.NoClassDefFoundError: BaseModMp Try to delete this zip or put it into another folder so that it shouldn't be loaded. Looks like it depends on ModLoaderMP.
-
So we should use the curr. 1.3.2 pre-release for the curr. Jenkins build? EDIT: nvm. found out the answer ^.^
-
Sorry for DP, but I searched in the code again for a solution, rewrote my mod_ file to the new Forge system and stuff. I found out that I have to implement IAnimals now for my entities. I did that and somehow the entity is now registered. But as soon as I load a world with my entities or try to spawn them, I get this two errors together: So I tried to catch these exceptions in the Render file with try { ... } catch (NullPointerException e {} blocks. Then tried to open the world with my entities and I see my entities will be rendered now, but with "vanilla" textures like Creeper and spiders and even some with the /gui/items.png as texture, as seen here: As soon as I try to kill any of them, I get this error: So either I forgot something again or this is a forge bug. Here is my changed mod_* file: https://gist.github.com/4e3d7b2b13bb339601b7 Is there a way to solve this? EDIT: forgot to insert screen EDIT 2: If I outcomment the call super.onLivingUpdate() in my CSM_EntityClayMan class, I get this error, which is similar to that last one above:
-
1. Nothing Changed, My code: LanguageRegistry.instance().addStringLocalization("FrostedDirt" + ".name", "en_US", "Frosted Dirt"); 2. Yes I do 3. Hmm, Lex? 4. I crashed: This is weird for 1. this: "FrostedDirt" + ".name" has to be this: "frostedDirt" + ".name" for 3. I dunno how it works on Blocks, I used that only for my items so far and that works. for 4. then I dunno. How can it be a lowercase f when the Block is called FrostedDirt? The first initial has to be lower case. If you set the block's name like this: block.setBlockName("FrostedDirt") then you have to do this for that method, too (like this: block.setBlockName("frostedDirt")