Okay so I haven't coded anything in a while and I'm going after the skeleton I had of a grid system for rooms. Trying to make things run better and make more sense, be more self-sufficient sort of.

A piece of syntax I'm wondering about is the old...

for <i; 1; %thisnumber%>

Is it possible to have two instances of that running in the same uh, "process". Let me explain better, ok, if a room has a layout of a grid, x and y, 10 by 10, and I wanted to visually represent this grid on the screen, sure I could just have quest get the x and y size of the room and print out a 10 box by 10 box little grid, that's easy enough. Now suppose we want to check each object in the room's properties to see if and what section of this grid it occupies, of course you can do a "for each object" type deal but it seems a little inefficient checking for each number of the grid. What I'm wondering is if a piece of syntax could look like this would work...

for <x; 1; $objectproperty(#quest.currentroom#; x)$> AND for <y; 1; $objectproperty(#quest.currentroom#; y)$> // maybe the and isn't necessary, perhaps just setting the variables to be anything on those scales is enough

It seems like in some form it could work, Alex probably has it set up where the "for" only sets the variable as a "sliding" one and they can be combined, I just haven't tried it and wanted to shoot it by some people.

Another problem, though it seems easy enough, would be controlling view of objects through the direction they are facing. This seems easy to control via a scope type property on players, giving a virtual uh, peripheral vision. That seems easy to implement by only having the x and y co-ordinates of the map be positive numbers and in more sense a chart than a grid and processing only a cone type shape of the grid in that direction... ie:

                 * pov
1,1 1,2 1,3 1,4 1,5 1,6 1,7 1,8 1,9 1,10
2,1 2,2 2,3 2,4 2,5 2,6 2,7 2,8 2,9 2,10
3,1 3,2 3,3 3,4 3,5 3,6 3,7 3,8 3,9 3,10
4,1 4,2 4,3 4,4 4,5 4,6 4,7 4,8 4,9 4,10
5,1 5,1 5,3 5,4 5,5 5,6 5,7 5,8 5,9 5,10
6,1 6,2 6,3 6,4 6,5 6,6 6,7 6,8 6,9 6,10
etc.
If they are standing on 1,5 facing south, they can see 2,5 3,5 and 4,5 straight in front of them and a broad field of the according *,3 *,4 *,6 and *,7's as well.

So I suppose that seems sort of "easy" enough to do, right? I imagine to make it so quest can cout out the grid for viewing it would probably be best if it operated on some ansii graphic string variables that were preset. That way it tests each object in the room for it's "grid" position, stores those positions in variables with references to the object name, and these objects properties are tested to see if it is a mob, npc, piece of scenery, etc., and finally the grid can begin filling in empty squares get to a variable it knows an object is at, insert the appropriate little "graphic" and continue/repeat as necessary.

Eh, I don't know what this was about, just crap on my mind. As always, questions, comments, ideas, opinions and reaming is all welcome and all is open to interpretation.

Right read most of the post ITID... Missed out some lines in your last 2 paragraphs I think (I'm a bit tired now... I'll re-read everything later and see if it makes more sense).

For your loops I would guess one within the other would do just fine. One loop counting the y's then a loop inside counting the x's....
Ie:
loop1, = 1
loop2:
1,1 1,2 1,3 1,4 etc...

then loop1 = 2
loop2:
2,1 2,2 2,3 2,4 etc...

I'm taking it your giving each object in the room a position vector property (ie property X and property Y) then just searching through it getting those values to see what is where (IMO the easiest way).
You can also move/drop these objects at different points on the grid easily, also throwing them shouldn't be too hard either - just alter the X and Y prop's.

For the perspective I would guess at 1, 3, 5, 5 being a good perspective...
Let's example:

    # #
  # # #
# # # #
  # # #
    # #

Or maybe something different. All you need to do is reference the players' position with his direction and alter the two loops from above to match this 1, 3, 5, 5 pattern.
I may be able to go into more depth but I am quite tired (being awake for 24 hours AGAIN).... and hungry.... and thirsty....

Slightly off topic but commenting on you going back to old work - I'm dreading going back to my RPG battle system after so long (about 1 month), I really want to get things going though as I don't honestly see things getting hard for quite a while!

Now suppose we want to check each object in the room's properties to see if and what section of this grid it occupies, of course you can do a "for each object" type deal but it seems a little inefficient checking for each number of the grid. What I'm wondering is if a piece of syntax could look like this would work...

Re-read that... The thing that immediately comes to my mind is array!
Go through a loop checking each object in the room and check the X & Y properties. Then place this object in the array with the corrosponding X and Y....
IE:
Object 1 has properties <X=2; Y=3>
As you check through them you'd put object 1 in the array:
currentroom[XY]
If you start at 0 and go to 9 then you can have a 10x10 grid stored easily.
Getting the grid bigger is curious. I think the array right now is restricted to one-dimensional...
So work on a script to convert the Y in the example to 2 digits to get up to 9800-odd rooms. Or 3 digits for a higher grid.
(NOTE: creating arrays above around 1000 means quest halts while it's creating them - Alex uses a Loop without "do events". I suggest you have rooms of 10x10 grids or 20x20 grids... I wanted a big array for my monsters I was working on. I found it wasn't necessary - more than 1000 monsters isn't needed??)

.... Another problem arises when you put multiple objects in the same array space. This is easy if you put either markers to seperate the object names (/ or \ does nicely) and use Quest's string processing functions to seperate them. You can always add numbers to the beginning to seperate certain criteria of objects if you want to use that to describe the squares or objects from players etc... I use this for monster actions FYI. I just need to actually move the code out of my head.

The periferal(SP) vision I dealt with in my previous post as best as I could explain without taking up loads of space.

As for the displaying the object's etc - yes. A property maybe of "sign=" or "type=". Type would mean you take that, put it through a multiple "if" system and then display the result. The sign would mean it would display the sign as raw text. This (IMO) would be best as you can have slight variations etc... and put text code in there (|xb |cbl etc...) so it may be customizable to some degree.
With this customizability (yeesh! Long words aren't me!) comes the ability to ruin the map... The only help I can even attempt to offer here is to maybe stop text re-sizing, and stop anything over a certain amount... You can always allow the user to have a "more info" command for certain squares etc... Which can be stored in other properties!

This looks quite interesting... It would be very cool to be looking at a 10x10 grid seeing "CW" in red in a 'square'.
Oh, another thought entered my head - if you have 10 objects in a room then it will REALLY screw up the map. Maybe a key with "1-10 objects = # 11-20 objects = #, 1-5 NPC's = #, 6-10 NPC's = #, 1-5 users = # etc...). That will limit the amount of distort by 100%, meaning they will need to ask for more details on certain squares to bring up the details.

I've left the stuff above just as idea's for you - it may help, may not (the same applies for all of this post!)

How do you get For/Next loops and arrays in QDK, like you were using above?

Matthew G.