A problem: making game remeber where are the items

[Overwhelming]

I need help with a problem:

 

It\'s posted here.

[Fort]

It's not possible.

[Overwhelming]

Yeah... I thought so. I was hoping someone would know a solution for this problem...

[Lattan]

Isn't there a check to find out what items are on a space? If there is, you can just go through every space in the town and copy them into the new town, though it would probably take a good while.

[Lilith]

That wouldn't pick up items the party might have brought in from other scenarios, and anyway it'd almost certainly exceed the script length limit.

[Archmagus Micael]

REad my reply in your BOA center forum. No2 is a probably the onl way to do it effectively. But, as I say in the other forum, it WILL need a lot of code.

 

- Archmagi Micael

[Lattan]

Quote:

Originally written by The Hexamethonium Man:
That wouldn't pick up items the party might have brought in from other scenarios, and anyway it'd almost certainly exceed the script length limit.

Now I'm confuzzled. You're saying the 'check items on space' command exists, but it won't work on items from outside the scenario?
And I don't have a clue why you think it would exceed the script length as it's a simple couple of loops.

[Lilith]

Pay attention -- what he wants to do is check items on every single space in town. That's a lot of runs through the loop, and it's the number of instructions that's counted for the single script length limit, not the number of different instructions. It'd take forever to run anyway.

 

And items from other scenarios can't possibly be detected by scripts because their data isn't stored anywhere in the scenario.

[Overwhelming]

I guess limiting it to a limited area (a container or two) would do it. Hummm... But I'll try fiting everything in a single town first.

[Lattan]

Quote:

Originally written by Thuryl:
Pay attention -- what he wants to do is check items on every single space in town. That's a lot of runs through the loop, and it's the number of instructions that's counted for the single script length limit, not the number of different instructions. It'd take forever to run anyway.

And items from other scenarios can't possibly be detected by scripts because their data isn't stored anywhere in the scenario.

Got the first part. Stupid 'infinite loop' check. Items from other scenarios must be detectable by scripts or they couldn't be used for anything, though, mustn't they?

[Lilith]

Just because the BoA engine can recognise them doesn't mean that scripts can. An item within a scenario is a unique number; a custom item from another scenario is just a list of stats.

[Eldritch_Cadillac]

A simple nested loop

 

x : 1 to town_width

y : 1 to town_height

copy items

next y

next x

 

will work fine, i think.

 

The time taken should be neglible. Underestimating the capabilities of even prehistoric computers appears to be a common misconception.

 

There are other ways if this really doesn't work, but i'd try this first.

[Lattan]

Quote:

Originally written by Eldritch_Cadillac:
A simple nested loop

x : 1 to town_width
y : 1 to town_height
copy items
next y
next x

will work fine, i think.

The time taken should be neglible. Underestimating the capabilities of even prehistoric computers appears to be a common misconception.

There are other ways if this really doesn't work, but i'd try this first.

The problem is that those instructions are executed so many times that it's likely to activate the 'infinite loop' error. But that's what I said should be done.
And while underestimating capabilities of computers may be common, it's not something I generally do. My 400 MHz Mac runs BoA fairly slowly (but playably) anyway, and a loop like that would make for a huge wait.

[Kelandon]

Well, let's do the math. In a large town (64 by 64), there are 4096 tiles to check. Assuming the code looks vaguely like this:

 

Code:

i = 0;while (i < 64)     {j = 0;     while (j < 64)          { // not sure what would go here           j = j + 1;          }     i  = i + 1;     } 

The interior "while" will run 64 times, meaning that the "while," the condition, and the stuff inside the brackets (total of two calls, let's say, but it'd likely be more) get run 64 times. That's 4*64=256 calls every time that "while" runs. The exterior "while" would also be run 64 times. Each time it runs, it calls the "while" itself, the condition, the j =, the 256 calls in the interior while, and the i increment. That's 259*64=16576 calls. One additional call (to copy, rather than just record items) would push the script up to 20672 calls. Another one would bring it up to 24768. Another one and you'd be pushing the consecutive calls pretty darn close to the edge, because I think the limit is 32000.

 

So, in other words, if you could manage to record and copy the item using four calls or less, I think you'd be able to do this.

 

Of course, it would take a DAMN long time.

[Fort]

I don't remember a call that returns the specific item on a space. I know there are special class calls, but not normal item type calls.

 

Even if it existed, it probably wouldn't work out too well because more than 1 item can be placed in a spot.

[Overwhelming]

On the other side, these instructions would have to be run only once (when the town changes to the cloned own.

 

The problem is to take information from one town, and copying it to another. I mean, in the editor, you can only load one town. In the game, when you exit a town, the variables are reset (i think). So I presume that when town A disappears, all its information disappears too. So if Town B replaces Town A, the later's information would be lost. Even if the scaning the town for items would be no problem, how would I tranfer them to another town? Where in the game's memory would that information be stored while the engine's switched the towns?

 

I guess it's impossible. Hum... I'm just going to check in BoA if the game remebers where I droped items, even after exiting and reentering the town. If it does, then that information is somehow stored in the save game and the engine's memory. So maybe some kind of solution may be reached for my problem.

 

Edit: it remembers. That information must be stored somewhere. Somwhere where I could store Town A's dropped items and then copy to Town B (cloned town)...

 

Maybe that's an impossible quest.

[Fort]

OF COURSE THE GAME REMEMBERS DROPPED ITEMS. It isn't as unforgiving as Exile, but remember that there is a limit.

 

If you wanted some variables to carry over, you'd just have to use SDFs.

[Eldritch_Cadillac]

Im sure this is far from an 'impossible quest'. I still think it can be done with a couple of loops, if necessary placing the actual copy stuff code in the scenario module to get around line limits. The scenario won't remember the items posistions apparently, however you can pass the relevent data using SDFs.

 

Otherwise, is there a way to execute code everytime a character drops an item? In which case you could store the location and type using SDFs, then refit the party by checking these when switching to the clone town.

[Pachat]

Putting the possibility aside, there are plenty of ways to make the item-scanning faster and less instruction-consuming.

 

For example you could define that only a portion of the town saves the items. Items are seldom placed on blocked spaces or on solid stone and pits. Also town boundaries limit the area to scan.

 

This could be achieved by making a lot of small scan-rectangles or just one large rectangle with exclusions marked in. That is, of course, a matter speed. Someone should test if which-terrain - is faster than item-on-floor - check. If it is faster to check if the terrain is suitable for items than it is to check if there are items on space, one should use the former. That is mostly because there are more empty spaces with no items than there are spaces with items in a town.

 

One alternative would be to scan the adjacent spaces of the party every time they drop or get items. That would leave only 9-18 spaces to check depending on party size. If a change is noticed, it is recorded into a flag. The problem is tracking items the party can grab from a distance.

[Drakefyre]

It's easier to tell them not to drop items and destroy all items that they drop. And by easier, I mean not impossible, like your first idea.

[Fort]

...because it seriously is, for all practical reasons, impossible. Forget the idea; let it die. But you can do other things with items, so don't fret.

[Dark Elf]

Garrison is right. Give this version of the idea up.

As far as the PCs are concerned, the town has a very active scavenger population. Add a few beggars running around, picking stuff up, peddling crude daggers, flagons, bowls and other nearly useless stuff, and maybe a toadstool. Have one character have a basement or other storage area safe from the scavengers. Charge a reasonable amount of money (about 10-20 coins) for its use. Make the basement a different town from the clone towns. Then, in either town, the PCs can get to their protected stuff.

Its also a much smaller number of calls for the CPU, and thus a much shorter wait when the town is entered.