 |
Castle Paradox
|
| View previous topic :: View next topic |
| Author |
Message |
msw188
Joined: 02 Jul 2003
Posts: 1041
|
 Posted: Fri Dec 07, 2007 2:05 pm Post subject: Various menu-related questions |
 |
|
Okay I'm having a bit of trouble understanding a few issues concerning menues. First of all, when determining what slot a menuitem handle is referring to, what counts as a slot? Do captions count as slots? What if they are type 'not selectable'? I think that any slot who's text is visible to the player (whether selectable or not) SHOULD count as a slot (at least, that is what it sounds like on the plotdict.xml). Right now I am pretty certain that unselectable captions are not counted.
Furthermore, what is an unselectable caption for, anyway? Why does it make the selection's text gray, and why can the cursor still highlight it? in short, what is the difference between being selectable and unselectable for a caption? I thought that unselectable captions would be a great way to show a name for a menu (that the player would not be able to highlight with his cursor), but as it stands now there is no way to do this.
Is the Main Menu supposed to take precedence over all other menues? As in, if I have an option on the Main Menu call a script that calls a new menu, should the Main Menu still be on top? I don't think so. I would expect the most recently called menu to appear on top, regardless of what menu is what. Right now the Main Menu always ends up on top. This is a problem because I would like a chain of menues that the player can cancel out of one at a time, starting with the Main Menu all the way at the 'back'. If the Main Menu is given precedence (as it seems to be now) this is impossible.
The 'allow gameplay' bitset also seems problematic, but maybe I'm just misunderstanding it. What I WANT is for a menu to be called, then altered by a plotscript, then the player to be able to select things on that menu without affecting the world outside the menu. What is the proper way to do this?
_________________
My first completed OHR game, Tales of the New World:
http://castleparadox.com/gamelist-display.php?game=161
This website link is for my funk/rock band, Euphonic Brew:
www.euphonicbrew.com |
|
| Back to top |
|
 |
Bob the Hamster
OHRRPGCE Developer
Joined: 22 Feb 2003
Posts: 2526
Location: Hamster Republic (Southern California Enclave)
|
| Posted: Fri Dec 07, 2007 2:27 pm Post subject: Re: Various menu-related questions |
|
|
| msw188 wrote: | | Okay I'm having a bit of trouble understanding a few issues concerning menues. First of all, when determining what slot a menuitem handle is referring to, what counts as a slot? Do captions count as slots? What if they are type 'not selectable'? I think that any slot who's text is visible to the player (whether selectable or not) SHOULD count as a slot (at least, that is what it sounds like on the plotdict.xml). Right now I am pretty certain that unselectable captions are not counted. |
All visible menu items have slots, regardless of whether or not they are selectable. Hidden menu items also have slots, but they always come after the last visible slot.
The item at the top of the menu is in slot 0. the item below it is in slot 1, the item below that is slot 2, and so-on.
Slots are probably not useful for much. If you can think of a reason why you want to care what the slot number of a menu item is, I can probably tell you a different way to accomplish the same thing.
| msw188 wrote: | | Furthermore, what is an unselectable caption for, anyway? Why does it make the selection's text gray, and why can the cursor still highlight it? in short, what is the difference between being selectable and unselectable for a caption? I thought that unselectable captions would be a great way to show a name for a menu (that the player would not be able to highlight with his cursor), but as it stands now there is no way to do this. |
Understood. I'll look into the code and see how hard it is to make the cursor skip "Unselectable" captions. (Although I think it should not skip other types of greyed-out disabled menu items)
| msw188 wrote: | | Is the Main Menu supposed to take precedence over all other menues? As in, if I have an option on the Main Menu call a script that calls a new menu, should the Main Menu still be on top? I don't think so. I would expect the most recently called menu to appear on top, regardless of what menu is what. |
Right. That is how it should be now.
| msw188 wrote: | | ...Right now the Main Menu always ends up on top. |
That sounds like a bug... But try again with tonight's nightly, as I have made some fixes to main menu activation today.
| msw188 wrote: | | This is a problem because I would like a chain of menues that the player can cancel out of one at a time, starting with the Main Menu all the way at the 'back'. If the Main Menu is given precedence (as it seems to be now) this is impossible. |
Wait, I am confused. You want to open up a stack of sub-menus, but then close them one-by-one from the back rather than from the front?
| msw188 wrote: | | The 'allow gameplay' bitset also seems problematic, but maybe I'm just misunderstanding it. What I WANT is for a menu to be called, then altered by a plotscript, then the player to be able to select things on that menu without affecting the world outside the menu. What is the proper way to do this? |
So you want to modify the menu with scripting, but then you want the menu to act like the "allow gameplay" bit is off, right?
What happens if you do something like:
| Code: |
variable(menu, mi)
menu := open menu (5)
mi := add menu item(menu)
$0="Hello World"
set menu item caption(mi, 0)
set menu bit(menu, menubit:allow gameplay, OFF)
wait(1)
|
|
|
| Back to top |
|
|
msw188
Joined: 02 Jul 2003
Posts: 1041
|
| Posted: Fri Dec 07, 2007 3:07 pm Post subject: |
|
|
First off, ignore the stuff about the Main Menu coming on top, I made a stupid mistake (put in the condition for returning false in a script, but forgot to make it return true otherwise, so it was ALWAYS returning false). Sorry about that.
Secondly, if unselectable captions at the top of a menu should count as slot zero, and the choice after them should count as slot 1, I think there is a bug with this either in the command 'menu item slot (handle)', or in the passing of menu item handles to scripts. I'm pretty sure this is not a mistake on my part, but just in case, here is the script:
| Code: | plotscript, Item use, MChandle=0, begin
variable(i,localHero)
gMSlot:=menuitemslot(MChandle)
localHero:=gHero
if(localHero>>4),then
(localHero:=4) #all triplets count as hero 4 for the item menu
gItem:=readglobal( 81+(localHero*8)+(gMSlot--1) )
if(gItem==0),then
(showvalue( 81+(localHero*8)+(gMSlot--1) ), exitscript) #ERROR, SHOULD NEVER HAPPEN
openmenu(menu:What to do with item)
getitemname(1,gItem)
set menuitem caption(firstmenuitem(topmenu),1)
end
|
The globals in question start at 81, and the first slot in the menu that calls this script is the unselectable caption. However, any time I try to choose an item with hero zero, it fails and show values 80, meaning that somehow gMSlot is getting 0 instead of 1...?
In regards to using slots, I am going to be simultaneously furious and elated if you can explain an easier way to do the following.
I am creating a custom item system where every hero has their own item menu, and each hero can carry up to eight items. There are a total of five obtainable heroes, so I have 5*8=40 globals set aside for this, in a set order. I have the Item choice on the Main Menu call a script that first calls a hero picker (who's items do we want to look at?) and then, as long as the player didn't cancel, it calls an item choosing menu, 'populates' it (I'll explain in a moment), and then terminates.
This new itemchoosing menu is only one menu in custom, with nine slots defined. The first slot is a blank unselectable caption, and the other eight are all assigned to call one script (I'll explain this in the next paragraph), but their captions are blank. The 'populating' mentioned above is where the script goes to the relevant globals and extracts data from them to assign captions to all of the choices, and delete them as necessary if the hero has less than eight items.
The script that all items calls receives a menuitem handle (as far as I know, the only form of argument we have for calling scripts from a menu). But in order to tell what item was chosen, the handle is not enough. I need to know what slot was chosen, as this will tell me what global needs to be referred to. So this is where I need to use the slot numbers of the menuitems.
Whoo, that was a lot. I'll try to be quick with the other things.
| Quote: | | Wait, I am confused. You want to open up a stack of sub-menus, but then close them one-by-one from the back rather than from the front? |
No, I said that backwards. Sorry for the confusion, but it turns out that the whole problem there was my script anyway.
| Quote: | So you want to modify the menu with scripting, but then you want the menu to act like the "allow gameplay" bit is off, right?
What happens if you do something like: GOOD IDEA GOOD IDEA |
Yes, that will probably take care of it. Can't believe I didn't think of it. It is kind of a pain to do though; I don't know what other people will be using menues for, but as of now I think I will have to do this on almost every menu. It would be nice if proper bitset wizardry could be arranged to make this simple to do in custom. But it's not a big deal.
Thanks again for everything.
_________________
My first completed OHR game, Tales of the New World:
http://castleparadox.com/gamelist-display.php?game=161
This website link is for my funk/rock band, Euphonic Brew:
www.euphonicbrew.com |
|
| Back to top |
|
|
Bob the Hamster
OHRRPGCE Developer
Joined: 22 Feb 2003
Posts: 2526
Location: Hamster Republic (Southern California Enclave)
|
| Posted: Fri Dec 07, 2007 4:02 pm Post subject: |
|
|
| msw188 wrote: |
The globals in question start at 81, and the first slot in the menu that calls this script is the unselectable caption. However, any time I try to choose an item with hero zero, it fails and show values 80, meaning that somehow gMSlot is getting 0 instead of 1...? |
If "menu item slot" fails (for example, if you give it an invalid handle, or a handle to a menu that already closed) it will return -1. Could that be what is happening here?
| msw188 wrote: |
In regards to using slots, I am going to be simultaneously furious and elated if you can explain an easier way to do the following.
I am creating a custom item system where every hero has their own item menu, and each hero can carry up to eight items. There are a total of five obtainable heroes, so I have 5*8=40 globals set aside for this, in a set order. I have the Item choice on the Main Menu call a script that first calls a hero picker (who's items do we want to look at?) and then, as long as the player didn't cancel, it calls an item choosing menu, 'populates' it (I'll explain in a moment), and then terminates.
This new itemchoosing menu is only one menu in custom, with nine slots defined. The first slot is a blank unselectable caption, and the other eight are all assigned to call one script (I'll explain this in the next paragraph), but their captions are blank. The 'populating' mentioned above is where the script goes to the relevant globals and extracts data from them to assign captions to all of the choices, and delete them as necessary if the hero has less than eight items.
The script that all items calls receives a menuitem handle (as far as I know, the only form of argument we have for calling scripts from a menu). But in order to tell what item was chosen, the handle is not enough. I need to know what slot was chosen, as this will tell me what global needs to be referred to. So this is where I need to use the slot numbers of the menuitems.
Whoo, that was a lot... |
I said "probably" and not "definitely" because I remembered what you were working on :)
The system you have describe does actually sound like the best way to do what you want. So if it is not working, then you may have exposed a bug in one of the commands. You are basically the first person to test a lot of these commands.
This makes me thing that I should add a couple "extra" data members to menu items, just so that you have a place to store the item numbers when you populate your menu.
or if you really want to do this the easier way, you just learn FreeBasic, and help me write the feature into the engine ;)
| msw188 wrote: | | What happens if you do something like: GOOD IDEA GOOD IDEA |
Yes, that will probably take care of it. Can't believe I didn't think of it. It is kind of a pain to do though; I don't know what other people will be using menues for, but as of now I think I will have to do this on almost every menu. It would be nice if proper bitset wizardry could be arranged to make this simple to do in custom. But it's not a big deal.[/quote]
Actually, if you open a menu with the "open menu" command, and that menu does not allow gameplay, I don't think it will instantly cause the script to stop running (*goes to check*) yeah. A menu with "allow gameplay" off will pause all running scripts, but the menu doesn't actually appear until the next wait command, so it is safe to do this:
| Code: |
variable(menu, mi)
menu := open menu (5) #this menu already has "allow gameplay" OFF
mi := add menu item(menu)
$0="Hello World"
set menu item caption(mi, 0)
wait(1)
|
And it will work how you expect. |
|
| Back to top |
|
|
msw188
Joined: 02 Jul 2003
Posts: 1041
|
| Posted: Fri Dec 07, 2007 8:15 pm Post subject: |
|
|
Actually, I realized that the GOOD IDEA GOOD IDEA won't work for me. You see, I need menuitems to call scripts, and which call and populate new menues, all while leaving the original menu on in the background. So I need gameplay allowed. So I guess I will need that bitset 'suspend player even if gameplay is allowed', or whatever it is. That means that the player will still be able to manipulate the menu, just not anything out of it, right?
Also, I'm slowly becoming convinced that the menuslot thing is a bug. The menu is still open (one of the reasons I need gameplay allowed), and the code looks okay. Or maybe I'm misunderstanding the arguments. When a menuitem calls a script, it sends one argument - a menuitem handle. This is the first and only argument sent (thus it should correspond to my MChandle in my code above). Is this true?
EDIT: Upon a bit of further debugging, it appears that the menu IS sending an argument. In fact, it send 12 for the second slot, and 13 for the third slot, or the given menu. But somehow, regardless of this, the line gMSlot:=menuitemslot(12 OR 13) gives gMSlot==0 in both cases. Does it sound like a bug, or is there still a chance I'm screwing something up completely? Variables don't hurt each other if they aren't defined in order, do they? (by which I mean, I've defined globals up to about 13 or so, then skipped ahead to 78 or something like that)
_________________
My first completed OHR game, Tales of the New World:
http://castleparadox.com/gamelist-display.php?game=161
This website link is for my funk/rock band, Euphonic Brew:
www.euphonicbrew.com |
|
| Back to top |
|
|
Bob the Hamster
OHRRPGCE Developer
Joined: 22 Feb 2003
Posts: 2526
Location: Hamster Republic (Southern California Enclave)
|
| Posted: Fri Dec 07, 2007 10:22 pm Post subject: |
|
|
| msw188 wrote: | | Actually, I realized that the GOOD IDEA GOOD IDEA won't work for me. You see, I need menuitems to call scripts, and which call and populate new menues, all while leaving the original menu on in the background. So I need gameplay allowed. So I guess I will need that bitset 'suspend player even if gameplay is allowed', or whatever it is. That means that the player will still be able to manipulate the menu, just not anything out of it, right? |
I think the "suspend player even if gameplay is allowed" bitset will do exactly what you want. Try it, and let me know.
| msw188 wrote: | Also, I'm slowly becoming convinced that the menuslot thing is a bug. The menu is still open (one of the reasons I need gameplay allowed), and the code looks okay. Or maybe I'm misunderstanding the arguments. When a menuitem calls a script, it sends one argument - a menuitem handle. This is the first and only argument sent (thus it should correspond to my MChandle in my code above). Is this true?
EDIT: Upon a bit of further debugging, it appears that the menu IS sending an argument. In fact, it send 12 for the second slot, and 13 for the third slot, or the given menu. But somehow, regardless of this, the line gMSlot:=menuitemslot(12 OR 13) gives gMSlot==0 in both cases. Does it sound like a bug, or is there still a chance I'm screwing something up completely? Variables don't hurt each other if they aren't defined in order, do they? (by which I mean, I've defined globals up to about 13 or so, then skipped ahead to 78 or something like that) |
Sounds darn buggy to me. I'll look into it...
EDIT: Oh, hey, look in your g_debug.txt file and see if there are any lines that start with "menu item slot:"
EDIT: Aha! Yes, you definitely found a bug! I wrote the "menu item slot" command wrong. It was interpreting the menu item handle as if it was a menu handle, and that always produced the wrong results. I fixed it (and just in time for tonight's nightly too) |
|
| Back to top |
|
|
msw188
Joined: 02 Jul 2003
Posts: 1041
|
| Posted: Sat Dec 08, 2007 2:06 am Post subject: |
|
|
Thanks so much. I will test that stuff sometime Saturday evening most likely. I also saw some commands being implemented for 'extra' menu data. Is there any way that this data can be assigned in custom (so that it is permanent for the menu)? That would make my system for shops SO much easier.
I also meant to ask, can 'read NPC()' get data like whether the NPC was only one-time usable, and what it's one-time usable tag is? I don't think it is documented.
_________________
My first completed OHR game, Tales of the New World:
http://castleparadox.com/gamelist-display.php?game=161
This website link is for my funk/rock band, Euphonic Brew:
www.euphonicbrew.com |
|
| Back to top |
|
|
msw188
Joined: 02 Jul 2003
Posts: 1041
|
| Posted: Sat Dec 08, 2007 7:06 pm Post subject: |
|
|
Okay, not extensive testing by any means, but everything seems to work as it should so far. I also found a really horrible mistake. Note to scripters: for loops increment their counter variable at the end of their last iteration (otherwise how would they know they are done?). In other words, the code
| Code: | for(i,8,13),do
begin
#blah blah
end
showvalue(i) |
will show 14, not 13. Don't be dumb like me and think that you can just start your variable from where it ended in the loop.
About that read NPC command, all I really need is a way to restore a one-time usable NPC (like a treasure chest) if none of the player's heroes had room for the item and he did not decide to drop something. The plan is to take the NPC ref, check to see if the NPC is still there (if it is, then the NPC was not one-time usable), and if not then to restore the relevant one-time use tag. So my questions are as follows:
1. When an NPC calls a script, does the script run before or after the one-time usability tag is set?
2. Can an NPC ref ever be the number zero? (I really hope not)
3. Since I have to use the item argument for the item ID, how can I discover what the relevant one-time usability tag is?
Actually, I've begun thinking of a way around #3, which will be a fair pain though. Now that variables are 32-bit, that means I can have a six-digit argument without a problem, yes? I guess I could pass both the item ID and the (tag--1000) as one argument and parse it up in the script... does this sound like a workable idea? If so, I'm sure someone explained this to me before, but,
4. How does Hamsterspeak handle modular arithmetic of negative numbers?
I will possibly be using negative itemIDs to indicate that an item is NEEDED, unless we get commands to read item data.
_________________
My first completed OHR game, Tales of the New World:
http://castleparadox.com/gamelist-display.php?game=161
This website link is for my funk/rock band, Euphonic Brew:
www.euphonicbrew.com |
|
| Back to top |
|
|
Bob the Hamster
OHRRPGCE Developer
Joined: 22 Feb 2003
Posts: 2526
Location: Hamster Republic (Southern California Enclave)
|
| Posted: Sun Dec 09, 2007 9:44 pm Post subject: |
|
|
"read NPC" can do everything you need, although some of it is undocumented.
To know what item an NPC gave you, do this:
| Code: | | item := read NPC(ref, NPCstat:giveitem) |
To know what one time tag an NPC uses, do this:
| Code: | | onetimetag := read NPC(ref, 11) + 1000 |
Although I can guarantee that the above code will not work the same way in a future version. Because of the way one-time-tags are stored, they mean we can't increase the available tags without breaking plotscripts that alter one-time tags.
Naturally, I will do my best to minimize any compatibility problems, but bear in mind that you will probably have to change your script if you want to re-compile it after the 999 tag limit gets raised. |
|
| Back to top |
|
|
TMC
On the Verge of Insanity
Joined: 05 Apr 2003
Posts: 3240
Location: Matakana
|
| Posted: Mon Dec 10, 2007 2:47 am Post subject: |
|
|
| msw188 wrote: | | 1. When an NPC calls a script, does the script run before or after the one-time usability tag is set? |
Here's the on-map loop:
-Get new keyboard/mouse state
-Run scripts
-Game logic
-Draw screen
-Wait
-Repeat
So triggered scripts (somewhere in the 'Game logic') are always actually run the next tick, "after".
| msw188 wrote: | | 2. Can an NPC ref ever be the number zero? (I really hope not) |
No, npcrefs currently range from -300 to -1.
| msw188 wrote: | | Actually, I've begun thinking of a way around #3, which will be a fair pain though. Now that variables are 32-bit, that means I can have a six-digit argument without a problem, yes? I guess I could pass both the item ID and the (tag--1000) as one argument and parse it up in the script... does this sound like a workable idea? If so, I'm sure someone explained this to me before, but, |
Scripts are 32-bit (which is 9 full digits) but almost all data files, such as NPC definitions, are still 16-bit. This means that anywhere that you can pass an argument to a script, you can only give a 16-bit number.
| msw188 wrote: | | 4. How does Hamsterspeak handle modular arithmetic of negative numbers? |
I went into great detail of this somewhere, but CP's forum search doesn't work, and Google hasn't indexed much of the forums. Basically, the same way as native x86 code (the wrong way), which means, IIRC:
-15,mod,5 == 0
-7,mod,5 == -2
Can't remember what division by negative numbers ended up as.
_________________
"It is so great it is insanely great." |
|
| Back to top |
|
|
msw188
Joined: 02 Jul 2003
Posts: 1041
|
| Posted: Mon Dec 10, 2007 9:21 am Post subject: |
|
|
| Quote: | | No, npcrefs currently range from -300 to -1. |
I was pretty sure I knew this, but it is beautiful to have confirmation. Thank you.
| Quote: | To know what item an NPC gave you, do this:
Code:
item := read NPC(ref, NPCstat:giveitem)
To know what one time tag an NPC uses, do this:
Code:
onetimetag := read NPC(ref, 11) + 1000
|
I can't believe I didn't think of this. Why waste the argument on the itemID when I could use the NPCstat:giveitem? It's unfortunate because I've already written that part in such a way as to make items from battles use the same function, where I can't read the NPCstat:giveitem. I'm not sure how much it would help me (if at all) to rewrite to use this kind of system. Probably not, since I think I am going to go the negative itemID route for 'undroppable' items.
| Quote: | | Although I can guarantee that the above code will not work the same way in a future version. Because of the way one-time-tags are stored, they mean we can't increase the available tags without breaking plotscripts that alter one-time tags. |
I saw you guys talking about this. So here is my first question. If the memory limit on tags is being raised, does there have to be any support for 'one-time' usable tags at all? What's the difference? Just have all old games move the one-time-use tag numbers for their one-time NPCs to the line "appear if tagx==off", and because said games will not have duplicated this tag number anywhere else, no problem should arise. All new games do not have 'special' tags of any sort, and the tag editor allows you to go up past 1000. NPCs no longer have a 'usable one time' option, rather with the new tag freedom authors have enough to give the NPC a unique "appear if tagx==off".
Now it'd be nice to use NPCstat 11 for other things after this, but on the NPC editor maybe it says "extra data (used to be one-time use tag#-1000)". Does any of this make sense, or am I just way off-base here?
Alternatively, for myself, if you are just changing the storage method, would it be safe for me to assume that the one-time tags will always be NPCstat 11 + some constant? So I can juse define a global constant, so to speak, and use that everywhere, and then if you guys change it, I only have to change one number in my script?
_________________
My first completed OHR game, Tales of the New World:
http://castleparadox.com/gamelist-display.php?game=161
This website link is for my funk/rock band, Euphonic Brew:
www.euphonicbrew.com |
|
| Back to top |
|
|
Bob the Hamster
OHRRPGCE Developer
Joined: 22 Feb 2003
Posts: 2526
Location: Hamster Republic (Southern California Enclave)
|
| Posted: Mon Dec 10, 2007 11:10 am Post subject: |
|
|
| msw188 wrote: |
| Quote: | | Although I can guarantee that the above code will not work the same way in a future version. Because of the way one-time-tags are stored, they mean we can't increase the available tags without breaking plotscripts that alter one-time tags. |
I saw you guys talking about this. So here is my first question. If the memory limit on tags is being raised, does there have to be any support for 'one-time' usable tags at all? What's the difference? Just have all old games move the one-time-use tag numbers for their one-time NPCs to the line "appear if tagx==off", and because said games will not have duplicated this tag number anywhere else, no problem should arise.
|
That would break for any games that use one-time NPC tags in combination with both tag conditionals, and it would not solve the basic problem of games that plotscript one time use bits with "read NPC" and "alter NPC"
| msw188 wrote: | | All new games do not have 'special' tags of any sort, and the tag editor allows you to go up past 1000. NPCs no longer have a 'usable one time' option, rather with the new tag freedom authors have enough to give the NPC a unique "appear if tagx==off". |
Hmmm. No, I really like the "one time use" feature, and I was even planning on expanding it for other things such as menu item usage. It is very convenienc to be able to make a thing one time usable without having to worry about manually allocating a tag number.
| msw188 wrote: | | Now it'd be nice to use NPCstat 11 for other things after this, but on the NPC editor maybe it says "extra data (used to be one-time use tag#-1000)". Does any of this make sense, or am I just way off-base here? |
If I was going to add extra NPC data, I would add it as a new data member, not a re-purposing of old data. Bad backcompat karma.
| msw188 wrote: | | Alternatively, for myself, if you are just changing the storage method, would it be safe for me to assume that the one-time tags will always be NPCstat 11 + some constant? So I can juse define a global constant, so to speak, and use that everywhere, and then if you guys change it, I only have to change one number in my script? |
Well, here is what I expect will happen:
Plan for increasing available tags
Now that I have thought it through in writing, I think it can be done without any serious disruption to your game. Just go ahead and work as you planned, and you won't have to worry about changing anything in your script unless you decide to add to the maximum tags in your game. |
|
| Back to top |
|
|
msw188
Joined: 02 Jul 2003
Posts: 1041
|
| Posted: Mon Dec 10, 2007 9:53 pm Post subject: |
|
|
| Quote: | | That would break for any games that use one-time NPC tags in combination with both tag conditionals, and it would not solve the basic problem of games that plotscript one time use bits with "read NPC" and "alter NPC" |
I realized the first part in the shower (great place for thinking), but didn't get a chance to post it. I didn't think of people altering the one-time usability tag, just shmucks like me reading it.
Well, thank you for everything so far. I am getting pretty close to having the system set up properly. While it'd be nice to be able to disable the Item menu in battle, it doesn't break functionality at all (I just changed the global text string to "[unused]"). The worst is the inability to affect levelMP in battle (although I wonder what happens if I set someone's levelMP negative - would that make the spell infinitely usable maybe? I guess you'd probably call it a bug, but it sure would make me happy). No item-reading command and no attack-using (or item-using) command are both problematic, but side-steppable (I'm using enemy data to read attacks for items, which reminds me: Can enemies uses levelMP attacks?). I'm sure I'll run into some more problems once I get to equipment (the only thing I haven't started at all yet).
| Quote: | | or if you really want to do this the easier way, you just learn FreeBasic, and help me write the feature into the engine ;) |
Heh, if only I knew anything about programming. I did take one mandatory course in college, but we never got anywhere beyond one-dimensional arrays, and I don't really remember it anyway. All of my actual knowledge about any of this comes from Hamsterspeak, and pretty much Hamsterspeak alone. No, I'm much better as that guy who asks for annoying generalizations and customizations of current features, all of which just end up seeming like attempts to make Dragon Warrior instead of Final Fantasy.
_________________
My first completed OHR game, Tales of the New World:
http://castleparadox.com/gamelist-display.php?game=161
This website link is for my funk/rock band, Euphonic Brew:
www.euphonicbrew.com |
|
| Back to top |
|
|
|
|
You can post new topics in this forum
You can reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
