N247S

It's own implementation of what? And how would Minecraft "override" that implementation if it is built in Java? nvm, I got confused with something else.

@LexManos , I am suprised you looked the MCIndicators up. and yea, its a total mess wich I already have redesigned but not pushed yet. The main problem is that generics involvement is giving problems when registering a universal capability object.(because of the Class<T> parameter) I tried to solve it by dynamically registering a capability per indicator, wich should give less problems (especially with the getDefaultInstance() thingy). But I have tried to work that out a litle bit more, and technically it should work although it doesnt feel right to me. (pretty messy, and fail prone) So I propably will go for a central wrapper object, and take the extra synchronizing of non changed values instead. I hoped that I could exploit the @CapabilityInject Annotation mechanism which is a pretty cool feature in my opinion. Anyway thanks for your comment! N247S

Alright, so I assume that there is no 'normal' way to get the Capability object instance wihtout hardcoding stuff, too bad. Anyway Im going to rely on reflection. And just like the Capability injection does, I'll try to work around doing that during performance sensitive operations. Thanks for your help! Hope they add a simple getter for this in the future Btw, just to make sure, the net.minecraftforge.* part of the Forge library doesn't use deobfuscated names right? N247S

that might play a role in the story as well, although I thought that java has 'fixed' that problem with its own implementation. But at the same time openGL handles almost everything in its native library, so that wouldn't help verry much .

Erhm.. Im pretty sure Forge is creating an Capability instance in the CapabilityManager#register method, and populating/calling every @CapabilitInject annotated field/method. although its pretty much checking if the 3 passed arguments are not null, and passing those through to the Capability constructor. besides I know how the Capability CLASS() works, the problem is that I need the instance for the ICapabilityProvider/ICapabilitySerializable for nbt writing/reading (and preferably for the 2 checking methods). It all works fine, though the flaw is, that there is no way to get those singleton Capability instances without FailProne reflection or hardcoding a @CapabilityInject a field/method(which I cannot use because of the problem described in the first post). SO just to make it simple. I need an the singelton instance of the Capability stored within the CapabilityManager preferably without reflection. Is there a way to do so? if not, Ill use reflection for now. thanks for the replies!

I think there wont be an automatic workspace installation like on Eclipse and IDEA . but if you can do it manually you are good to go.

@swordkorn I have to disagree on that one. There are plenty of applications supporting real-time-collaboration. after less than a minute of googling I came accross this. https://iprodev.com/20-best-code-editors-for-real-time-collaboration/ @DireWand maybe you'll find something in this link, otherwise google is your friend, Im sure you'll find something suitable for your needs.

I defenitly dont wanna make my own Capability instances. thats whats forge should do for me. though you can use them to get new default instances, get the IStorage singelton etc. and first and foremost, they are used as identifier in the ICapabilityProvider (getCapability & hasCapbility). So it would help a lot if you can get them without hardcoding an annotation, like I described, via a annotated method or as a return value from the register method. I could go for my own identification/defaultInstance/storage system, though why should I if those mechanics are already there... only unreachable atm.. (just to make sure, I register capabilities dynamically, I dont use a general or a hardcoded one!)

I think its because of the inconsistency of the mc positions? I once had a severe issue with moving polygons rendered from the mc particle system. The problem was that the players/camera position is updated/moved during rendering meaning the data passed to the render code is not valid anymore. Now I dont know if you use the players position at all, but for me the solution was to get the players position actively instead of using the passed values. But again I dont know if you use the camera/player position at all. Aslo when messing around with that stuff, a small offset(on the screen) for a polygon 1 block away is almost not noticable, while that same small offset for the millions blocks away polygon may have a much bigger impact. Especially if you are able to stroke it on your enviroment. Besides keep in mind that your polygon might be smaller than one pixel. Which can also create unespected result. Anyway just some thoughts about this problem, tbh I dont know the exact problem, though I hope this was helpfull.

Hey, Im trying create capabilities dynamically using the new capability system, though I came accros a litle problem. For the system to work properly I need an instance of the capability which is created after calling: CapabilityManager.INSTANCE.register(); The thing is that I provide a base structure for the actual Capability itself. meaning the registered Class is always an subInstance of my base structure. And because of that there is no way to get the instance, since the @CapabilityInject annotation does not support the use of superclasses. So for example if I have an interface called "ICapBase" which people should implement in order to use my system. If someone implements this interface and register it, there is no way for me to get the capability unless I hardcode that into my system. because the following doesn't work! @CapabilityInject(ICapBase.class) Public static void onInject(Capability<? extends ICapBase> cap) {} Before I go to Forge's github and make a possible fix, I want to make sure I dont forget something which would solve this problem. If there isn't any there are 2 fixes: 1. modify the current system so the above code would work. 2. simply return the capability from the #register method (from which I dont understand why that hasn't been done in the first place). anyway, Im looking foreward to your opinion about this. N247S

Aint this possible with a simple langFile? E.g. adding it as resourcePack content? Otherwise, try to figure out how the vanilla Lang files are loaded, and start from there. If Im correct you wont need reflection that way.

I can try to explain everything in detail, though your link is broken, so I cannot help you pointing exactually to the problematic code. Maybe its better to learn about the error itself instead. Googling the error, and the first hit is: this:http://stackoverflow.com/questions/27525323/openglexception-cannot-use-offsets-when-array-buffer-object-is-disabled-on-a?lq=1 I think you can figure out the problem yourself after reading this, otherwise please fix the link. Hope this helps!

Unfortunatly I dont see anything wierd/mistakes so far. Just to make sure, your particle is rendered but only with the default black and purple texture? Either that is your texture , or there is something going wrong with the ResourceLocations, although Im sure it would give some kind of error. So I am sorry, but I think that Ii cannot help you further with this. Try some extensive debugging, and see where strange thingd are happening.

Just a small tip, if you want to adjust the particle's velocity after initialization, just move the calculation part from the constructor to the 'onUpdate()' function. On to the texture bug, if it is black and purple, you deffenitly need to see some kind of error in the logs, otherwise that default texture wouldnt appear. Furthermore you can mess up as much as you want on the texture size etc. Opengl will render it nontheless. The only thing that might happen is that it might not be rendered as you would like it to be.

First of all, dont copy paste stuff if you dont know how it works! Its better to figure out every single step on your own. Second, you redoing a part of the velocity calculations in the constructor, with the intention to change the velocity each tick.... I hope you know that a constructor is only called once per instance? Furthermore, In your StichtEvent you register a 'CopperCrucible' texture, while in your FXClass you are searching for a 'particles' texture. Any idea what is going wrong here But appart from that, everything seems normal meaning that if the above isnt the problem, you got to debug everything till you find the problem. Ps. You could try to spawn in the particle without any velocity to check if it isnt flying out of view the second it spawns. Hope this helps you on the right track.

Well, is there anything to see in the logs? And for the code part, I would like to see the particleClass itself, and the part where you spawn in the particles. Besides, if you init the ResourceLocation of the particletexture outside the particleClass, please show us that part as well.

I cannot sence your mistake, so please show some code if you want specific feedback. For now I suspect that you are spawning the particles on the serverSide? But Im not sure, so again, please show what you have so far.

Thats what I was afraid of. The writeUTF (UTF16) method is not compatible with readUTF8String (UTF8). Use either readUTF or writeUTF8String instead. Ps. Dont change both parts, or the same problem will occure again .

So you are not 'writing' the messages? In that case you would need to use the bukkit/NettyIO system for reading. (Unfortunatly Im not verry familar with bukkit, though Im sure youll get it right.) As for the 'longer messages crash', it is pretty wierd, either they are writtin differently, or this is a bug from Netty. Not sure wich version is used by MC right now. Though it sounds rather familar, I believe that a simular problem made me choose to use the java BufferUtils system instead (as I would advise you to use it as well, if possible). Finally, have you updated the mod from 1.7 to 1.8 or 1.8 to 1.8.9? In the fisrt case, recieving messages is moved to a sideThread. Otherwise no major changes have been made. Unless bukkit has changes their system, but you would know that better than me! I hope this us enough info for you to go on, since I have no clue what else can be done, unless there is a flaw in your code(which I cannot see from here )

What is the exact problem right now? You dont use the bukkit (partially?) system for some reason, so why not using the mc system instead? (If fixing read/write methods isnt possible?). I would like to help, but right now I have no clear vision of your goal is. Besides, if there is no (complete) code of what you have tried already, its nearly impossible to help solving this bug. So could you explain exactly what problem is still standing. And post some code of the things you have tried already.

Nope, the serverSide TileEntity is for all the logic behind a block. The clientSide one is for rendering, since values can be shared between server and client through the read/writeToNBT methods. That way there is no need for a complex packet system. ClientSide rendering can either be a gui (chest items, furnace progress etc.) Or an animated block model(which animation is dependend on the tileEntity values. (Smelting furnace etc.). So no, no need to prevent the initializing of a tileEntity on either side. Even if you dont use it on the clientSide.

This is actually not a crash from a too long package, otherwise it would mention about something like the 32k border. Assuming you defenitly wont pass that point. The actual problem is that you decode the recieved buffer wrong. Reading should be done in the exact same order as Writing. (Might have confused mc's read/write String method with the java's Buffer one). Your attempt to decrease the size of the packets are defenitly not helping in this case. So pharaps the 'bigger' packets you are sending are read in a different way than you are writing them I hope this helps you a bit in the right direction.

Than thats a pretty bad tutorial in my opinion. The only particle that is spawned server side is the xp-orb. But thats because it should be able to be picked up by players. As Ernio said, spawn it ClientSide by either using packets, or using a ClientSide event/method. Maybe try to find where vanilla potion particles are spawned from. Cause than you would be able to implement yours as well!

Which particle should it spawn? I miss that parameter in world#spawnParticle which determine what particle should be spawned.

@Draco Lol, I said it the other way around indeed. @wilLink If that is set correctly, maybe playing around with the renderType?(Dont know what number you need exactually, I dont have acces to my IDE right now) Otherwise you might need to add some lightning adjustments inside your tileEntityRenderef code. Though I higly doubt that it would be necessary.