Willow and the Storm

Bounds-checking is not required; if you're dumb enough to OOB an argument, then, yeah. You deserve the crash.

...no. No you don't. You never deserve a crash. Plus, putting in an out-of-bounds value doesn't imply "dumb"; it could be simply a typing error.

But because of the way it works out, the last few don't save properly cm.

Actually, Noxid, could I have an explanation of why this is? DragonBoots tried to explain, but he didn't really seem to understand either.

And the 'system variables' (variables 0000-0005) are recalculated and updated per-frame.

A tad inefficient, really; I don't see what's wrong with my look-up table suggestion. Still, I guess it works.

Anyway, there's no difference between these so-called 'editable variables' and anything else; it's all just RAM somewhere.

No difference at the assembly level, yes. However, there's a good reason to make them different at the TSC level. There's literally no reason to ever change these variables, because it has no effect; any change will be overwritten, and it won't actually change the value it points to. Why not make them read-only? And if you can make them read-only, why not have them point directly to the values?

 

Mkay; as for how the variables work, I just start them at 49e090 (I think) and each is two bytes long. Flags start at 49dda0 and there's 8000 bits or 1000 bytes (decimal) so whatever that takes up, I think it goes to like 49e148 or something (I don't have a hex calculator handy).

So I believe there are like 124 effectively usable variables. Also, there was an issue on my .exe because I was using variable 120 to save the variable for the Mimga mask hack; that's why I had to use the first 6 variables for system instead of the last 6. On anyone else's .exe it wouldn't be a problem though I guess.

I'm not sure what you mean by 'read-only'... Technically if you just use the VXXX method to access the OOB variables then that'd be "read-only" as VXXX doesn't actually change anything. And, when you say "You wouldn't be able to change the values they point to", I don't understand that either. They aren't pointers, VAR0798:0001 would indeed set your current health to 1 because it (sort of indirectly) points directly to the health variable. For a listing of how the memory is laid out check the compendium's list of RAM values.

 

Mkay; as for how the variables work, I just start them at 49e090 (I think) and each is two bytes long. Flags start at 49dda0 and there's 8000 bits or 1000 bytes (decimal) so whatever that takes up, I think it goes to like 49e148 or something (I don't have a hex calculator handy).

So, flags go from 49dda0 to 49e188, and variables start at 49e090. That's 248 bytes for the variables, which as you say is 124 variables.

I'm not sure what you mean by 'read-only'... Technically if you just use the VXXX method to access the OOB variables then that'd be "read-only" as VXXX doesn't actually change anything.

Well, it's true that the VXXX method is "read-only"; more precisely, VXXX is simply the way to read a variable. That says nothing about whether the variable can be written to. To make them read-only, you simply make <VAR (and any other command that changes the value of a variable, like <VAO) not accept those variables as a parameter. That is, if you're asked to write to the variable, refuse. That makes the variable read-only.

And, when you say "You wouldn't be able to change the values they point to", I don't understand that either.

I was referring to the system variables, V000 through V005. These are, in effect, read-only pointers. You can examine their value, but you can't change the value they point to. You can't, for example, heal the player with <VAR0000:V001. Wouldn't it be better for <VAR0000:1234 to be interpreted as <VAR0798:1234, and then refuse any variable above 123? Or better still, leave V000 to be a regular variable, and interpret <VAR0124:1234 as <VAR0798:1234; then do similar things for variables 125, 126, 127, 128, and 129 mapping to max HP, Y position, X position, current ammo, and XP to level-up respectively, and refuse any numbers outside the range 0..129 (just do nothing, or maybe trigger an error). All you would need to do it put a table of pointers somewhere, say at offset Q, and if the variable number V is greater than 123, you deal with the value pointed to by the pointer at offset Q+V-124 rather than dealing with the value stored at offset Z+V (where Z is the offset where the variables start).

They aren't pointers, VAR0798:0001 would indeed set your current health to 1 because it (sort of indirectly) points directly to the health variable. For a listing of how the memory is laid out check the compendium's list of RAM values.

This is not a pointer, no. But I wasn't talking about the out-of-bounds variables my post. I was talking about the "system" variables that you decided to update per-frame.

 

It works fine as-is CM.
No sense in fucking with it if it ain't broken.

Also, the latest version of the CS Toolpack (v. 1.1) contains this hack and the expanded drums hack in fully-compatible format with handy-dandy Python hack installer by carrotlord, and the expanded intruments with an installer script for ResHacker by moi.

 

No sense in fucking with it if it ain't broken.

I would tend to disagree; it's better to do it right the first time then to have to fix it later.

 

Depending on who you are, you may or may not know that I've taken over the hacking on this mod. Mostly it's because I'm a madman workaholic who can't turn down an interesting proposition. Anyway, have you ever been working on a mod and thought "Gee, I'd like the player to be able to give an input other than YES or NO."

Maybe there will be like a feature or something where you can name the player too. By maybe I mean probably because it's already done.

 

Typcal noxid.
Completely revoloutionizing cave story every day.
Typical.

But honestly, this could turn out well in so many ways.
You could remake Zork, but with CS graphics o:

 

This thread still here? Sweet.

Anyways, with regards to Noxid's post on a slightly tangental note, I've come to a conclusion on a simple but deep way to do the alchemy system, loosely inspired by MSPA's 'Homestuck' alchemy system, classical elements and magic mushrooms inherit insanity.

So here's the idea:

Pick a base material and 2 elements. Same as before, right?
Then you enter a 1-3 digit code with that innovative system Noxid came up with.
(May insert a slight randomization here, might not. Probably based on the base material level - between +/- 10 and 50 for basic, +/- 5 and 25 for intermed. and no random chance on perfect).
The code is then run through an engine yet to be written that spaghetti-logics out an item from a selection based on the code(+/- random) from a pool of items determined by the materials.

As well, the item screen will be essentially dedicated to alchemy with this design. Perhaps rather than having individual items I can have catagories of items, such as Healing, Hurting, Summoning, Utility etc., with each catagory containing 6 items. Kinda reduces yet increases clutter... Maybe some kind of customizable quick-slot for making your own macros (Bind to a key, maybe? Probably a lot of work for nothing.)

Toughts on dis?

I'm probably just over-complicating this way too much, but at the same time it might be a simplification of my original plans. Essentially items would be reduced to a pile variables that could be increased and decreased without changing the iventory 'content' as well. If I made each item its own the inv. would overclutter pretty quickly (and it maxes at 30-something IIRC). I'd probably not include any limits on the alchemy materials, beyond the aquisition of the base material (eg. have the 2 elemental items not consumed), reducing a certain amount of 'alchemy grind' I've found in games with such a system.

 

Sorry but I can't input text with my controller.

 

Sorry but I can't input text with my controller.

But I worked hard on this >_>

You must *own* a keyboard. You could just reach over and type some keys when you need to, or maybe even just use the keyboard to play the whole game!

 

What a great and powerful tool these "keyboards" are!

 

But I worked hard on this >_>

You must *own* a keyboard. You could just reach over and type some keys when you need to, or maybe even just use the keyboard to play the whole game!

Just build an onscreen keyboard like this:

That would involve more work, but it's doable.

 

That seems like a lot of work to accommodate approximately one person, especially when it won't make the game unplayable so much as inconvenience them. And let's not forget the golden rule, "Noxid only does what he feels like doing". That's not to say I don't take your opinions under advisement, of course.

I just don't see the value added from such a feature to be high enough to compensate the effort.

 

I just don't see the value added from such a feature to be high enough to compensate the effort.

Agreed. Those grid keyboard things are annoying as hell anyway.

 

Glad to hear you're still working on the mod DB

 

Sorry but I can't input text with my controller.

Shitty controller then.

What a great and powerful tool these "keyboards" are!

Not as amazing as *my* controller.

Just build an onscreen keyboard like this:

That would involve more work, but it's doable.

Ew. On-screen grid keyboards suck clipples.

That seems like a lot of work to accommodate approximately one person, especially when it won't make the game unplayable so much as inconvenience them. And let's not forget the golden rule, "Noxid only does what he feels like doing". That's not to say I don't take your opinions under advisement, of course.

I just don't see the value added from such a feature to be high enough to compensate the effort.

A lot of people do use gamepads (myself included).
I'd rather not alienate those users entirely (or even a potential future PSP port or something).

Agreed. Those grid keyboard things are annoying as hell anyway.

Scruffy seconds.

Glad to hear you're still working on the mod DB

Indeed I my crew is.

 

A lot of people do use gamepads (myself included).
I'd rather not alienate those users entirely (or even a potential future PSP port or something).

Err, how are the rest of the hacks to this supposed to transfer? Say you leave out the keyboard thing, there are still a number of other changes. I had a hard enough time getting simple hacks to work on a mac, and at least those look like computers.

 

Err, how are the rest of the hacks to this supposed to transfer? Say you leave out the keyboard thing, there are still a number of other changes. I had a hard enough time getting simple hacks to work on a mac, and at least those look like computers.

In the case of most of the hacks so-far, it would be possible to transfer them.
However, requiring a keyboard does alienate a portion of CS fans.
I dunno. :/

WTLWIG.

 

Sorry but I can't input text with my controller.

Cave Story is a computer game. Requiring a keyboard is almost expected. I don't see a problem with it, and if you're thinking of console ports, then it's the responsibility of the porter to come up with an alternative.

at least those look like computers.

They definitely are computers!

...then again, technically a Wii is a computer too. <_<

 

What about using left and right to select a character with up and down skipping forward or back 6 characters. There are more that enough ways to accommodate a controller for inputting characters. And yes I do have a keyboard in front of me, but that doesn't make continuously picking up and putting down my controller to perform alchemy any less irritating.