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.