Okay, I think I get it. But I feel like I'm pestering you with all these questions, so I have just one more. When the program is in RAM, what happens to the area of memory it was in when you move it to $9d95? The first 2 bytes will be its size, but what happens to the rest?

The next program in memory will directly follow those two bytes, starting with its own two byte size word. You probably haven't seen problems because you're not putting other programs in higher memory above your program.

And don't worry about pestering me, but thanks for acknowledging my time.

That's what I figured. I was gonna try and fill my RAM up with scrap programs and see if they would be changed. I assume now that they would.

It's weird then that nobody has mentioned it, because the random function has always been using a seed which is being changed in the original version of the program, which evidently is NOT the programs RAM area if it is being run by Doors. Guess nobody else had any other programs in higher RAM either. Perhaps because they heeded my advice and stored everything in the archive before running it, which would have been smart.

I'll go and fix it.

Thanks for clearing this up!


EDIT: So I guess if I just don't make a nostub version anymore, I would never have to write back myself?

*bump*

Three hours isn't quite bump-worthy, but I appreciate that this is an urgent issue. Yes, you have it exactly right.

Hehe, yeah I want to finish this. AND, more importantly, not have buggy versions of my program online. Expect an update later tonight (yes tonight, for me it is 8 pm)

Excellent, I shall keep my eye out. Feel free to poke me here or on SAX to approve it. TIFreak8x and Elfprince, as administrators, also have the power to approve archives submissions.

Or you could use an appvar. If it bothers you that the user can delete the appvar, hide it.

An excellent point, DrDnar. Cerzus, what he said.

I guess... What's the advatage to doing that? I have no idea what exactly it is or does, by the way... Wouldn't the program need to be an Application for that?

No, appvars can be created by any kind of Asm program. Personally, I like appvars because it means that I can backup just the appvar and not the whole program when I need to make a backup of my progress in the game. It also means that a user's records won't be transfered to a friend's calc unless the user sends both the program and the appvar.

Huh, those are some pretty convincing reasons to use them. I'll look into them for my game.

JosJuice makes some good points about why AppVars might be nice, and I agree, but I'm not personally opposed to having writeback. The one concession I might make to JosJuice's points if I were writing your game would be to add a clear button or key to the High Scores display.

That's actually a good idea. I'll think about that as well.

Excellent. I think that would actually be a good idea regardless of how you decide to implement high-score saving.

@KermMartian: You are right. But I think I'll use a hidden AppVar, because of the transfer from calc to calc reason.

Why hidden? JosJuice makes a good point about being able to backup the AppVar to back up your scores; I think that would be a good idea.

You're probably right again. But I'm working on the popup window atm. Let me finish that first before I dive into AppVars (I don't know anything about them yet).

Excellent, I look forward to guiding you. Now that this is a DCS program, by the way, you could use the DCS GUI API.

Great to hear!
I know and I may have if it would ONLY be for Doors, but, and I think I've already mentioned this, I want to make a MirageOS and Ion compatible version as well, without any differences but a header. Would be too much of a hassle to update multiple different versions of the program once I don't work on it this much anymore and won't know all the ins and outs in all their detail anymore if you know what I mean.