Leaderboard

Sorry, had my wires crossed and somehow combined your thread with another in my head. On closer inspection I see errors coming out of MoreCommands

sorry it took me awhile to figure out how to reply to you, i don't even know if this is correct i'm kinda new but. Yes i ran the installer and then i pressed on the server. i made a video here https://youtu.be/JUr2CtFnBpU Thank you so much for replying i really appreciate it. I just want to play galactica and make a moon base haha.

On ProjectE's wiki, it mentions an EMC mapper API. Digging through the mod's source code, you can get an instance of an EMC proxy (used to register EMC values) from the API's class. All you have to do then is use the provided registerCustomEMC() methods. You can search on GitHub for other mods using this API, if you need to.

In Blockbench, go to File -> Export and choose one of the options. You can use the exported files as normal. If you're doing a block, export as a blockmodel. If you're doing an entity, export as a java entity. Feel free to explore the other options too.

I realized that the FastTESR method of rendering (add vertices to a communal buffer, render buffer, throw away buffer and ask for more vertices) is, at least for my purposes, extremely wasteful. In my current situation, nothing changes location, so there's no need to discard the data after every frame, and reload it before the next. As a result of this concept, I've mostly circumvented the system: no longer contributing to the buffer, and simply using the method as one that is called for each frame, for each tile entity. Instead, when the graph is first loaded, I use the GlStateManager to generate a new call list (and delete the old one if it existed), and store the reference to this list within the TileEntity that I was given during FastTESR#renderTileEntityFast(). During subsequent frames, I then simply use GlStateManager#callList() to render the call list whose reference index is stored in the TileEntity. It isn't a standard use of the FastTESR system, but it does produce a 7-fold performance improvement, or much more, depending on the circumstances. The only problem this presents is that I'm no longer able to take advantage of the depth-sorting that's run on the vertices of the batched FastTESR buffer. This means that graphs are rendered "out of order," which is especially a problem for translucent ones. I can fix the problem of individual graphs rendering out of order (e.g: a graph behind is rendered on top of one in front) by moving the actual rendering over to one of the rendering events, and then drawing the furthest graph first, etc, but I'm not sure if there's a way of fixing the order within a graph being off, while keeping to call lists (BufferBulder#sortVertexData() isn't applicable to call lists). I'll keep looking, though.

Yeah, I love that, too. But what's the problem to have both things at once? Just install Forge and put Optifine into the mods folder.