GenElectrovise
Members-
Posts
132 -
Joined
-
Last visited
Everything posted by GenElectrovise
-
What is the error you get? Does it simply do nothing? Or does it tell you that the operation cannot be completed? Or something entirely different? Edit: You say you can't even give permission? So the option is simply not available? Where are the files stored on your PC? Or does it deny you when you try?
-
World Edit saves schematics wrong
GenElectrovise replied to Breadsilence's topic in General Discussion
I don't know, but I suspect they are the same thing. Try making a backup and changing the file extension. They probably both store data the same way -- like .nbt and .schematic are interchangable (to my experience) when generating structures from structure blocks. -
Hi @TheGreyGhost! Yes that's quite helpful, but I've tried implementing it and I'm still getting all defaults on the AltarContainerScreen (renamed from AltarScreen for greater accuracy). I noticed that you're not using capabilities, but that shouldn't affect data synchronisation, should it? The AltarContainer is updating correctly, and also now saving to NBT properly, but, as I said, the AltarScreenContainer continues to default... Any ideas? Btw it has 4 item slots in addition to energy
-
Solution: https://www.minecraftforge.net/forum/topic/85900-1152-sync-energy-level-of-a-tileentitys-energystorage-to-a-gui/?do=findComment&comment=405145 (This is just the my final comment with a link to the commit. For the actual infos, you'll have to look through everyone else's comments ) === Pretty common issue, but I can't seem to suss it out. I have a TileEntity with a custom EnergyStorage implementation (enabling me to change its capacity more easily). I need to be able to display that energy level on a GUI (AltarScreen). Once that data is in the screen, I can display it, so the issue is in getting it there. I have passing the values down from the TileEntity, but when the AltarScreenManager creates the AltarScreen, the current- and maxAmethystFlux are always their default values of 0 and 50. Pretty sure this isn't good practise -- reaching across sides, with the Screen being on the client and the Container on the server -- but either way it doesn't work. I believe I need to be sending packets whenever the stored energy of the AltarTileEntity changes, but I can't work out how to do that. I've put some of the framework down, but how are the messages sent and received? How do I ensure that only the correct AltarScreen receives the data? It wouldn't do for all of the Altars in a world to display the same energy all the time! Here is a link to the altar package of my GitHub repo.
-
I wouldn't say you'd need a custom TileEntity per se? Have you reviewed the documentation on Models? https://mcforge.readthedocs.io/en/1.14.x/models/files/#model-files Blockbench can help with making the models, though you'll still need to code them together yourself. IProperties could help you here -- for example you could have a bunch of BooleanProperty s in your block, one for each side of the pipe. If the "up" property is true (i.e. there is a pipe above this one), the BlockState json can detect that (if you define it) and change the model accordingly. I think these are called sub-models, but don't quote me on that. Although it isn't quite what you're looking for, here is an example of a complex model and here is its blockstate. It only has one state, but I think it serves as a fine demonstration mostly ?
-
All working! I used DeferredRegister again instead of RegistryEvents, as I could reuse the code from before. For anyone who is having the same issues, this post helped with the last error. The relevant classes on my Github are in this package for the Altar classes. and this package for my registry. Thanks @Draco18s! Great EasyRegistry, but you might want to update that sometime . You don't seem like a "complete and utter jerk" to me! -- Remember to override the read and write methods to your TileEntity if you want data to be persisted through saves! Examples are on both mine and @Draco18s's GitHubs repos If I think of any more helpful things for people with this problem, I'll add them here. Ps. How do I close this thread? Can only moderators do that?
-
Ahh! But I overthink and forget! I *do* have an object! What else am I registering!? Now I get an error when I try to open the GUI... Can't find the right ContainerType ? Looks to be something to do with NetworkHooks not being able to "Unable to construct this menu by type" (seems pretty obvious). I'm passing in a ServerPlayerEntity, AltarTileEntity and the TileEntity's position. Have to check if one of them is null, but I'd expect NullPointerExceptions then, not this... Time for a break. I'll resume this tomorrow. Many thanks!
-
Ironically, I found all of these just before I saw the message. For the moment, if you don't know how to register a ContainerType with DeferredRegister, where would one set the registry name of the ContainerType to be registered? EasyRegistry does it at https://github.com/Draco18s/ReasonableRealism/blob/033da26f8ba4bcd25b0911aa9775764f12d7dbbe/src/main/java/com/draco18s/hardlib/EasyRegistry.java#L89, but this to me doesn't seem to be what I need, given that I'm not using your EasyRegistry system. To set it in the event, I'd need an object to call the method on. Constructor is a no-go because it's called later... Any ideas?
-
Yup found that . CommonContainer is as well -- very helpful class! All is looking good *so far*, but yet again I am wrestling with DeferredRegistry... Where is your registry in your repo? The error I am recieving is that "The constructor ContainerType<AltarContainer>(AltarContainer::new) is undefined". How are you registering yours? Another hidded error is that "- The type AltarContainer does not define AltarContainer(int, PlayerInventory) that is applicable here". That could be fixed by adding another constructor with the applicable arguments, but what could I pass in as the PacketBuffer / IItemHandler and AltarTileEntity to get into another of my constructors...
-
Ok, @Draco18s, I have added and pushed the changes to GitHub, but as yet, I can't test the new functionality as I believe ICustomContainer, which you are using to open the container has been removed between 1.14 and 1.15.2 (I believe your repo is 1.14.x?). What has it been replaced by? I can't seem to find any useful sounding interfaces with "Container" or "Gui" in the name... Am revising this right now
-
You say you are using a 1.12.2 environment, yet you link to the 1.14.x documentation? Which version are you using? Can't help with oredict, though! Haven't tried it yet, though will need to sometime soon!
-
Solution: https://www.minecraftforge.net/forum/topic/85745-1152-usage-of-capabilities-to-make-an-inventory/?do=findComment&comment=403277 Be sure to reference the rest of the thread though! === Hello all. I am trying to make a block (Altar) which the player will be able to interact with. I have already made an GUI for it using this very helpful post and by using the enchantment table's own code. The downside of using said enchantment table code is that it does not use the Capability system which the forge documentation promotes. My current inventory (*contained* in ContainerAltar in my repo) mostly works -- the player's inventory is displayed correctly and can be interacted with, but any items which I place into the Altar's 4 Slots vanish when the GUI is closed (kind of understandable considering I'm doing nothing to persist the data. I think this is where IItemHandler comes in?).I have fiddled a bit with Capabilities before, but never had much success, so before I end up writing something bodged and half-working etc., I though I'd get some advice. How can I use the Capability system (if that is even the best way!) to: - create an inventory with 4 slots which the player can interact with through my GUI - ... which will persist inside the Altar across openings. GitHub: Here is the Github repo Directly to the Altar package: ... and here is the package in question Many thanks in advance!
-
[1.15.2] Ore generation with DeferredRegistry
GenElectrovise replied to GenElectrovise's topic in Modder Support
Can do! Thanks! -
[1.15.2] Ore generation with DeferredRegistry
GenElectrovise replied to GenElectrovise's topic in Modder Support
I am aware of this and have been very successfully using this for Items and Blocks. My question is how to generate ores in the world, registering the Feature / Generator using DeferredRegister. Following the advice of my own signature, I have found another thread asking about general ore generation in 1.15 and have combined that information with MC source to create this bodged, yet functional method which is called on the FMLLoadCompleteEvent being fired: I would much rather use DeferredRegistry, however no-one appears to know how to do that. Or else I haven't been able to work it out from their hints. I believe that you would do something like this to register it? If by some miracle that is correct, I seem to be getting an endless number of compiler errors in my EvileOreFeature and EvileOreFeatureConfig classes. How does one make a new FillerBlockType? Eg for generating ores in the end dimensions? I have been trying to use the create(String enumName, String p_i50618_3_, Predicate<BlockState> p_i50618_4_) method, however I can't work out what to pass into the last parameter. So far I have this: ... which throws 2 compiler errors, saying: "The method create(String, String, Predicate<BlockState>) in the type OreFeatureConfig.FillerBlockType is not applicable for the arguments (String, Block, Predicate<BlockState>)" Which seems pretty self explanatory, as a Block is certainly not a String -- I just don't know what to put there. AND "Cannot instantiate the type Predicate<BlockState> Which I am less sure of. Oh and I don't even think it will work as all the method does is: ...sooooooo yeah. Any tips? In a nutshell: How to create new FillerBlockType for ore gen in other dimensions How to do this with DeferredRegistry I can't think of anything else to say, so I'll just make sure my GitHub repo is updated and await someone's reponse. Many thanks, GenElectrovise -
[Solved][1.14.2] Custom Ore Generation
GenElectrovise replied to NickDerMitHut's topic in Modder Support
Same -
[1.15.2] Ore generation with DeferredRegistry
GenElectrovise replied to GenElectrovise's topic in Modder Support
Sorry it took sooooooo long for me to respond -- another project had to take over for a bit. I have resolved the compiler errors I previously was asking about -- by deleting my copied classes, then readding them and simply extending the appropriate MC classes with a view to overriding their methods in the future. However I don't believe it is being registered properly. There are no errors, however my generator does not appear in the [ne.mi.re.ForgeRegistry/REGISTRYDUMP]: Registry Name: minecraft:feature , so I assume that that means it isn't being registered (all of my other items and blocks appear in their respective registry dumps). Any ideas how I can get the game to acknowledge my Feature's existance? It is now being registered after I realised I hadn't been registering its registry. Oops! Still no ore spawning though. I haven't come across any place to put in AMETHYST_ORE as a parameter yet, so I'm not making anything happen, even if it is now being registered properly. Is there some documentation on use of DeferredRegistry? Because noone seems to have posted anything about it anywhere, and of course MC doesn't use it as it's part of Forge, so there's no help coming from there. Ps I now have a github repo -
[1.15.2] Ore generation with DeferredRegistry
GenElectrovise replied to GenElectrovise's topic in Modder Support
Ok I've been trying and have been left going round in circles. Might need a bit of a pointer as to where to go from here The problem I'm having right now is a compiler error on line new EvileOreFeature(EvileOreFeatureConfig::deserialize)); In EvileRegistry, which says: The type of deserialize(Dynamic<?>) from the type EvileOreFeatureConfig is EvileOreFeatureConfig, this is incompatible with the descriptor's return type: OreFeatureConfig And all I seem to be able to do is shift the issue elsewhere, eg to the constructor of EvileOreFeature by changing EvileOreFeature's parameters to fit, which then throws a similar error I was about to go down the route of making a whole new Features class for myself, but I thought that ore generation should probably be simpler than that, so I thought I'd ask for some help instead Here are my classes: -
Three things: I have never needed to change these settings -- only the amount of RAM allocated to the game in the launcher profile. Is this related to Forge or Modding? Regardless of whether this is related to those, pretty sure Modder Support isn't the place for this... This would probably be better in either Minecraft General or General Discussion -- you'd probably get more help there besides. Sorry I can't be of more help though. -GenElectrovise
-
HI! It's what the title says. I am looking to generate standard Block s with registry names amethyst_ore_overworld , amethyst_ore_end , and amethyst_ore_nether in their respective dimensions, however I don't know the correct type of DeferredRegister to use. I think it is one of: FEATURE, DECORATORS, CHUNK_GENERATOR, or possibly WORLD_CARVER , though of those I suspect, from looking at the Feature class of MC, it should be FEATURE , although I don't know how I would implement that. Right now I mostly get a lot of compiler errors saying that Feature has an invalid type argument, but again, I don't know what I'm aiming for as I don't know how many additional classes I may need for it. In 1.7.10, I used a full devoted class ; in 1.12.2 the generator was made in one line ; in 1.15.2 I have seen people do it without DeferredRegistry , but not with it. Thanks!
-
Bingo! After looking through the generic minecraft json format (on the game wiki) I found this worked! I believe the issue was something like there was no property named "normal" (or whatever else) in my code for the block? Which would seem logical that it wouldn't work, I guess... So by just not calling it anything (as the mc wiki says you should for only one state) it works! Onwards and upwards to even more variants! Thanks!
-
Hi @Ugdhar. I have been trying to get this to work, however I keep getting this error and I can't work out why... I've tried several iterations, but these are my latest attempts.... (They've all had this same error) : magiksmostevile:blockstates/amethyst_block.json magiksmostevile:models/block/amethyst_block.json It should just be a basic block but that seems to be harder than expected! Thanks! EDIT: Also just tried porting my blockstate over from 1.12.2 and still got this error: The blockstate json: