Jump to content

Ernio

Forge Modder
  • Posts

    2638
  • Joined

  • Last visited

  • Days Won

    4

Everything posted by Ernio

  1. 1. Your 2 last videos are private. 2. Loading chunks takes time, if you load 10 chunks/sec somewhere far away you can have problems. Besides, even if that is not the problem - you should never force generating whole thing at once. Make "recursive" TileEntity. You set one with e.g: "value=160" (value - number of sections left to generate). Then every, say 20 ticks make check inside that TileEntity - if next (neighbor) chunk is loaded -> place next tile entity with "value--" in next chunk and in this (current) chunk generate tunnel and remove this tileEntity. And so on to value=0. This way you will get nice on-load procedural generation that will no lag.
  2. You know the day is good when you beat one of design problems. GL11.glEnable(GL11.GL_STENCIL_TEST); // Turn on da test GL11.glClear(GL11.GL_STENCIL_BUFFER_BIT); // Flush old data GL11.glStencilMask(0xFF); // Writing = ON GL11.glStencilFunc(GL11.GL_ALWAYS, 1, 0xFF); // Always "add" to frame GL11.glStencilOp(GL11.GL_KEEP, GL11.GL_KEEP, GL11.GL_REPLACE); // Replace on success //Anything rendered here becomes "cut" frame. GL11.glStencilMask(0x00); // Writing = OFF GL11.glStencilFunc(GL11.GL_NOTEQUAL, 0, 0xFF); // Anything that wasn't defined above will not be rendered. //Anything rendered here will be cut if goes beyond frame defined before. GL11.glDisable(GL11.GL_STENCIL_TEST); // Turn this shit off! EDIT: Edited code to more universal.
  3. Question then - how big is the part of users that doesn't or could have some problems there? I am not gonna spend weeks on this design if it turns out that it doesn't work for 50% of ppl. ...if you would have to guess. EDIT: Wait... I think this is retarded question. Like... really retarded.
  4. Pre-init: Minecraft.getMinecraft().getFramebuffer().enableStencil(); Call: System.out.println(GL11.glGetInteger(GL11.GL_STENCIL_BITS)); System.out.println(Minecraft.getMinecraft().getFramebuffer().isStencilEnabled()); Out: 8 true P.S: Now that last part of comic... how to do rest
  5. After trying everything... does MC support stencil buffers? I think Forge did something in about 1.6.4 (or earlier) that was enabling stencil buffer, but idk if its still a thing - can't find anything. Do I have to do it myself? EDIT Everything points to "It doesn't". So question: How to create/enable stencil buffer without ASM (Minecraft#createDisplay())?
  6. @Deprecated != Deprecated Mojang miss-uses this annotation to mark "internal" methods that should only be overriden by sub-classes.
  7. I know this should probably go to stack overflow, but: When rendering with vertexes (we are talking 2D), you can pretty much draw anything you want - rect, circle, arc or like in my case - rect with arc corners. Now - coloring that shit is also simple, but what about applying repeating texture onto non-rectangular vertexes? Basically - what's the approach on drawing box above? Rules: * Background = repeating any texture. * Arc-corners = of any radius. * Outside of bounds (white border) will not be rendered (not included in image) EDIT Okay - I think using stencils is right way, but - any good tutorials on that?
  8. Please speak in programming - direct. You use random words that mess up everything you are trying to say. * extructuraTunel00 = Block * generarTunel = Block * tunelTileEntity = Tile Which block owns that tile? Which one generates 16x16 part of tunnel and which one does other shit? You explanation (to me) is simply too messy. As to problems - as long as you make not too many replacements per tick - you are safe. But also - you can't load too many chunks in too short time, that is IO and requires some power (but rather memory). Also - be sure you are ending previous processing (remove tiles after they finish or whatever).
  9. 1st of all - THIS! public void handleClientTick(ClientTickEvent event) { Minecraft mc = Minecraft.getMinecraft(); EntityPlayer player = mc.thePlayer; if (mc.inGameHasFocus && player != null) { player.worldObj.spawnParticle(EnumParticleTypes.SWEEP_ATTACK, player.posX, player.posY + 2, player.posZ, 0, 0, 0, new int[0]); if (ticksExisted % 2 == 0 && player.getRidingEntity() instanceof EntityDragonBase) { Entity dragon = player.getRidingEntity(); player.worldObj.spawnParticle(EnumParticleTypes.CLOUD, player.posX, player.posY + 2, player.posZ, 0, 0, 0, new int[0]); if (mc.gameSettings.keyBindJump.isKeyDown()) { IceAndFire.NETWORK_WRAPPER.sendToServer(new MessageDragonKeys(dragon.getEntityId(), 0)); } if (mc.gameSettings.keyBindSneak.isKeyDown()) { player.worldObj.spawnParticle(EnumParticleTypes.FIREWORKS_SPARK, player.posX, player.posY + 2, player.posZ, 0, 0, 0, new int[0]); IceAndFire.NETWORK_WRAPPER.sendToServer(new MessageDragonKeys(dragon.getEntityId(), 1)); } if (ModKeys.dragon_fireAttack.isKeyDown()) { IceAndFire.NETWORK_WRAPPER.sendToServer(new MessageDragonKeys(dragon.getEntityId(), 2)); } if (ModKeys.dragon_strike.isKeyDown()) { IceAndFire.NETWORK_WRAPPER.sendToServer(new MessageDragonKeys(dragon.getEntityId(), 3)); } if (ModKeys.dragon_dismount.isKeyDown()) { IceAndFire.NETWORK_WRAPPER.sendToServer(new MessageDragonKeys(dragon.getEntityId(), 4)); } } } } FASTER. CLEANER. BETTER. 2nd: Server alredy knows about sneak key being pressed (boolean in EntityPlayer I think, like #isSneaking()). I think server also knows about space but idk, probably. As to 3 others - they don't work meaning if statement doesn't pass or what?
  10. "But I can't find anything like that to differentiate the 2 pokeballs in my rocket pokelauncher." I don't quite understand? ItemStack is ItemStack, if you have its instance you can "differentiate" it anywhere. #clearMatchingItems is an utility method, if you can't use it where you want to use it - simply write your own...
  11. ChunkEvent.Load can fire your algorithm. As to "only once" - you will need to store some versioning number inside chunk (and e.g if version is smaller, then fire all previous versions, e.: chunk=3, but there is already 5th generation version, so you fire 4 and 5 generation algorithm on that chunk.) To do that you can use ChunkDataEvent.Load and #getData() where you will save chunk version.
  12. [/img] Try reading corpo code. As of now Forge API is very clear and Caps are way better than IEEP.
  13. Setup @SidedProxy, design choice: abstract Common { abstract File getDir(); } Client extends Common { File getDir() { return Minecraft.getMinecraft().mcDataDir; } } Server extends Common { File getDir() { return FMLCommonHandler.instance().getMinecraftServerInstance(); } } Packet client->server are limited and if you need big data - you need to split them manually. Packets server->client on the other hand are handled internally, so basically there is no limit as to what can written to buffer - it will be split into parts if too big. As to how much can be sent? Well - you can always throttle connection, but if operation happens per-login you are safe to send data in MB. Big note - you should NOT send xml files!!! Waste of memory and requires client-side decoding. Once you decoded them on server you can encode data directly to buffer and read it back.
  14. One of approaches: In common code (main file / common proxy) make MyRegistry field. In client code (client proxy) make additional MyRegistry field. Use common MyRegistry as a place to load and hold stuff from XML, no matter what side. Use client MyRegistry as holder for what client should use on current server. More detailed: 1. Use init events to read XML files and place stuff loaded from them in common registry. * For dedic it will be dedicated server data. * For client it will be fallback single-player data (which can be used when you play SP). 2. Use PlayerLoggedInEvent (which is fired only on server thread) to gather common registry data and send it to client - which will save it to client registry. * As you now see - no matter if you are on SP (integrated) or MP (dedicated/LAN) common registry is always present and no matter what you play - SP or MP - common one will be used on server thread (dedicated or integrated), and the other one (client's) will be use as display registry. * What you choose to sync is entirely up to you. 3. Just to stress things out: Your mod will have 2 registries - one for data holding, one for display, where display one will only exist on Client.jar.
  15. Hey, At this point everything I do pretty much converges to defining regions (regions - e.g: cities, guilds zones or non-/pvp zones and zone-based mob-spawning which is pretty much key in MMO Engines.) I am here for brainstorming and maybe even finding someone in doing mod/api with me 1. Let's define some stuff: * Regions are defined in X/Y coords with bottom and top (y1,y2) creating prism. * Rectangle ((x1,y1),(x2,y2)) - self explanatory. * Polygon (List<xi,yi>) - where polygon is only viable if its area is not 0 (which ensures that it has 3+ vertexes) and its sides don't intersect (those prerequisites will be handled internally on creation). * Circle - in future, so i'll skip it. 2. Let's bring idea into play: * Most of you probably know WorldGuard and unless something changed there, I don't want to do it like they do - running with wand around, but with a nice GUI (admin only tool). * Basic idea is to open editor GUI which will display currently loaded world and will request all visible (in range) regions and draw them using simple vertex based GL. * GUI will have creation and edition tools and will send update packets to server on demand (on change). * Regions will be saved mostly server side, unless needed otherwise - e.g (again admin tool) - we would want to render their sides inside world. 3. Let's bring image into play: ...and define some stuff: * GLOBAL will be region of world. * Regions will be tree based (I think). In image above we have: // Obvious tree structure: GLOBAL DESERT 1 (orange) FOREST (purple) RIVER (blue) LAGOON (brown) STRUCTURE (dark red) DESERT 2 (dark orange) // Not so obvious: CITY (red) LAKE (yellow) Okay so: "obvious tree" (B+ tree maybe) can be created because we have direct parent-child relations. * Note: We assume that RIVER is fully contained in FOREST (because on image it is not visible). The "not so obvious" refers to regions which are harder to assign. Now - how would one assign them? 3.1. Extend parent - region will have one assigned parent and will extends parent reach to borders of itself. * Problem - what if we want city to be partially in forest and desert, not just extend one of them? Here comes 3.2: 3.2. Have one parent region (the one drawn) and then internally split region into split-regions and assign them to proper parents. * Well, everything seems nice, we could have: // Obvious tree structure: GLOBAL DESERT 1 (orange) FOREST (purple) RIVER (blue) LAGOON (brown) STRUCTURE (dark red) CITY 1 LAKE 1 DESERT 2 (dark orange) CITY 2 LAKE 2 CITY (red) CITY 1 CITY 2 LAKE (yellow) LAKE 1 LAKE 2 ...but we kinda lose parent-child structure as split-region would have 2 parent. Okay so 3.3: 3.3. How about make it like 3.2. but also add "SplitRegion extends Region" that would be that "internal structure" and would have Region#parent and SplitRegion#parentInternal LAKE (yellow) LAKE 1 // parent = FOREST, parentInternal = LAKE LAKE 2 // parent = DESERT 2, parentInternal = LAKE ...which seems like we got it? In case of finding where we are, we would recursively climb by Region#parent so e.g: (LAKE 1, FOREST, GLOBAL}, while LAKE 1 could have #getName=LAKE.getName (fallback to parentInternal). 4. Algorithms and tracking: Okay so regions exist for us to know where we are (naming) and for all sorts of checks like spawning specific mobs with specific stats and in specific numbers. 4.1. Entity containment: (everything would be server side, and client would receive final form like one mentioned: (LAKE 1, FOREST, GLOBAL}) @Capability would hold current Region. 4.1.1. On 1st assign we would have to scan all regions in world to find ourselves, so basically big recursion. 4.1.2 On tick we would check if Entity#pos changed and then make all sorts of checks: * Entity leaves sub-region into parent-region. * Entity leaves sub-region and number of parent regions (number because we can have many recursive regions on border of something big). * Entity joins adjacent region or internal region. * Other shit that we have to account for... Note: Holy shit, we are closing in to big-ass data structures (if we want to have some speed). 4.2 Other shit I will probably mention in posts to come. 5. Minecraft problems: * How do you render visible world in a smart way? How could one make leveled rendering? (display everything from Y to 0, so I can e.g see cross section of high-ass tower and define floor sub-regions). * How do you render borders in world (vanilla does it, so easy to find, yet - ideas are appreciated). * How know what Regions to send to display on GUI? Heck, check all the Regions! * Other shit, idk. Okay - why does this thread even exist? The hell if I know... I kinda of started designing some of this and then even re-thought while writing this post. Basically - if anyone has some ideas (as to not only how to write, but what to write), some references, some algorithms (well, I know most), some polygonal smart-conversions (e.g converting self-intersecting polygon to a closed one, which will be used on poly creation), or anything of sorts - post it, right here! Also as mentioned before - if someone would be interested in coding it with me - feel free to say so and I will make open repo. Thanks for input P.S: Seriously - ANYTHING that comes to your mind, MC source is big and its easy to overlook some stuff. EDIT 1: Note - image shows 2 regions have shared border - I plan on writing algorithm that will auto expand region to adjacent ones (if possible) and also bucket tool for defining regions that are surrounded by others. EDIT 2: If you look at LAKE - it will obviously have more internal splits than {1,2} as it is being split multiple times. EDIT 3: 5.1. What if visible world is not covering the region we want to create? How could one force sending to client? How to prevent chunks to auto-unload? Maybe generate simple image on server and send it to client?
  16. While I agree - "set" (setStackInSlot) means that you are setting instance and should be literally "inv[slot] = stack", you can't argue with the logic behind it - If stacks are already equal = do nothing, else = set it to one you want. Still, this is not bug, rather design choice. Also - there most certainly won't be negation like you proposed. P.S: You can always override
  17. Okay, 1st question: Registry name is: modid:name Should unlocalized name also contain modid? // constructor // name = "block" this.setRegistryName(name); // internally converts to "modid:block" this.setUnlocalizedName(this.getRegistryName().toString()); // will set to "modid:block" // or this.setUnlocalizedName(name); // will stay "block" Does mc/forge somehow recognise per-mod lang translations? For "modid:block" I am getting for example: "tile.modid:block.name" - is modid needed? Asking because I've never did it this way, and I just saw this in some opensource. 2nd Is is safe to assume that calling GameRegistry from constructor is safe - I know it is a bad practice, but I also know that it works, question is is it safe for internals (I can't really think of critical cases).
  18. If you find me a tutorial listing all (probably about 15) methods regarding blocks, variants items-blocks and items in less than 5min - I will love you. If not - I am asking for a simple favor that can save me probably hour of looking and checking if given method is actually the right way. INSTA EDIT: Thanks D7 EDIT 2: K
  19. Hey there, I haven't touched blocks, etc in damn long time and I basically want quick update as to what you do. If someone could, please list every method you use in current modding of Blocks, Items and ItemBlock (I see there is no constructor taking ItemBlock?). Just methods and classes (for other magical stuff) and maybe other references, also client stuff and variants and shit like that) - basically everything that comes to your mind. Note: No need for any long descriptions. Thanks
  20. I think I remember your piece of code and it was something like: for (index : all) { player.inventory.decrStackSize(index, 1); } Learn what loop is, you are not supposed to loop through inventory. (because then indeed you will remove 1 from each stack). Just call: (current item is item held) player.inventory.decrStackSize(player.inventory.currentItem, 1);
  21. NO! Jesus... READ THE LINK I GAVE YOU! http://mcforge.readthedocs.io/en/latest/concepts/sides/ Client = Client.jar Server = Dedicated.jar You ServerProxy is supposed to be fired for Dedicated.jar and ClientProxy for Client.jar. Entity should be registered in pre-init on BOTH SIDES - thus either main mod pre-init OR CommonProxy method called from pre-init. Render should be registered on CLIENT, so in ClientProxy. CommonProxy is abstract base! // handler registering code for both sides ClientProxy extends CommonProxy // handles registering rendering stufff for only client ServerProxy extends CommonProxy // almost never used, but sometimes required to do stuff for dedicated server (e.g database connection) @SidedProxy(client = clientProxy, server = serverProxy)
  22. Post full code, best - on github. Problem: You are msot likely spawning/operating on entities on wrong thread. Note: http://mcforge.readthedocs.io/en/latest/concepts/sides/ Singleplayer = Server (integrated) with one player online (your client).
  23. Oh my god. Yeah... right... Please read javadoc of EntityRegistry#registerModEntity. Your tracking range = 0, which means client will probably never even spawn client-side arrow. For vanilla arrows range is 64 (such values can be found in EntityTracker). P.S: You should move this "ModEntities.registerRenders();" to client proxy.
  24. Classes: Main mod, proxies, entity, renderer and other related stuff (maybe rendering events?) I totally forgot to ask before - when are you calling #registerRenders()? (well, I'll se, just give sources). Note: It should (must) be called in pre-init. P.S: Okay, that "You don't know Java" was far fetched, but shit I read here sometimes... That argument is true in most cases.
×
×
  • Create New...

Important Information

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