It could be a default of 1, which is basically what input() does, stack items of the same name.
Setting this to zero could be useful, assuming you don't want to stack items.
~~> Dragon Lord
ID:259797
 Aug 21 2004, 3:27 pm
|
|
|
Aug 21 2004, 5:13 pm
|
|
Foomer
 |
It'd be nice, but you might just be better off using a statpanel or browser popup instead...
|
If you don't have items stack, how would you tell items with the same name apart?
| |
Foomer wrote:
By their position in the list. You know, kind of like this:
Suddenly I am intrigued. If there's room for another bit flag to go with the ones like null|anything, then presumably we could do a "position" type to go with it, which would implicitly prevent stacking. The only problem is, input() is one of the more truly arcane parts of the code. And any such change would only be compatible with new clients built to support it. Still, this is worth mulling over. Lummox JR | |
I'd find that useful too. At the moment, if I write any type of turn-based battle system that uses the input command to get targets for attacks, I have to add a number on to the end of the name of every monster there, so they don't stack.
| |
Foomer wrote:
It'd be nice, but you might just be better off using a statpanel or browser popup instead... I'm with Foomer. Use an HTML page instead. You can keep it a pure and simple list, or tack on as much extra information as you like (co-ordinates, icon, desc, price, attack strength, et al.) The popup browser is the most powerful interface element we have, yet it is completely overlooked by many. (Spuzzum, write your dynamic HTML article already! ;) ) | |
Shadowdarke wrote:
Foomer wrote: Although if we could get statpanels with limited HTML/table (and popup!) support, it'd be a lot more useful, since statpanels make it much easier to interact with objects shown in them. | |
Foomer wrote:
Although if we could get statpanels with limited HTML/table (and popup!) support, it'd be a lot more useful, since statpanels make it much easier to interact with objects shown in them. Tom experimented at one point with HTML stat panels, but I don't think he got very far. If implemented they would be very similar to the text output window, and would have the same limitations. Tables would probably be impossible. Lummox JR | |
Lummox JR wrote:
Tom experimented at one point with HTML stat panels, but I don't think he got very far. If implemented they would be very similar to the text output window, and would have the same limitations. Tables would probably be impossible. Actually, all I did was allow some html commands to be embedded in the current statpanels, to support color and such. It worked ok, but was a bit hacky so I shelved it for a more complete later implemenation. | |
It seems like statpanels already have some support for tables, just not the HTML variety. You can put information on either side of the statpanel, which is like having two columns. You can put rows of text, so you have rows. Add some support for more columns, and some arguments that lets you determine how many rows and columns each stat uses, and you've got tables! (Mostly, anyway...)
| |
Foomer wrote:
It seems like statpanels already have some support for tables, just not the HTML variety. You can put information on either side of the statpanel, which is like having two columns. You can put rows of text, so you have rows. Add some support for more columns, and some arguments that lets you determine how many rows and columns each stat uses, and you've got tables! (Mostly, anyway...) With names, data, and suffices, you can have three columns (you'll note that Shadowdarke does this in Darke Dungeon). Space can get a little limited that way, unfortunately, unless you have a wide map view. | |