Saving data to player.dat file

[oldcheese]

Hi.

 

I'm experimenting with making mods, and one of the things I'd really love to do is add a weapon that basically 'saves' to a player. So you pick up a blank weapon, and if player variable X = 2 then it's a sword with 5 damage that sets people on fire. if X = 1 then It's a sword that blinds.

 

So far so good. I made a simple orb that is right clicked to create the weapon depending on X, then changes back if dropped or logged out.  I'm using a simple item that sets a variable to 2 when clicked to test all this, what I CAN'T figure out is how to save a variable to the player!

 

My general guess would be to make a eventhandler for login/logout that would load/save an NBT. but I have no idea how to save a NBT tag to the player.dat file, is there a specific way to save it? sorry if I say dumb stuff my english isn't very good and I can't say what I'm doing very well. but I hope you guys can help on how to save Variable to the player.

[Ewe Loon]

all entities have a NBTTagCompound that gets saves

 

use

getEntityData() method to retreive the tag to save your data in

 

 

 

[Ernio]

There would be 2 approaches here:

 

Save property to weapon when it's crafted, which is not what you want.

 

Save property to player and check it when you use certain custom item.

 

IEntityExtendedProperties - saving stuff to player in runtime memory AND saving it to disk whenever MC normally saves/loads player.

You won't need packets since everything happens on server side.

 

here tutorial how to do it:

http://www.minecraftforum.net/forums/mapping-and-modding/mapping-and-modding-tutorials/1571567-forge-1-6-4-1-8-eventhandler-and

(2nd post)

 

Edit:

Ewe Loon idea is NOT good here, saving and loading uses IO operations (interacting with hard-drive) you DON'T want that. Use IEEP to keep data loaded all the time and save/loaded only when MC does.

[Ewe Loon]

NBTTagCompound is nothing more than a HashMap with lots of methods for access

tell me how it uses IO operations

 

 

[oldcheese]

Darn. Thanks everyone for the quick replies.  I'll use IEEP for now. Thanks all!

[Ernio]

Ewe Loon

1. When calling getEntityData() you are getting NBTTagCompound with key of "ForgeData".

Using it is not THAT risky, but if used with too generic key names might cause 2 mods put same key and corrupt data.

 

2. Accessig getEntityData() and getting data in it uses very INEFFICIENT process (byte-reading, comparable to String reading) and shouldn't be ever used beside one-time accessing.

In this thread author pointed out he wants to use data that presists (not pointed out but probably had in mind). It's MUCH better to store IEEP with single value that ise loaded once per construcing and saved once a while (on entity save) than reading it every time server-side wants to use it - e.g damaging enemy.

In more complicated cases, like IEEP being synchronized to client and used in renderer (GUI for e.g) those calls would be made on FPS-timing, on my comp it could get to about 500 calls if not more. Kinda stupid to read NBT 500 times per second, don't you think?

 

And one last thing - I stated: "saving and loading uses IO operations (interacting with hard-drive)", how is this not correct?

Saving NBT uses IO, reading it is just very inefficient.

 

#noHate

[Ewe Loon]

using extended entity properties adds the properties to all entities in the game , this is also inefficient as they all get loaded and saved even if not used

as for 2 mods using the same tag ids , the same can happen with extended entity properties too

 

the differences between the 2 differences is one was added by FORGE and the other was added by MOJANG after forge added their one

 

if you are really worried about efficiency dont use minecraft at all, if you read the code you will see that most of it is inefficiently written anyway

 

>> In more complicated cases, like IEEP being synchronized to client and used renderer (GUI for e.g) those calls would be made on FPS-timing, on my comp it could get to about 500 calls if not more. Kinda stupid to read NBT 500 times per second, don't you think?

 

NBT is a HashMap    Extended Entity Properties are also HashMaps  wow what a difference

 

BOTH methods have pros and cons , dont rubbish one just because you thought of something else

 

[Ewe Loon]

  On 1/20/2015 at 5:54 PM, diesieben07 said:

  Quote

using extended entity properties adds the properties to all entities in the game , this is also inefficient as they all get loaded and saved even if not used

Bullshit. You are the one registering the IEEP instance, you decide exactly which entities you add it to.

sorry, you are correct on this, I thought it was a static hashmap, but it isnt.

 

  Quote

  Quote

the differences between the 2 differences is one was added by FORGE and the other was added by MOJANG after forge added their one

Bullshit. Both getEntityData and IEEP are Forge patches. getEntityData saves in a tag called "ForgeData". Definitely added by Mojang.

Both forge, wow, I wouldnt have expected that.

 

  Quote

  Quote

if you are really worried about efficiency dont use minecraft at all, if you read the code you will see that most of it is inefficiently written anyway

Bullshit.

I still think there is a lot of inefficient code in it, but what hasn't got that problem these days, my computer is many years old, and still runs it ok, so the inefficiency isn't an issue anyway

 

  Quote

  Quote

NBT is a HashMap    Extended Entity Properties are also HashMaps  wow what a difference

NBT is a HashMap that stores each property on it's own as a structure of wrappers (NBTTagInt for integer, etc.). With IEEP you have one HashMap that stores reference to one wrapper object (implementing IEEP) that stores all your data. With that method primitives do not get boxed, etc.

I was referring to efficiency , one you write methods in your class to read and write the values the other its in a separate class, just a different approach

 

  Quote

  Quote

BOTH methods have pros and cons , dont rubbish one just because you thought of something else

The only "good" thing about getEntityData is that it is a little bit easier to use if you just store one thing.

That's all.

getEntityData has some builtin error checking, getExtendedProperties() will return null if it wasn't registered to that entity so error checking is necessary.

 

I think its time for this to be closed

 

diesieben07, You're one of the best coders in here, you personally have answered some of the hardest questions i have asked, and pointed me to good resources, keep up the good work