Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

Correct approach to store globally accessible values


DeadPix
 Share

Recommended Posts

Hello, 

in mod I am working on I have a need to store some values that I would need to check on in multiple places in my mod. I know that this value will be unique for every player (pretty much every instance of Minecraft running the mod will have this value different).

 

In Android, there are SharedPreferences into which one can store such information. Is there dedicated class/space in forge that I should take advantage of? Is there a recommended approach for this?

 

Or will it be okay just to create a public static class, let's say SharedPreferences with HashMap and getters and setters for indexes in the HashMap?

 

Thank you in advance.

Link to comment
Share on other sites

54 minutes ago, DeadPix said:

Hello, 

in mod I am working on I have a need to store some values that I would need to check on in multiple places in my mod. I know that this value will be unique for every player (pretty much every instance of Minecraft running the mod will have this value different).

 

In Android, there are SharedPreferences into which one can store such information. Is there dedicated class/space in forge that I should take advantage of? Is there a recommended approach for this?

 

Or will it be okay just to create a public static class, let's say SharedPreferences with HashMap and getters and setters for indexes in the HashMap?

 

Thank you in advance.

Are these values gonna be accessed on the server or is this a client only feature?

VANILLA MINECRAFT CLASSES ARE THE BEST RESOURCES WHEN MODDING

I will be posting 1.15.2 modding tutorials on this channel. If you want to be notified of it do the normal YouTube stuff like subscribing, ect.

Forge and vanilla BlockState generator.

Link to comment
Share on other sites

2 minutes ago, DeadPix said:

I am not sure how to exactly determine that. But probably only client side? It will be mostly client relevant values like 'is this thing on or off' and similar. Is that client side only?

Sounds like you need to read about sides.

VANILLA MINECRAFT CLASSES ARE THE BEST RESOURCES WHEN MODDING

I will be posting 1.15.2 modding tutorials on this channel. If you want to be notified of it do the normal YouTube stuff like subscribing, ect.

Forge and vanilla BlockState generator.

Link to comment
Share on other sites

1 minute ago, DeadPix said:

So, what does it mean for my original question, please?

I would just store it in a static variable in your ClientProxy or an @SideOnly(Side.CLIENT) class.

VANILLA MINECRAFT CLASSES ARE THE BEST RESOURCES WHEN MODDING

I will be posting 1.15.2 modding tutorials on this channel. If you want to be notified of it do the normal YouTube stuff like subscribing, ect.

Forge and vanilla BlockState generator.

Link to comment
Share on other sites

Actually the more important question is whether this value needs to persist between saves. If it does not, then you are free to create public static fields that store the values, and then regenerate them each time the game starts. But if you need to save them then generally you would add them either to the player or to the world in a saveable way, such as using the WorldSaveData mechanism. You can also pretty easily just create your own file format for saving the information -- like on client side you could store it along with config info.

Check out my tutorials here: http://jabelarminecraft.blogspot.com/

Link to comment
Share on other sites

4 minutes ago, jabelar said:

You can also pretty easily just create your own file format for saving the information -- like on client side you could store it along with config info. 

@DeadPix Though I would only do this if, this value doesn't control anything important as it could be edited by the player.

VANILLA MINECRAFT CLASSES ARE THE BEST RESOURCES WHEN MODDING

I will be posting 1.15.2 modding tutorials on this channel. If you want to be notified of it do the normal YouTube stuff like subscribing, ect.

Forge and vanilla BlockState generator.

Link to comment
Share on other sites

@jabelar@Animefan8888

Alright, thank you guys for your input - in the end, I decided to create a weaker version of aforementioned SharedPreferences (for boolean value only) and it seems to work exactly as I wanted it to. I need it only client side - and the scenario when player edits those values, is not a problem. I do not need it to persist between game loads, so I also do not save it anywhere, but in the future I will need some persistent functionality for something else, so I am also grateful for your suggestion on reading around it, jabelar. Thanks.

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.

Guest
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.

 Share



  • Recently Browsing

    No registered users viewing this page.

  • Posts

    • Your report is very hard to actually understand. Your best bet is to stop trying to 'describe' the issue and provide the actual tag files and  what you are expecting to happen. Because all of our tests in tags work just fine. Also, there is no 'registering' of tag in the sense you're talking about. All tags are 'registered' when they are read from disc in one pass. So ya, provide us a test case of your tags and we'll see if it's a real issue or not.
    • Minecraft Version: 1.16.5 Forge Version: 36.2.0 Description of issue: A loaded mod containing data pack tag registries, which creates new tags and references the new tags to further register the items in existing tags fails to register anything in the existing tags. Example: Tinkers Construct v3.1.2.265 contains Json files to register: forge:ingots/cobalt as a new tag containing cobalt_ingot and add to previously registered tag forge:ingots. In the file for forge:ingots, values of "tconstruct:seared_brick", "tconstruct:scorched_brick", "#forge:ingots/copper", "#forge:ingots/cobalt", etc. are indicated. In-game, none of the items listed as values are tagged under forge:ingots, however the new tags including forge:ingots/cobalt include the items tagged in those files. Further, copying the json file for forge:ingots and placing in a later applied datapack, such as Kubejs, and reloading, properly registers the forge:ingots tags. This would appear to be an issue with timing of registering the new tags. Before copying the json file to a datapack, the existing tag (forge:ingots) appears to be handled first, which containing references to new tags that are not yet processed (forge:ingots/cobalt) fails and does not register any of the appended values. But in the second instance because the copied json file is processed after the mod jar file as a whole, the new tags exist and the appending of the new values succeeds. While I have given Tinkers construct as an example I have viewed the same issue with multiple mods, each of which uses references to new tags in an appending of an existing tag. Likewise, mods that do not exhibit this behavior use explicit item listings rather than referencing a new tag. I looked through the log files and did not identify any error or other message relating to the registration of tags in general or specifically these exemplar tags.
    • Debug.log here: https://gist.github.com/DexTGS/4f33065cbe2ad844b76ed1b1890fd069 . Game crashing once I die.
    • I'm making a mob like zombified piglin except instead of all the mobs getting mad at you I want to make it do they all go into a panic. How can I do this?
    • What. Just register your events in your mod constructor or use the class annotation.
  • Topics

  • Who's Online (See full list)

×
×
  • Create New...

Important Information

By using this site, you agree to our Privacy Policy.