Should there be a stacking limit in room-type regions?

by **Admiral Ackguh** » Sat Nov 03, 2012 11:54 am

joebonk wrote:There are very few basic items in the game. Just about 80%
of all weapons armor and items are game necessities as each has a particular powers (given mostly by gods). So they
can't be eliminated. I did notice a destroy object option while
dropping something and because its the D keypress I
accidentally destroyed/discovered this was possible. And is there a way to disable this? I would hate for the player to do
this either by error or accident. These items are required.

Hello... I finally got a registered ID here.

For artifacts, just set the weight to 00. The item becomes indestructible, undroppable, and unsellable. It otherwise functions as a regular item with zero weight. So you can create a SUPER MAGICAL SWORD weapon with weight 00 and godly damage. Like all items, these would have an INV variable, and using code to change this value is the only way to get rid of these items.

Also, since artifact weight is essentially zero, you can use the STR = 0 and encumbrance method as rld suggested. Don't forget to reset STR to its former value later. I find it useful to have SPELL/SKILL objects to store base STR, INT, WSK, and RWSK.

by **joebonk** » Sat Nov 03, 2012 4:40 am

Awesome ideas. I like best the several rooms/doors
because it makes it easier for the player to get their stuff.
But zero encumbrance is great too.
There are very few basic items in the game. Just about 80%
of all weapons armor and items are game necessities as each has a particular powers (given mostly by gods). So they
can't be eliminated. I did notice a destroy object option while
dropping something and because its the D keypress I
accidentally destroyed/discovered this was possible. And is there a way to disable this? I would hate for the player to do
this either by error or accident. These items are required. And are only one in the game.
But Actually maybe only one room for dropping objects.
I wonder if you could stack doors that destroy upon passing, but another one is right underneath requiring further without items. But then maybe they player would then be standing on it and it wouldn't work.

by **rld** » Fri Nov 02, 2012 11:11 am

A few possible ways to do this:

1) Since there are settings for SPACEs of "PASSABLE IF NOT HOLDING <type>", as you said, you could put several in a row; first the player has to pass through one that doesn't allow WEAPONs to pass, then one that blocks RANGED WEAPONs, then one for ARMOR and one for MISC ITEMs.

A bit hacky, but it should work. You might want SPELLS/SKILLS to stay with the player since they are knowledge, not physical objects; if you don't, you have to use another method to remove those, since the player can't drop them directly anyway.

2) Similarly, use the "take all TYPE items from player" action to just clear out the player's inventory. This won't let you restore it later, but depending on what happened to the player, maybe they shouldn't get everything back anyway. If the player is getting captured, the guards probably looted their stuff anyway...

You can always have the player 'find' a subset of stuff when they escape, including anything you know they had to have on them when they were captured, and any key items they will have to have to continue the adventure; you can always save restore a few choice items manually if you want.

Or just give the player the bare minimum back, and one of the puzzles is for the player to figure out where to stash their stuff BEFORE they get captured so they can retrieve it afterwards...

3) If you set the player's strength (STR) to zero, the encumbrance feature will probably force them to drop everything they are carrying with a nonzero weight before they can continue moving.

by **Admiral Ackguh** » Thu Nov 01, 2012 7:08 pm

joebonk wrote:would it be easier to take inventory from a player and
have it in a locker, or would it be easier to have a door
that won't let you through until the player drops everything?
It might save a lot of typing out a macro.

I would say the latter (a door passable only if no items) would be easier. But even that is non-trivial; it will need a portal with a large macro that goes through every INV item the player could possibly have, and sets SUCCESS to 0 if any >0. Remember, INV is not a true array, and cannot use a variable as its subscript. So you can't loop through INV and branch out of the loop if any item is non-zero.

Also, the PASSABLE TO setting of a space or portal may be set to ONLY IF WITHOUT specific item or type - but not only if without any items.

- A:A:

by **joebonk** » Tue Oct 23, 2012 10:35 pm

would it be easier to take inventory from a player and
have it in a locker, or would it be easier to have a door
that won't let you through until the player drops everything?
It might save a lot of typing out a macro.

by **Admiral Ackguh** » Mon Oct 22, 2012 9:11 pm

Admiral Ackguh wrote:My storage-cabinet code takes up four macros. It starts by disassembling the stack; using a loop to place each dummy item on another part of the room. Item #1 goes onto square 1,0; #2 goes to 1,1; etc. (This is usable only in rooms at least 16x5 in size.)

I meant to say:
Item #1 goes into square 1,1; #2 goes to 2,1, etc.

- A:A:

by **Admiral Ackguh** » Mon Oct 22, 2012 4:39 pm

rld wrote:Seems like there is a use for large item stacks under certain circumstances, but really these are being used as workarounds for the fact that there isn't enough variable space and ACK doesn't support any data structures like arrays or stacks.

You got that right!

I can imagine that keeping a large stack in a space for something like a storage locker or chest gets a bit tedious to macro code, because if you want to see if something is in there, you have to take every item off the stack one by one using MAPTAKE until you get to the one you want, right? Then you have to put them all back.

My storage-cabinet code takes up four macros. It starts by disassembling the stack; using a loop to place each dummy item on another part of the room. Item #1 goes onto square 1,0; #2 goes to 1,1; etc. (This is usable only in rooms at least 16x5 in size.) The room itself becomes a pseudo-array - but the user never sees the clutter of dummy objects behind the long message serving as a user interface. After the user is finished, the program cleans up everything, removes the scattered dummy objects, and rebuilds the stack, finally putting a cabinet object on top.

What we really need added to the engine is a way to save/restore large chunks of additional game data, in a way where the new data files are saved/restored along with the rest of the saved game state.

The patch already added the new 'scratch variables', but currently these are lost when the game is saved/restored. If I got additional functions working that would allow these to be copied to and from block data files in the game directory (allowing data to be accessed 256 variables at a time) they would be a lot more useful.

Then all you would need would be some more commands to copy various portions of game state to and from the scratch variable array. For example, "save inventory" and "restore inventory".

It would also be useful to associate this saved block data with map locations, so you could have a macro function check, "is there any extended data located at this map location?" or "is there any extended data associated with this room?"

That would help, along with actual arrays and/or stacks, with full indirect addressing. The INV and HELLO variables are not true arrays. Changing them, to the point of allowing a variable as address, would also be a great help.

- A:A:

by **rld** » Mon Oct 22, 2012 9:32 am

Seems like there is a use for large item stacks under certain circumstances, but really these are being used as workarounds for the fact that there isn't enough variable space and ACK doesn't support any data structures like arrays or stacks.

I can imagine that keeping a large stack in a space for something like a storage locker or chest gets a bit tedious to macro code, because if you want to see if something is in there, you have to take every item off the stack one by one using MAPTAKE until you get to the one you want, right? Then you have to put them all back.

What we really need added to the engine is a way to save/restore large chunks of additional game data, in a way where the new data files are saved/restored along with the rest of the saved game state.

The patch already added the new 'scratch variables', but currently these are lost when the game is saved/restored. If I got additional functions working that would allow these to be copied to and from block data files in the game directory (allowing data to be accessed 256 variables at a time) they would be a lot more useful.

Then all you would need would be some more commands to copy various portions of game state to and from the scratch variable array. For example, "save inventory" and "restore inventory".

It would also be useful to associate this saved block data with map locations, so you could have a macro function check, "is there any extended data located at this map location?" or "is there any extended data associated with this room?"

by **joebonk** » Sun Oct 21, 2012 3:13 am

The admiral is right. If my game takes away all the
inventory items of the player (he goes to jail),
then all that stuff would be stacked later for him/her when
the sentence is done. And there may be a lot of items.
Didn't think of that.

by **Admiral Ackguh** » Sat Oct 20, 2012 3:04 pm

rld wrote:The thing I am wondering is, given the additional flexibility that macros offer in ACK, does it really make sense to have to be able to stack 20/30/40/50 items on a square? Does anyone ever do this in their adventures?

Yes.

Earlier I wrote about a storage cabinet object in one of my games. It uses extensive stacking of dummy objects in room-type regions, to keep track of what is stored there. With 37 possible object types (up to 255 objects of each) plus one checksum object plus the cabinet itself - that could add up to 76 items on a square! it is unlikely that there would be a 76-item-stack in an actual game, but 20-item stacks would be common.

I often use stacked dummy objects for other purposes. Custom spaces/obstacles allow a 0-255 number for extra info, and I use this feature often. But it is sometimes not enough. For some items, I stack a dummy object underneath for an additional 8-bit number. I could use additional macro code to "do this if this item is in this place" but sometimes I prefer to put the extra item data in the maps.

But what would a good limit be? Something in the 10-20 range sounds reasonable to me; even ACS (which had no macros at all) usually didn't stack more than a dozen or so things in a square at once.

For most games, a 20-item stacking limit sounds right. This really should be customizable at the "Configure Adventure" level, which means more and more screens. Or have a .INI type text file for advanced game configurations, including maximum stacking, thus not requiring any changes to the "Configure Adventure" screens.

by **joebonk** » Thu Oct 18, 2012 9:15 pm

So more then one item can be stacked on world maps, I always assumed that only one miscellaneous item can be on top of a terrain in world maps. This is good news.
I would think that the limit could be 16, i can't imagine someone needing more then that, besides they could always download an older version of ack for thier 400 stacked objects :)

by **Garth's Equipment Shop** » Wed Oct 17, 2012 1:50 am

Good points. I never stack anymore. I did in the beginning only because I was trying to do things the ACS way. But the more I became comfortable with using macros the less I stacked things. I find it far easier to debug or make changes or just see what is going on in someone elses adventure if I can just read through a bunch of macro code instead of having to go into map edit, find the right map, find the offending tile/coordinates, page through the stack, make note of each object in stack, then go to object editor and track down those objects to see how they are set. Stacking can be very time consuming and frustrating to handle if you are designing a large and elaborate world or any game that does more than just show and tell or walk you through some not-so-interactive script.

by **rld** » Tue Oct 16, 2012 10:41 am

So, the current design for the ACK engine allows objects to be stacked in room-type and worldmap-type regions as follows:

worldmap regions:
- 1 terrain item per tile
- any number of items/vehicles per tile
- up to 1 creature per tile

There seems to be a limit on the number of floating/movable items that can be in each world map. From the text export file, it looks like 255 total items/vehicles.

Room-type regions are similar except that they can stack any number of items in a space, terrain, items, whatever, even creatures, although a creature won't do anything on its turn unless it is the top 'item' on the stack.

There is a 'heap' of free spaces shared by all rooms in the region for stacked items, which allows you to put any number of items on a given tile should you want to for some reason (hundreds if you like), but there is a hard limit for the whole region of 2500 objects or so.

The thing I am wondering is, given the additional flexibility that macros offer in ACK, does it really make sense to have to be able to stack 20/30/40/50 items on a square? Does anyone ever do this in their adventures?

All the stacking mechanisms add a lot of complexity to the code - if there were just a fixed number of objects that could live in each location, it would take up a little more room in memory per tile, but it would be much simpler. And anyway, the whole ACK design assumes that you are only loading one room at a time into memory (for room regions), or a certain number of 16x16 'chunks' (for worldmap regions).

But what would a good limit be? Something in the 10-20 range sounds reasonable to me; even ACS (which had no macros at all) usually didn't stack more than a dozen or so things in a square at once.

If you had all the data stored together, it would be much easier and more predictable to do things like copy chunks of maps, save and restore states of rooms/areas, etc. on the fly.

Should there be a stacking limit in room-type regions?

Post a reply

Expand view Topic review: Should there be a stacking limit in room-type regions?

Re: stacking

stacking

Re: stacks

stacks

stacking

Re: Should there be a stacking limit in room-type regions?

stacking

Should there be a stacking limit in room-type regions?