Jump to content

SamMan

Members
  • Posts

    39
  • Joined

  • Last visited

Everything posted by SamMan

  1. Update, checked back on the PR today and its been now merged, thanks for the help in getting this back into forge diesieben ❤️
  2. If you want to keep things separate, in the launcher when creating the 'forge' profile you can set its directory to where you want your forge stuff to go
  3. I'm not sure whether to post this here or in bug reports but general rule of thumb is that its probably my fault so here goes: According to the forge docs at https://mcforge.readthedocs.io/en/latest/gettingstarted/autoupdate/, when a new update for your mod is released, it'll display a little blinking emerald icon on the mods button on the main menu, and in the mods menu. However, after getting it set up, the emerald does appear in the mods menu, but does not appear on the main menu? Main Menu: Mods Menu: So uh, not sure what's going on here? The update JSON is retrieved from https://us-central1-dfplusplus.cloudfunctions.net/getUpdateJSON Its currently equal to: { "homepage": "https://dfplusplus.github.io/webpage/downloads/", "promos": { "1.15.2-latest": "0.8.1", "1.15.2-recommended": "0.8.1" }, "1.15.2": { "0.8.1": "Added 'Either' chat side", "0.8.0": "Custom sizings for side chat", "0.7.0": "Added sound effects" } }
  4. Aah no worries then, thanks for keepin me real lol
  5. No dice at all? As in, with a good enough layer of abstraction and stuff I control, there's still no way I can leave all calls to that underlying code to small chunks I can replace much easier?
  6. Hello! I've been making a small utility mod for 1.15, for use as a client mod on a vanilla server (that supports connections from 1.15 and 1.16). However it's about time to update to support 1.16, which leads me with a problem. As the server has users on both 1.15 and 1.16, I really want to be able to release versions for both. 1.16 hasn't introduced any new functionality for the mod, so all features should be compatible on both versions. However, I really don't want to duplicate the entire codebase, as this would lead to issues when I want to add a new feature, as I'd have to program it twice (and potentially make mistakes twice) and it would generally be a bit of a hassle. So, is there a way to structure the mod such that it can be compatible, or at least built for both versions, from one codebase? The general idea is that I'd abstract away everything such that all orders to minecraft go through an interface, and then the interface will deal with the version specific stuff, but is there a way in Forge to pull something like this off? Thanks for reading ❤️
  7. Update: Nope, it was my fault, my accesstransformer was invalid.
  8. You have chosen death an unsupported version of forge
  9. It says 'Do not run this in a folder ending with !' You're running it in C:/Users/CARL!, which ends with an ! Move the jar somewhere not inside of the CARL! folder.
  10. I think the real error is right at the bottom, I'm having the same problem
  11. Hello! After refreshing gradle as I'd edited access transformers, I got this error, and all code from Minecraft became unresolvable symbols: Could not find net.minecraftforge:forge:1.15.2-31.2.0_mapped_snapshot_20200514-1.15.1_at_5001db69360629811200a9d34da2251e7eb6e597 It mentions that it searched (and could not find the file) in a few online locations, so I'm thinking this might be a problem with forge's servers?
  12. Thank you for your guidance! Took me a little while to figure out the access transformers but got there in the end. This thread really helped: but took me a while to work out I had to DM the MCPBot http://mcpbot.bspk.rs/help and have it tell me what line to put into the accesstransformers.cfg However, is that enough? What I mean is that when I want to override a certain function, like rendering or the one that splits up the line, after changing it to protected I still have to copy the entire method to perhaps only make a change to like one line, keeping every other line in the function just a copy of Mojang's code. Is this still ok? I suppose there's not much else I can do so I hope so haha
  13. Hello! I've been making a mod that seeks to change how chat is displayed, allowing for a better chat screen. I've got to the point using reflection where the game uses my NewChatGUI rather than vanilla's one, but still I need to reuse a lot of the functionality from the existing NewChatGUI, such as the rendering, meaning I have to copy some of the read-only Minecraft code. Some methods will change but some will stay exactly the same (jibberish names and all) Is that bad? If I'm redistributing code that I didn't write (though edited large parts of it), is this against the ethos of modding? Is this frowned upon by modders? Note, I'm not able to render over the existing chat GUI, it's gotta be fundamentally changed. Hopefully this makes sense, if not I should be able to put the code onto github
  14. At the very bottom of the KeyBinding class there's this function: Hopefully it's obvious what that function does.
  15. Now... I'll start looking into the next task - putting items in the chest
  16. A challenge eh? Well consider it accepted. So I did some digging for a good while, around in the item code. and eventually I found myself all the way up in Minecraft.java looking at the right click code. (Minecraft#rightClickMouse) Inside it I found the case for clicking a block: Which made a called to the handily titled 'func_217292_a'. A quick check in it showed that this was likely what I was looking for. So, by fudging a call to 'func_217292_a', it worked! The chest opened on the client. This made the necessary code: Minecraft mc = Minecraft.getInstance(); ClientPlayerEntity player = mc.player; BlockPos pos = new BlockPos(146, 68, -77); mc.playerController.func_217292_a( player, mc.world, Hand.MAIN_HAND, new BlockRayTraceResult( new Vec3d(0,0,0), Direction.NORTH, pos, true ) ); I wasn't quite sure what to put for the BlockRayTraceResult, but these values seemed to work fine. Thanks for the help! I'll look into placing items into the chest next...
  17. I see, thanks for the info Do you know which classes contain the relevant stuff for sending a fake click? I'd guess it'd be somewhere in the packet classes I'm not quite sure how to send those..
  18. Ah sorry, I mean on the second line of code: What should I set the containerBlock variable to? It can't be null or else I can't get a property from it. I can't set it to a BlockState since they're incompatible types.
  19. Gotcha, thanks! Any ideas what I set the ContainerBlock variable to?
  20. Thanks for looking into this a bit deeper! So I tried to implement those methods, and I feel like I'm really close (only one letter is bad!). Though yeah I wasn't quite sure what to set ContainerBlock to, as getContainer isn't static. It feels weird to me that this block object is used to get other blocks? I also wasn't quite sure what to make of the 'state' parameter. I'm not overly bothered what state the chest is in so I left it as null, but is that bad? Here's my code so far: aaa these sides always confuse me. I'm running this on a client connected to a vanilla server, and I check the side like this upon doing anything: So am I fine? Thanks for the heads up Thankfully this is a vanilla server so I shouldn't have to ever worry about those kinds of shenanigans
  21. Thank you for your reply! Ah I see. I did some digging in the ClientPlayerEntity class and found an openContainer property, nice! However is there a way to force the player to open the chest? I did an openContainer method on ClientPlayerEntity but its parameter name or type isn't too helpful...
  22. Hello y'all! I've been working on a mod that aims to automatically complete some operations with chests (from the client side). However this needs two fundamental features: Reading chest contents, and placing items into the chest (from the players inventory) Is there a way with Forge to do this? Thank you for reading!
  23. hello friend i am having a crash for beta 1.6 forge can you help me :((((((( In all seriousness though, look forwards to seeing what the future of 1.14 modding brings!
×
×
  • Create New...

Important Information

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