Jump to content

Kirdow

Members
  • Posts

    11
  • Joined

  • Last visited

Converted

  • Gender
    Undisclosed
  • Personal Text
    I am new!

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Kirdow's Achievements

Tree Puncher

Tree Puncher (2/8)

0

Reputation

  1. I know this isn't really a topic directed at forge or minecraft, but since it's a forge mod I figured this is the right place. Having a game called Cube World finally out to the public, me and a friend of mine figured we would make the map/minimap a thing in Minecraft, that is the 3d map you can rotate, zoom and pan around in a 3d view rather than top down 2d. I got the rendering of this sorted out, but there's one slight thing that might be major that we want sorted out before initial release. Before we go into more details I want to mention that the mapping is done by generating a mesh when we find the chunk, together with a checksum to check for future changes. Firstly chunk is copied to a custom chunk format, then on a separate thread, generate a mesh out of this data, and lastly call the main thread to do any opengl calls necessary. Worth mentioning this rendering uses the vanilla map colours, with each axis having its own tint to make some depth, and the mesh itself is generated using greedy meshing, that is scanning left to right, top to bottom for rectangles with similar look, and creating 2 triangles from that rectangle, which result in much fewer vertices for the same result/outcome. But back to the problem, the task is to not render enclosed space, would it be caves, or even a bunker or a secret base in a mountain. As you may know, a 3d map you can view in actual 3d would cause more problems than a normal 2d top down maps in the sense of revealing stuff, like where ores are, or where someones base yet to find is located. On well over 50% of servers I'm been on, using map mods requires you to turn off caves in the map settings, as it could fall into the use of an X-Ray mod/hack. Because of this, we want to get some sort of algorithm to implement a type of system that would render what would be seen from someone flying above surface, this would include the stuff below trees to the most part and the overhangs on mountains (as much as we can do that is, nothing in programming is 100% perfect), but not caves below the surface, and if the cave is connected to the surface, it would render it, but cut off at some distance into the cave. This sounds good and easy on paper but in practice it's not that too easy if you've never done similar stuff before. At the current state of the code, we are currently looking for specific blocks like stone, dirt, grass etc, and when that is found, we increment a counter (how much depend on the type of block) and when an upper bound is reached, stop render the tiles (I want to point out this is done starting at y 255 down to 0, and does this for each xz coordinate per chunk). What I had in mind, was to follow the 8,8 coordinate in each chunk (or the average highest median coordinate), down until it reaches surface level. Then, from that point, if any emptiness is found nearby or below, use something like A* to find the distance and deviation from the straight line between those points, render stuff with little deviation, and ignore/blacken stuff with much deviation. The distance variable used in A* would also play a huge role and would also have priority over other rules in use if it would get too long. This is the best I could think of myself, but I'm not fully sure how this would pay out in practice, thus I come here to ask if there's anything I could do in any other way, to give a good result, while still not going too complex. Note: I'm not asking for direct code, just what algorithms I should use, in what way and stuff like that, relative to the ideas I already have, and what is currently in use.
  2. Well that was pretty weird. So I realized I wrote about git pull so I decided to look in my git repo and commits, and found a strange thing where the commit where I made a custom ArrayList override called ListTweaker, there was a change to build.gradle which changed all net to tweak which I have no idea how that could happen (since I'm the only one on this project), I'm guessing some select all or similar action happened which searched all files by mistake. Nothing major, everything sorted out. Gonna add [Solved] to title
  3. So I just went back to work on a project after not working on it for a week (after being sick), I recall I was working normally like you usually do, and everything worked fine. I then took a break and worked on other projects, got sick half a week and now I was about to get back to that project. However I noticed the project had missing dependencies as soon as I launch IntelliJ. I decide I want to fix this, my first thought was to do gradlew setupDecompWorkspace as that's what I usually do right after I run git pull in case something happened in that manner. However I instantly get an error, which I will get to later. I then try to look up the error, search a few times and can't find any relevant info. I did find people having similar problems but all solutions were the same, to run gradlew setupDecompWorkspace --refresh-dependencies or simply gradlew --refresh-dependencies, both of which I already knew of, and both also gave the same error as above. So the error I get when I ran that command is the following I decided to search this forums for stuff, I searched for "Unable to load Maven meta-data from" which ended up giving tons of results, none of my interest I then decided to search up "tweak.minecraftforge.gradle" which I found gave no result at all, and also "files.minecraftforge.tweak" which also gave no result. At that point I felt I was clueless and had no idea, and decided to make this post. Any idea? EDIT: The console command is run from inside IntelliJ just so you're aware. Might look inconvenient otherwise
  4. I am aware of this. I'm sure as long as you don't do too specific tasks with this it should be fine, I'm currently only going to use it in one if statement so I'm sure it will be fine. But then again it's Java so anything could happen I'll probably revert back if this starts causing any problems though.
  5. Oh I forgot about this one, thanks, I modified the enum's constructor to use this instead. Just to help out future visitors, this is the code I put in the constructor for it to work. private RarityGlowType(int id, String name) { this.id = id; this.name = name; try { EnumHelper.setFailsafeFieldValue(ReflectionHelper.findField(Enum.class, "name"), this, name); System.out.println("Successfully changed RarityGlowType name!"); } catch (Throwable throwable) { throwable.printStackTrace(); } }
  6. I managed to fix it. So while trying to find how it gets the value, I realized something I noticed a few years ago, how enums during compilation gets turned into a class extending Enum. This means my RarityGlowType would instead result in a public static class RarityGlowType extends Enum Now I looked at my enum's super class to get to Enum, and Enum has 2 variables, "name" which is a String and "ordinal" which is the index. the "name" variable is returned in a method called "name()", though since all fields and methods are final I can't override them. So I decided to look up if reflection allowed modifying final fields and found this stackoverflow answer . So I took that code, and put it in my enum's constructor resulting in the following code public enum RarityGlowType { SOLID_COLOR(0, "Solid Color"), GRADIENT_COLOR(1, "Gradient Color"); private int id; private String name; private RarityGlowType(int id, String name) { this.id = id; this.name = name; try { Field field = Enum.class.getDeclaredField("name"); field.setAccessible(true); Field modifiersField = Field.class.getDeclaredField("modifiers"); modifiersField.setAccessible(true); modifiersField.setInt(field, field.getModifiers() & ~Modifier.FINAL); field.set(this, name); System.out.println("Successfully changed RarityGlowType name!"); } catch (Throwable throwable) { throwable.printStackTrace(); } } public int getId() { return id; } public String toString() { return name; } } And while running this in IntelliJ it successfully showed up as "Solid Color" and "Gradient Color" like I wanted. Just note, as the stackoverflow answer states, if the environment has some sort of SecurityManager blocking changing the modifiers, this would break, so hopefully this wont break when the version is released to the public.
  7. So I currently have an annotation based config class fully set up and working. Though one of the properties is an enum, and I don't like the way that it shows the enum instance name, I want to have a custom string for each value I currently have this code, where I added a String property and put it in toString to return the name, but it still use the enum variable text to display in the configuration menu. (note that I use the built in menu automatically generated by Forge upon using @Config ). // This is inside the root class for the config file public static class Inventory { @Config.Name("Rarity Glow") public boolean rarityGlow = true; @Config.Name("Rarity Type") public RarityGlowType rarityGlowType = RarityGlowType.GRADIENT_COLOR; public enum RarityGlowType { SOLID_COLOR(0, "Solid Color"), GRADIENT_COLOR(1, "Gradient Color"); private int id; private String name; private RarityGlowType(int id, String name) { this.id = id; this.name = name; } public int getId() { return id; } public String toString() { return name; } } } Basically this makes the config gui show "GRADIENT_COLOR" as the default option while I want it to show "Gradient Color" as returned in RarityGlowType#toString How would I go ahead and fix this, without creating my own config gui of course?
  8. Hello. So I've been working on this mod for just around 2 years, and currently I'm adding a feature where items with a specific rarity glow just like with spectre arrow in the rarity of the item. Just a disclaimer, the project I work for is closed source so I wont be able to link to the git repo, but I do have in fact narrowed it down to a single OpenGL feature which shouldn't require my original source. So back to the topic, I do have this feature 100% working and so I'm not here with help for that. Currently, my problem is maintaining compatibility with my previous features. Basically I have a lock item system where you can lock the items and not drop them. These items are indicated by a lock texture in the top right corner of the item slot, overlaying some of the item. Now getting the glow requires using shaders, which in turn requires a separate framebuffer, atleast to my knowledge. The system took just over a day to get working flawlessly, until I wanted to render the locks again, and noticed they are at the wrong location of the screen, which is the top left corner. Having had this type of problem before I knew it was the scaling (from Gui Scale in video settings) reset, and I assumed it would be in the glow render code so I commented that out, built the code (Gotta love IntelliJ HotSwap <3), and noticed that the lock did indeed pop back to where they belong. After this it was just a matter of closing down the code step by step until I had only one part. I found last call made by me affecting the problem was Framebuffer#framebufferRenderExt. Now from reading help threads I knew this wasn't enough so I looked in the method and saw 2 key components. Resetting the view mode (in this case Orthographic), and resetting the viewport. I went into my main code for the gui rendering again and commented out the glow code call, and as a test, added a reset for orthographic just to test my theory and indeed that was the source of the problem. Just for reference this is a small illustration of my method at that point @Override public void drawScreen(int mouseX, int mouseY, float partialTicks) { // irrelevant code GL11.glPushMatrix(); GL11.glMatrixMode(GL11.GL_PROJECTION); GL11.glLoadIdentity(); GL11.glOrtho(0, mc.displayWidth, mc.displayHeight, 0, 1000f, 3000f); GL11.glMatrixMode(GL11.GL_MODELVIEW); GL11.glLoadIdentity(); //RarityGlow.renderGlow(this); GL11.glPopMatrix(); renderLocks(); } Now my first thought was to somehow push the matrix mode or view, and thought of glPushAttrib. I looked up the problem on google, both for forge and in general, and found that pushing GL_TRANSFORM_BIT and GL_VIEWPORT_BIT should do the trick. I did try this, but that didn't work. So my current concern is, how would I go ahead and push/pop (or similar) the state in order to solve this said problem? Edit: Also noting this is 1.12 which means Java 1.8. Forgot to mention that.
  9. As you saw from the title, when compiling my code, the compiler switches a variable around making the code crash when starting the game. I'm first gonna say that I am not new to Java, I have used Java for 6 years and I know not everything but far more than the basics. So currently me and a friend are making a mod for our own modpack, and it's going well. The mod has well over 20k lines and we already have 100k downloads. But just today as I was about to compile it and test it "on the production line" if you get what I mean, I noticed something I have never experienced before in my time of coding in Java. Basicly the compiler, switches around which variable I assign, meaning the code works fine when running in eclipse but when you run it after releasing it, it does not work. So the code it occurs in is our Party Chat feature. It's basicly the main chat but moved to the right of the screen which only shows messages from the party chat. Also note here that this mod only works on a minecraft MMORPG server that most people should know about by now. We recently updated from 1.10.0 to 1.12.0, and today is the first time I myself tries it outside of eclipse after updating. So about giving code. I'm currently modifying the vanilla code and adjust it to our liking, but something strange happened that didn't happen in the 1.10 version. I have this code in the party chat, I'm creating my own Logger variable from GuiScreen, with the same name as the GuiScreen one. This has worked before and only became a problem when we updated to 1.12. So the source looks like this: public class GuiPartyChatbox extends GuiScreen implements ITabCompleter { private static final Logger LOGGER = LogManager.getLogger(); [...] This works fine when running in eclipse, as we clearly state that our LOGGER variable is equal to LogManager.getLogger(); Now however, when I compile it, it changes which variable it assigns. How? Well as you know the compiler changes "static <type> <name> = <init>;" into "static <type> <name>;" and "static { <name> = <init>; }" and this is where the problem occurs In GuiScreen, we have the same line at the top of the screen, which when obfuscated has the name "field_175287_a". So I kept digging to find a reason for the crash, until I decompiled the code using Cavaj Java Decompiler (very old decomp but it still works... sort of). What I found was that the code had changed from the one above, to this. public class GuiPartyChatbox extends GuiScreen implements ITabCompleter { private static final Logger LOGGER; [...] static { field_175287_a = LogManager.getLogger(); } } This means instead of initializing my LOGGER variable it tries to initialize the one in the super class, which in this case is obfuscated. This means that gradle obfuscate my variable because it has the same name as a variable in the super class, despite that class being set to private meaning I can't access that variable, making me crash with this crash report on startup: Caused by: java.lang.IllegalAccessError: tried to access field net.minecraft.client.gui.GuiScreen.field_175287_a from class com.kirdow.enhancewynn.logic.gui.GuiPartyChatbox at com.kirdow.enhancewynn.logic.gui.GuiPartyChatbox.<clinit>(GuiPartyChatbox.java:353) I'm not sure how to fix this other than renaming the variable but that to be honest doesn't seem to be the real option, as that's not really how it's meant to be, is it? So if I can't rename the variable for some reason, what choices do I have to fix this problem or is it just to wait for a fix by a new update (if there isn't one already)?
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.