Question about Frames with savedgames(All Solved Thank you)

13 posts

Flag Post

I’m hoping I don’t have to completely rewrite how I handle achievements. Currently my achievements work similar to this. Ill give a couple examples of how I do it.
The achmenu is the achievements page. It lists all of the achievements. All the achievements are listed but grayed out at first. When you unlock them, they turn black so that you can see them better. It does this by going to the 2nd frame.


static function gameOver()
		{
			if (timesdied == 1)
			{
				if (died1time == false)
				{
					updateach("Achievement Unlocked: Die");
					updateScore(200);
					died1time = true;
					achMenu.die.gotoAndStop(2);
				}
			}


function newGame(e:Event)
		{
			if (playthegameach == false)
			{
				updateach("Achievement Unlocked:Play the game");
				playthegameach = true;
				updateScore(200);
				achMenu.welc.gotoAndStop(2);
			}

They are essentially all handled inside of a function, and that function is only called when its possible for the requirements to be met.

There are 2 main things that relates to the achievements. 1 is the frame the achievement is on which is what the player sees, and then 2 is the Boolean of the achievement that shows that if it has been gotten or not. Is there a way to save the current frame of achMenu.die, achMenu.welc ?

 
Flag Post

this is what you’re looking for.

 
Flag Post

I know how to check the current frame, I just havent been able to figure out how to set the current frame to a value. Ive tried things such as savedData.data.achMenu.die = achMenu.die.currentFrame; (TypeError: Error #1010: A term is undefined and has no properties. this is where the error points to) (this is also the code for when I try and save it) but it always returns undefined. The currentFrame is an int so if I set achmenu.Die to it, it should set it to the int (2) right? Well, obviously im wrong since its not working, but thats my train of thought. achMenu.die.gotoAndStop(savedData.data.achMenu.die); (when I try to load it)

 
Flag Post

Almost.

achMenu.die.gotoAndStop(savedData.data.achMenu.die.currentFrame);

That is, if you can save a Movieclip as is in a sharedObject, which I highly doubt. (SharedObject is not good for saving complex objects, for reasons I won’t get into in this thread). Otherwise you’d better have defined what exactly savedData.data.achMenu is, and why it should contain a .die property or you’ll get a #1010 err-… oh. Welp, you’re better off either saving the value only:

savedData.data.achievementDie = achMenu.die.curentFrame;

---

achMenu.die.gotoAndStop(savedData.data.achievementDie);

Or serializing all the stuff you want to save into a single ByteArray and save that. Deserialize when loading.

 
Flag Post

Make a shared object that does what you want in a easy-to-understand fashion before you start messing with serialization. ;)

 
Flag Post

Yea, you’d think that serialization would be the bigger headache…

 
Flag Post
Originally posted by Ace_Blue:

Yea, you’d think that serialization would be the bigger headache…

Oh, I’m sure it’s less of a headache than doing a bunch of data saving/loading manually, but that’s like saying riding a bike is easier than walking: it is, but you have to learn to walk first.

 
Flag Post
Originally posted by Ace_Blue:

Almost.

achMenu.die.gotoAndStop(savedData.data.achMenu.die.currentFrame);

That is, if you can save a Movieclip as is in a sharedObject, which I highly doubt. (SharedObject is not good for saving complex objects, for reasons I won’t get into in this thread). Otherwise you’d better have defined what exactly savedData.data.achMenu is, and why it should contain a .die property or you’ll get a #1010 err-… oh. Welp, you’re better off either saving the value only:

savedData.data.achievementDie = achMenu.die.curentFrame;

---

achMenu.die.gotoAndStop(savedData.data.achievementDie);

Or serializing all the stuff you want to save into a single ByteArray and save that. Deserialize when loading.

I still got the same error doing that, however, I figured out a way to pull it off thats even simpler than what I was trying to do.


savedData = SharedObject.getLocal("saaaa");
				if (savedData.data.timesdied == undefined)
				{
					timesdied = 0;
				}
				else
				{
					timesdied = savedData.data.timesdied;
					died1time = savedData.data.died1time;
					if (died1time == true)
					{
						achMenu.die.gotoAndStop(2);
					}
				}

 
Flag Post
Originally posted by Ace_Blue:

Yea, you’d think that serialization would be the bigger headache…

I’ve found that to be true only during the initial learning process. Once that’s out of the way though, I honestly can’t think of an easier way to load/save game data. To use Draco’s walking/bicycling analogy, riding a bike is easier and faster, but only once you’ve learned how to ride one. So, hop on and start learning how to ride—you won’t regret it later.

 
Flag Post

Ive got an unrelated question, if no one minds scouring my code ;)

Im posting a the whole class, but I can tell you exactly when it happens, I just dont understand why. This is related to the var ShieldPower in my Ship class. http://pastebin.com/bZ72A7jd When the saveg function (which is located in my Ship class) is called in my Game class http://pastebin.com/ZJzUVZy0 then ShieldPower reverts to NaN when it is previously traced at 1.

 
Flag Post

^ I only skimmed it, but it looks like you’re never actually saving ShieldPower when you save everything else. Look in saveg(), and notice how ShieldPower is the only thing being assigned something FROM the SharedObject, whereas everything else is assigning something TO the SharedObject. It’s probably NaN because there’s nothing to assign to it.

 
Flag Post
Originally posted by Aesica:

^ I only skimmed it, but it looks like you’re never actually saving ShieldPower when you save everything else. Look in saveg(), and notice how ShieldPower is the only thing being assigned something FROM the SharedObject, whereas everything else is assigning something TO the SharedObject. It’s probably NaN because there’s nothing to assign to it.

That did it. I looked at that part 5 times over and didnt catch it. Its amazing the thing a new pair of eyes can do.

 
Flag Post
Originally posted by Aesica:
Originally posted by Ace_Blue:

Yea, you’d think that serialization would be the bigger headache…

I’ve found that to be true only during the initial learning process. Once that’s out of the way though, I honestly can’t think of an easier way to load/save game data. To use Draco’s walking/bicycling analogy, riding a bike is easier and faster, but only once you’ve learned how to ride one. So, hop on and start learning how to ride—you won’t regret it later.

That was my point. Serialization looks daunting from the outside, but once you start implementing it, it’s actually logical and straightforward. Direct access to the sharedObject as needed seems simpler at first, but unless you exercise a lot of self discipline you end up with nearly every class putting its dirty fingers directly in the sharedObject until the whole thing becomes an intractable mess. Not to mention the problems associated with saving complex types such as instances of DisplayObject subclasses.