Jump to content

NEI API, adding a name to a new keybinding


DrEinsteinium

Recommended Posts

Hi guys, I've got a pretty small problem while working with NEI to add a new keybind to my mod WikiLink. I've registered the key binding matching what is in chickenbones's files and this what I have:

 

API.addKeyBind("gui.wiki", Keyboard.KEY_W);

 

And since chicken_bones doesn't register the name of the keybind for some reason, it shows up like this ingame:

 

6x3n.png

 

What should I do? Do I have to create my own language file or is there a method/way I can add the name without it? I don't really want to have to make a language file, because this button would be the only thing in it.. :/

 

Thanks

Follow me on twitter! @keepablock

Read up on whats new! www.catacombs.co

width=700 height=60http://electronic-chronic.com/assets/keep-a-block/wikilink/wikilink_logo.png[/img]

Link to comment
Share on other sites

Maybe giving "wiki" as first argument would work ? Just saying, I didn't know this API existed till now.

If you are sure about this API being necessary, you can suggest the author to add a API.addKeyBindWithName(args) method.

(I personally don't think you need an external API to make this KeyBind, unless it gives special properties ?)

Link to comment
Share on other sites

Well since I am adding integration for NEI into my mod WikiLink, I need to use chicken_bones' API in order to add another keybinding to his mod.

 

Essentially, what I'm trying to accomplish is this:

 

1. While NEI and WikiLink are both installed at the same time, WikiLink will add a key binding to NEI just like the preexisting recipe finder but with different functions. I will have to figure out how to extend NEI's API without making my mod totally dependent on NEI. I still want it to be a standalone mod.

 

2. Whenever the key is pressed while the mouse is hovering an item, it will get two things from the item the mouse is hovering: The name of the item and the @modid of the mod that it came from.

 

3. Now that WikiLink has the information it needs, it can check to see if the @modid corresponds with a wiki already in it's database. If so, it will open the wiki of the mod with the item name as the search term. If the wiki is smart enough, it will even open the page of the item.

 

It all seems like a simple task but after trying to work with NEI's API last night I was having trouble getting it going. It may not help that I'm a novice programmer, but once I get past this API part I can persevere on my own with the rest of the features.

Follow me on twitter! @keepablock

Read up on whats new! www.catacombs.co

width=700 height=60http://electronic-chronic.com/assets/keep-a-block/wikilink/wikilink_logo.png[/img]

Link to comment
Share on other sites

On the "standalone" part, I can safely say you will need reflection to accomplish this. Depending on how well written the API is, it could be pretty simple, that is, if you can subscribe to an event or call back for your key binding without actually implementing an interface.

 

I must say your idea is interesting. You could even provide an API with some IWikiLinkable interface :) so that modders add their blocks/items wiki link.

Link to comment
Share on other sites

Thanks for mentioning reflection. I didn't realize this existed until now. I'm still learning all of the tricks of the trait.

 

And do you mean an interface where the blocks and items are all linked to a wiki? The NEI integration was supposed to accomplish this, but now NEI is looking like a problem. Now that you mention this though, I think that adding a system for this without using NEI is possible.

 

Is there a way to get the mod id that an ItemStack is from? Such as ItemStack.getModId() or something lol.

Follow me on twitter! @keepablock

Read up on whats new! www.catacombs.co

width=700 height=60http://electronic-chronic.com/assets/keep-a-block/wikilink/wikilink_logo.png[/img]

Link to comment
Share on other sites

no but the interface could force the Item and Block to implement a method called "getMod" or wtv and then youd have access super easy

 

btw your mod is a f***ing great idea :D

can i haz ?

how to debug 101:http://www.minecraftforge.net/wiki/Debug_101

-hydroflame, author of the forge revolution-

Link to comment
Share on other sites

Thanks for mentioning reflection. I didn't realize this existed until now. I'm still learning all of the tricks of the trait.

 

And do you mean an interface where the blocks and items are all linked to a wiki? The NEI integration was supposed to accomplish this, but now NEI is looking like a problem. Now that you mention this though, I think that adding a system for this without using NEI is possible.

 

Is there a way to get the mod id that an ItemStack is from? Such as ItemStack.getModId() or something lol.

I was thinking about something like this:

public interface IWikiLinkable{

String getWikiLink();
String[] getDisplayInfo();

}

For modders to implement items and blocks.

 

As for mods information:

Loader.instance().getIndexedModList();

Returns an immutable map of ModContainer (an interface in cpw.mods.fml.common package) key-ed by their modid.

Link to comment
Share on other sites

Thanks for mentioning reflection. I didn't realize this existed until now. I'm still learning all of the tricks of the trait.

 

And do you mean an interface where the blocks and items are all linked to a wiki? The NEI integration was supposed to accomplish this, but now NEI is looking like a problem. Now that you mention this though, I think that adding a system for this without using NEI is possible.

 

Is there a way to get the mod id that an ItemStack is from? Such as ItemStack.getModId() or something lol.

I was thinking about something like this:

public interface IWikiLinkable{

String getWikiLink();
String[] getDisplayInfo();

}

For modders to implement items and blocks.

 

As for mods information:

Loader.instance().getIndexedModList();

Returns an immutable map of ModContainer (an interface in cpw.mods.fml.common package) key-ed by their modid.

 

I still don't understand what that interface would do. I already have an interface in my mod that other modders may access to add their mods to my wiki database, if that's what you mean. My whole problem is linking the mod items to the database.

 

When WikiLink's PluginManager finds a new mod that is implementing my interface. Upon start up, it will load this information:

 

    		
keyList.add(plugin.getWikiKey());
nameList.add(plugin.getWikiName());
domainList.add(plugin.getWikiDomain());
softwareList.add(plugin.getWikiSoftware());

 

The getWikiKey method returns the acronym users currently use to access a wiki. It's like the access code. So, /wiki <key> <search term>

The getWikiName method returns the english name of the wiki. Eg: "Example Wiki"

The getWikiDomain method returns the website that the wiki is loaded on. Eg: "minecraftwiki.net"

Finally, the getWikiSoftware method returns the type of wiki it is. Eg MediaWiki, Wikia, DokuWiki, ect

 

Each mod being added goes through this loop once, and all of their data is added to the list simultaneously so the indexes all correspond with each other.

 

Eg:

Mod 1 loads, and takes up getWikiKey[0], getWikiName[0], getWikiDomain[0], getWikiSoftware[0].

Mod 2 loads, and takes up  getWikiKey[1], getWikiName[1], getWikiDomain[1], getWikiSoftware[1].

 

And so on.

 

So now that my mod has the extra wikis in it's database, it can better suit the needs of the user when they are looking for something. When the user enters the command /wiki <key> <search term> WikiLink will match the index of the key with the indexes of the other lists and build the hyperlink accordingly. Once done it will send the hyperlink to the browser handler and open up the wiki page in your computers default browser. (Untested for Linux / Unix, but it should work)

 

-- That's the run down of how my mod works currently, but this is how I want it to work:

 

It will go through the same steps and all of the current features will be enabled, but I want an extra and easier way of getting a mod's wiki open. If possible, I plan to get the @modId of the item someone wants to look up. Now how the player declares the item they want to look up, I haven't decided yet. This is why I wanted to extend NEI's already built system, but it appears to be more trouble than I thought and I'm too much of a newbie of a programmer to figure it out. I was planning on just looking at the way the recipe system works and changing the methods, but chicken_bones' code is much too complex for my skill level.

 

But, after the @modId is obtained, it can be matched with one of the mod wikis in my database. If no match is found then it will take you to the default wiki.

 

So I guess the question is: Is there a method that I can use to get the mod an item came from?

Follow me on twitter! @keepablock

Read up on whats new! www.catacombs.co

width=700 height=60http://electronic-chronic.com/assets/keep-a-block/wikilink/wikilink_logo.png[/img]

Link to comment
Share on other sites

Well my suggested interface would be Item/Block specific, so that huge mods with dozens of items and a huge wiki would actually return a direct link for each one.

This is an addition rather than a change of your current API ;)

With an item name and a modid, you may do something like:

ItemStack searchedItem = GameData.findItemStack(modid, name);
if(searchedItem!=null && searchedItem.getItem() instanceof IWikiLinkable)
//get specific item wiki link
else
   //get global mod wiki link

 

Link to comment
Share on other sites

Well my suggested interface would be Item/Block specific, so that huge mods with dozens of items and a huge wiki would actually return a direct link for each one.

This is an addition rather than a change of your current API ;)

With an item name and a modid, you may do something like:

ItemStack searchedItem = GameData.findItemStack(modid, name);
if(searchedItem!=null && searchedItem.getItem() instanceof IWikiLinkable)
//get specific item wiki link
else
   //get global mod wiki link

 

If a modder has to add each and every individual item to the API, wouldn't that get a bit tedious? Especially for large mods such as Buildcraft, Thaumcraft 3 or IC2

Follow me on twitter! @keepablock

Read up on whats new! www.catacombs.co

width=700 height=60http://electronic-chronic.com/assets/keep-a-block/wikilink/wikilink_logo.png[/img]

Link to comment
Share on other sites

yes but i dont think you can make a generic method for everything

 

to give you an idea, i have a LOT of object, and i would deff do it

 

This.

The mod I'm working on now has a lot of weird stuff inside it, But for such an nice idea I might coonsider the trouble of manualy adding it all to be worth it ;)

 

Just adding my line to the ones above :P

If you guys dont get it.. then well ya.. try harder...

Link to comment
Share on other sites

I mean, your method would work and I know exactly how I program it, but that still doesn't solve the problem of getting the item the player wants to search for. There has to be a different system rather than a slash command that gets the item name.

 

 

Follow me on twitter! @keepablock

Read up on whats new! www.catacombs.co

width=700 height=60http://electronic-chronic.com/assets/keep-a-block/wikilink/wikilink_logo.png[/img]

Link to comment
Share on other sites

Here is what I was thinking:

 

1. Add a keybinding.

 

2. When the keybinding is pressed, it will get the name of the item in your hand.

 

3. The name of the item would get matched with a name inside of a modder's plugin and open their wiki.

 

4. If the name of the item does not have a wiki, it will just search the name on the default wiki.

 

While playing survival, the user probably won't want information on an item if it's not even in their possession, so adding a simple keybinding would work. I could also add an extra system to where if there is no item in their hand, it gets the block they are looking at.

Follow me on twitter! @keepablock

Read up on whats new! www.catacombs.co

width=700 height=60http://electronic-chronic.com/assets/keep-a-block/wikilink/wikilink_logo.png[/img]

Link to comment
Share on other sites

While playing survival, the user probably won't want information on an item if it's not even in their possession, so adding a simple keybinding would work.

actually when using IC2 or EE theres was a LOT of item i wanted to know why what they were doing, before i had them

how to debug 101:http://www.minecraftforge.net/wiki/Debug_101

-hydroflame, author of the forge revolution-

Link to comment
Share on other sites

Well I think at that point you can just pull up the industrialcraft wiki and get that information yourself. Atleast until I make an NEI compatibility addon for WikiLink.

 

Edit: You'll still also be able to do /wiki ic2 <name of item>

Follow me on twitter! @keepablock

Read up on whats new! www.catacombs.co

width=700 height=60http://electronic-chronic.com/assets/keep-a-block/wikilink/wikilink_logo.png[/img]

Link to comment
Share on other sites

Ill agree with Hydroflame on this.

 

 

But to expand on his idea, have a config file that can switch between the two methods. It means more work, but then it adds diversity, and with diversity comes heaps of users (if it is the right diversity).

 

So you would have say a boolean in the config that is true if the player wants the menu with ALL items, and false if they want the keybinding.

 

I would definitely use the menu, but hey, you have to have diversity :D

I am Mew. The Legendary Psychic. I behave oddly and am always playing practical jokes.

 

I have also found that I really love making extremely long and extremely but sometimes not so descriptive variables. Sort of like what I just did there xD

Link to comment
Share on other sites

I feel like my way would be so much easier lol xD

kindof like the difference between bukkit and forge, its so much easier in bukkit because you have to take care of 1 side, commands only

 

but forge is way better because we can create menu, make things intutive etc

how to debug 101:http://www.minecraftforge.net/wiki/Debug_101

-hydroflame, author of the forge revolution-

Link to comment
Share on other sites

I feel like my way would be so much easier lol xD

kindof like the difference between bukkit and forge, its so much easier in bukkit because you have to take care of 1 side, commands only

 

but forge is way better because we can create menu, make things intutive etc

 

Haha, agreed whole heartedly mate!

 

Well then I need to find a guide for GUIs, because I feel like my way would be so much easier lol xD

 

Well hydroflame here seems to be a semi master of GUI's, he helped me with a draggable GUI :D

I am Mew. The Legendary Psychic. I behave oddly and am always playing practical jokes.

 

I have also found that I really love making extremely long and extremely but sometimes not so descriptive variables. Sort of like what I just did there xD

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.



  • Recently Browsing

    • No registered users viewing this page.
  • Posts

    • The future of Bitcoin recovery is a topic of great interest and excitement, particularly with the emergence of innovative companies like Dexdert Net Pro Recovery leading the charge. As the cryptocurrency market continues to evolve and face new challenges, the need for effective solutions to help users recover lost or stolen Bitcoin has become increasingly critical. Dexdert Net Pro, a specialized firm dedicated to this very purpose, has positioned itself at the forefront of this emerging field. Through their proprietary techniques and deep expertise in blockchain technology, Dexdert Net Pro has developed a comprehensive approach to tracking down and retrieving misplaced or compromised Bitcoin, providing a lifeline to individuals and businesses who have fallen victim to the inherent risks of the digital currency landscape. Their team of seasoned investigators and cryptography experts employ a meticulous, multi-pronged strategy, leveraging advanced data analysis, forensic techniques, and collaborative partnerships with law enforcement to painstakingly trace the movement of lost or stolen coins, often recovering funds that would otherwise be considered irrecoverable. This pioneering work not only restores financial assets but also helps to bolster confidence and trust in the long-term viability of Bitcoin, cementing Dexdert Net Pro role as a crucial player in shaping the future of cryptocurrency recovery and security. As the digital finance ecosystem continues to evolve, the importance of innovative solutions like those offered by Dexdert Net Pro will only grow, ensuring that users can navigate the complexities of Bitcoin with greater peace of mind and protection. Call Dexdert Net Pro now     
    • I'm developing a dimension, but it's kinda resource intensive so some times during player teleporting it lags behind making the player phase down into the void, so im trying to implement some kind of pregeneration to force the game loading a small set of chunks in the are the player will teleport to. Some of the things i've tried like using ServerLevel and ServerChunkCache methods like getChunk() dont actually trigger chunk generation if the chunk isn't already on persistent storage (already generated) or placing tickets, but that doesn't work either. Ideally i should be able to check when the task has ended too. I've peeked around some pregen engines, but they're too complex for my current understanding of the system of which I have just a basic understanding (how ServerLevel ,ServerChunkCache  and ChunkMap work) of. Any tips or other classes I should be looking into to understand how to do this correctly?
    • https://mclo.gs/4UC49Ao
    • Way back in the Forge 1.17 days, work started for adding JPMS (Java Platform Module Support) to ModLauncher and ForgeModLoader. This has been used internally by Forge and some libraries for a while now, but mods (those with mods.toml specifically) have not been able to take advantage of it. As of Forge 1.21.1 and 1.21.3, this is now possible!   What is JPMS and what does it mean for modders? JPMS is the Java Platform Module System, introduced in Java 9. It allows you to define modules, which are collections of packages and resources that can be exported or hidden from other modules. This allows for much more fine-tuned control over visibility, cleaner syntax for service declarations and support for sealed types across packages. For example, you might have a mod with a module called `com.example.mod` that exports `com.example.mod.api` and `com.example.mod.impl` to other mods, but hides `com.example.mod.internal` from them. This would allow you to have a clean API for other mods to use, while keeping your internal implementation details hidden from IDE hints, helping prevent accidental usage of internals that might break without prior notice. This is particularly useful if you'd like to use public records with module-private constructors or partially module-private record components, as you can create a sealed interface that only your record implements, having the interface be exported and the record hidden. It's also nice for declaring and using services, as you'll get compile-time errors from the Java compiler for typos and the like, rather than deferring to runtime errors. In more advanced cases, you can also have public methods that are only accessible to specific other modules -- handy if you want internal interactions between multiple of your own mods.   How do I bypass it? We understand there may be drama in implementing a system that prevents mods from accessing each other's internals when necessary (like when a mod is abandoned or you need to fix a compat issue) -- after all, we are already modding a game that doesn't have explicit support for Java mods yet. We have already thought of this and are offering APIs from day one to selectively bypass module restrictions. Let me be clear: Forge mods are not required to use JPMS. If you don't want to use it, you don't have to. The default behaviour is to have fully open, fully exported automatic modules. In Java, you can use the `Add-Opens` and `Add-Exports` manifest attributes to selectively bypass module restrictions of other mods at launch time, and we've added explicit support for these when loading your Forge mods. At compile-time, you can use existing solutions such as the extra-java-module-info Gradle plugin to deal with non-modular dependencies and add extra opens and exports to other modules. Here's an example on how to make the internal package `com.example.examplemod.internal` open to your mod in your build.gradle: tasks.named('jar', Jar) { manifest { attributes([ 'Add-Opens' : 'com.example.examplemod/com.example.examplemod.internal' 'Specification-Title' : mod_id, 'Specification-Vendor' : mod_authors // (...) ]) } } With the above in your mod's jar manifest, you can now reflectively access the classes inside that internal package. Multiple entries are separated with a space, as per Java's official spec. You can also use Add-Exports to directly call without reflection, however you'd need to use the Gradle plugin mentioned earlier to be able to compile. The syntax for Add-Exports is the same as Add-Opens, and instructions for the compile-time step with the Gradle plugin are detailed later in this post. Remember to prefer the opens and exports keywords inside module-info.java for sources you control. The Add-Opens/Add-Exports attributes are only intended for forcing open other mods.   What else is new with module support? Previously, the runtime module name was always forced to the first mod ID in your `mods.toml` file and all packages were forced fully open and exported. Module names are now distinguished from mod IDs, meaning the module name in your module-info.java can be different from the mod ID in your `mods.toml`. This allows you to have a more descriptive module name that doesn't have to be the same as your mod ID, however we strongly recommend including your mod ID as part of your module name to aid troubleshooting. The `Automatic-Module-Name` manifest attribute is now also honoured, allowing you to specify a module name for your mod without needing to create a `module-info.java` file. This is particularly useful for mods that don't care about JPMS features but want to have a more descriptive module name and easier integration with other mods that do use JPMS.   How do I use it? The first step is to create a `module-info.java` file in your mod's source directory. This file should be in the same package as your main mod class, and should look something like this: open module com.example.examplemod { requires net.minecraftforge.eventbus; requires net.minecraftforge.fmlcore; requires net.minecraftforge.forge; requires net.minecraftforge.javafmlmod; requires net.minecraftforge.mergetool.api; requires org.slf4j; requires logging; } For now, we're leaving the whole module open to reflection, which is a good starting point. When we know we want to close something off, we can remove the open modifier from the module and open or export individual packages instead. Remember that you need to be open to Forge (module name net.minecraftforge.forge), otherwise it can't call your mod's constructor. Next is fixing modules in Gradle. While Forge and Java support modules properly, Gradle does not put automatic modules on the module path by default, meaning that the logging module (from com.mojang:logging) is not found. To fix this, add the Gradle plugin and add a compile-time module definition for that Mojang library: plugins { // (...) id 'org.gradlex.extra-java-module-info' version "1.9" } // (...) extraJavaModuleInfo { failOnMissingModuleInfo = false automaticModule("com.mojang:logging", "logging") } The automatic module override specified in your build.gradle should match the runtime one to avoid errors. You can do the same for any library or mod dependency that is missing either a module-info or explicit Automatic-Module-Name, however be aware that you may need to update your mod once said library adds one. That's all you need to get started with module support in your mods. You can learn more about modules and how to use them at dev.java.
    • Faire la mise à jour grâce à ce lien m'a aider personnellement, merci à @Paint_Ninja. https://www.amd.com/en/support 
  • Topics

×
×
  • Create New...

Important Information

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