yoshiquest

I'm using IntelliJ, not Eclipse.

Ok, I'm trying to create a rendering system, and I keep getting this crash: As far as I'm aware, I have lwjgl in the classpath, so what is the problem?

Yeah, that looks about right, thanks.

I have a few questions about rendering entities. First of all, I don't know what the RenderManager argument is and what I'm supposed to pass in (Jabelar's tutorial doesn't cover it). Secondly, I'm wondering how I could implement my existing system for TileEntities to work with Living Entities. Basically, instead of using a single model instance, I have multiple instances that the game cycles through. I think I could achieve the same thing if I set the protected model field before rendering, but I'd rather not set protected fields if at all possible due to the fact that if I don't have to set protected fields, I don't need to create a class at all (the proxy function from Clojure can create instances of "extended" classes, but can't access protected fields). But I might end up doing this anyways.

Ok, I just finished implementing it, and it works. You were right that the PlayerEvent.StartTracking event doesn't fire on the player themselves, but you were also right that PlayerLoggedInEvent was also an acceptable substitute. Thanks.

Ok thank you, I'll try this out then.

Ah, thanks, I thought I might have subscribed to the wrong event. This fires for the player themselves as well, right?

I'm trying to create a system that syncs entities and extended entity properties automatically. However, sometimes the first one or two entities it tries to sync return null when attempting to obtain them via getEntityByID, upon beginning a new world. This probably has something to do with threading, however I'm performing the sync at the EntityJoinWorldEvent, and according to the console, this IS being executed in the correct thread (the server logs "Error executing task" before the exception is thrown). So, what am I missing?

Ah, I understand. Side note: OOP is somewhat irrelevent, as the language I'm writing for is Clojure, which is FP (Functional Programming) instead. It is why wrapping around Minecraft Forge is quite a bit more monumental for Clojure than a language like Scala: I'm not only bridging the gap between languages, I'm also bridging the gap between mindsets. Anyways, I think I'm done with this, thanks again for all of the help.

I don't understand how this answers my question. Shouldn't the same be possible with or without an instance?

Actually, why DO we have to provide an object? Why not a class with static methods? For example, I wanna try putting an event subscription in my entity class, but I don't wanna have to have it registered every single time the entity is constructed, when just a static method will do (as the entity object gets provided by the event anyways). In fact, wouldn't calling static methods technically be faster anyways? So then why do we have to provide an instance?

Yeah, I think it's impossible. Minecraft Forge's event system is retarded. By that I mean it's very... static. But I suppose that perhaps instead of trying to keep everything in a single event class that gets modified over time, maybe I should just add event methods to the classes themselves. On a side note, I actually tried the global Event subscription idea I had. The game actually didn't lag for the most part. HOWEVER, core.async was trying to push too many events to the central channel. In other words, more events were coming in than could be sorted and subsequently dropped, causing a backlog of events that caused noticeable lag and constant complaints from core.async that it had too many events. TL;DR: You were probably right lol.

Hm, forge has a transforming classloader that it uses, right? Would it be possible to add subscribed methods to the event class using that, then re-registering the class, in order to allow for dynamic event registration?

Hm, would there possibly be a way to directly feed it a Method? Clojure can pass functions around like data, so I could probably make a way to register a function with the event handler. It would still directly call it as a method, but 1.) Wouldn't require a class at all (or an instance of one, it would function as a static method) and 2.) It wouldn't require method annotations (very annoying in Clojure). If you could just register an event from anywhere, it would open up a lot of possibilities, such as auto-subscribing to certain events (such as when syncing entities, or registering extended properties, for example). This is the main issue I'm facing that makes me want such a feature.

I've been writing a mod to integrate the Clojure programming language into Minecraft, and would like to add a better event system. This would involve shoving events into core.async channels, which would then distribute them across the mod. As such, I need a way to catch most, if not all, events in order to process them. So does subscribing to a parent class event catch the child events as well? Such that if I subscribe to just the Event class, I'll catch all events? Or on the other hand, is there a way to plug into the event bus, and handle events that way?

Got it to work! The following addition to gradle fixed it: Thanks!

Oh, that's nice! I'll have to test this.

ah, thanks. I'm not sure either. I'll probably have to either bug the people at Clojure about it, or create a custom version, probably. I might look for other options though. Again, thanks!

Ah, this helps a lot. Is there some sort of gradle magic I can use to resolve this, or will I have to go into tools.analyzer.jvm and manually change the dependency? No really though, thank you, I never would have thought of that at all.

Well, as you might already know, the mod I'm working on is one that attempts to integrate the Clojure programming language into Minecraft. It's working rather well so far, and in order to make certain tasks far simpler (networking, mainly), I wanted to include the powerful core.async library in the project (simply put, core.async allows you to write multithreaded-looking processes, while only using a simple thread. Apparently it does this by transforming your code into a state machine. Pretty powerful stuff). So, I've tried multiple times to include it, but keep running into this error. There is no mention of it in the error, and it's confusing as heck as I have no idea what Forge is doing at that point. BTW, if I DO manage to include it, I could potentially reduce simple networking to maybe like 3 or 4 lines of code + whatever you're wanting to do. So I'd really like to get this thing working if possible.

I'll try to keep this simple. Whenever I successfully include a certain dependency for a large project, I get this error (of course, things are a bit more complex, but it'd be hard to explain to a bunch of java programmers): I simply would like to know what the hell causes this error (under normal circumstances). The dependency in question isn't even listed in it.

After a lot of work (delayed due to college stuff), I finally finished updating forge-clj to Minecraft Version 1.8.9 with forge-clj Version 0.6.0!

Hm, I think I have an idea that might work. I don't need to run the entire game per say, but just need to change the classloader the thread that Clojure runs on is using. So just run those few things from a plugin and it MIGHT just work. Anyways, thanks for the help, I'll try some things out tomorrow.

Well, I'm simply wondering if it would be possible to write, say, a gradle plugin, that would set the class loader and register bootstrap before clojure gets touched. I suppose a simpler question would be: can gradle interact with the java environment it is running on top of. Such as for example, would it be possible to run pieces of Minecraft's java code from Gradle.

I already said that CLOJURE executes some code during ahead of time compilation. I know this is true, as I can place a print line statement in the middle of my code (not in any functions or anything) and the result is printed when compiling the code, without running minecraft at all. Still, if you really want the stacktrace though, there isn't much to see: