 |
Castle Paradox
|
View previous topic :: View next topic |
Author |
Message |
Bagne ALL YOUR NUDIBRANCH ARE BELONG TO GASTROPODA

Joined: 19 Feb 2003 Posts: 518 Location: Halifax
|
Posted: Thu Dec 03, 2009 8:55 am Post subject: Many, many vaguely related questions |
|
|
I am looking for ways to store unusual information in map tiles.
For example, I've got a character that hops, and I'm using four-walled-harm-tiles to define "unhoppable" tiles.
I'm also currently using step-on NPCs to define where a particular kind of bush may grow.
I don't like using NPCs because it's become clear that I'm going to have many such bush-growing locations, and I know there's an upper bound of 300 NPCs on a map - also, I've read a warning somewhere that zillions of NPCs wreck the game performance.
How badly does many NPCs affect performance? Is it really only on slower computers?
I could break up my map into smaller maps (to get more NPCs)- that will work for now, but I know I'm probably going to be defining other unusual hero abilities like "hop" which require still extra information stored in the map tiles.
Maybe I should rephrase my question:
"What kind of information is stored at each tile, and how might I access it?"
I am only currently aware of "NPC at spot", "Read map block", and "Read pass block"
Apparently reading/writing formation sets is not currently possible.
Hm ... it just occurred to me that if I reserve a collection of invisible layer-2 maptiles, I could store all kinds of things ... but only on tiles where I know there won't be a layer-2.
I can't think of anything else.
Bonus questions:
Are there commands which suspend/resume door usage, and a command which identifies a door at X and Y?
Oh, and:
I also had an idea, maybe it's a dumb one - is it possible to assign a formation set's battle probability to 100% (I don't know the formulas involved)? If you wrap battles with an "instead of battle" script, you could make map triggers without using step-on NPCs. You just have to differentiate between the different cases by looking at the hero's X,Y, read map block, or whatever.
Why would you want to do this?
I don't know.
Maybe you want a trigger that NPCs can walk across. _________________ Working on rain and cloud formation |
|
Back to top |
|
 |
Moogle1 Scourge of the Seas Halloween 2006 Creativity Winner


Joined: 15 Jul 2004 Posts: 3377 Location: Seattle, WA
|
Posted: Thu Dec 03, 2009 8:59 am Post subject: |
|
|
Use the other map bits. Vehicle A and B can be used if you don't use vehicles (and sometimes even if you do) and overhead can be used if you use the "suspend overlay" command (I think that's it). If you're always using these in four-walled tiles, you have fifteen types to work with (A, B, AB, O, AO, BO, ABO, H, AH, BH, ABH, OH, AOH, BOH, ABOH).
The other option is to set aside specific maptiles for those purposes and then check mapblock instead of passblock.
Quote: | I also had an idea, maybe it's a dumb one - is it possible to assign a formation set's battle probability to 100% (I don't know the formulas involved)? If you wrap battles with an "instead of battle" script, you could make map triggers without using step-on NPCs. You just have to differentiate between the different cases by looking at the hero's X,Y, read map block, or whatever. |
Just use the "each step" script instead.
Quote: | Are there commands which suspend/resume door usage, and a command which identifies a door at X and Y? |
Doorlinks can be tag-dependent. There's no command for figuring out where doors are (though I wish there were). _________________
|
|
Back to top |
|
 |
Bagne ALL YOUR NUDIBRANCH ARE BELONG TO GASTROPODA

Joined: 19 Feb 2003 Posts: 518 Location: Halifax
|
Posted: Thu Dec 03, 2009 9:38 am Post subject: |
|
|
Yup, I'm already using vehicle A and B.
Oh ... I thought suspend overlay did layer 2 as well, but you're right, PS says it doesn't.
How do you suspend layer-2-overlay? Surely, that command must exist, but I can't find it.
So, if I suspend overlay and never resume, is it suspended for the rest of the game (after saves, after battles, etc?). I find this option tempting.
True, doorlinks are tag dependent - which I rarely use.
You can only use something like two tags, eh?
I suppose one could be reserved for all-around suspension, and the other for something else ... and I guess if I'll ever need further conditions added to the door use, I could use an NPC.
Oh yeah. True. On-step would work. The thing I like about using the foemap is that you can visually see where the triggers are when editing. _________________ Working on rain and cloud formation |
|
Back to top |
|
 |
Moogle1 Scourge of the Seas Halloween 2006 Creativity Winner


Joined: 15 Jul 2004 Posts: 3377 Location: Seattle, WA
|
Posted: Thu Dec 03, 2009 9:54 am Post subject: |
|
|
Bagne wrote: | Yup, I'm already using vehicle A and B.
Oh ... I thought suspend overlay did layer 2 as well, but you're right, PS says it doesn't.
How do you suspend layer-2-overlay? Surely, that command must exist, but I can't find it. |
I thought so too, but the only thing I could find is "layer tileset." You could use a blank tileset to achieve the same effect.
Quote: | So, if I suspend overlay and never resume, is it suspended for the rest of the game (after saves, after battles, etc?). I find this option tempting. |
I think you'll have to do it every time the game starts. It is preserved between battles, though. _________________
|
|
Back to top |
|
 |
Bagne ALL YOUR NUDIBRANCH ARE BELONG TO GASTROPODA

Joined: 19 Feb 2003 Posts: 518 Location: Halifax
|
Posted: Thu Dec 03, 2009 1:15 pm Post subject: |
|
|
Eh?
You mean to change the layer two tileset to something blank?
But... then all the tree tops etc would simply vanish.
That's not what I want - I want everything to look the same, except that NPC and hero sprites are on top of everything.
You'd use that effect for bridges or flying machines.
I read somewhere that overhead tiles were obsolete, so I Built a map assuming that layer 2 could be flattened into the lower layers ... oh dear.
I'll have an air vehicle you see...
Maybe I'll just have to go back to ugly overhead tiles in that map.
I'm also making a feature request - this is clearly an obvious thing to have. _________________ Working on rain and cloud formation |
|
Back to top |
|
 |
Moogle1 Scourge of the Seas Halloween 2006 Creativity Winner


Joined: 15 Jul 2004 Posts: 3377 Location: Seattle, WA
|
Posted: Thu Dec 03, 2009 1:20 pm Post subject: |
|
|
You can do that with slices, but there's no way to do it with NPCs, since the whole point of layer 2 is that it's drawn on top of them.
The simplest way to do this as-is would be to make the vehicle invisible during flight and use plotscripting to show a sprite at its location. _________________
|
|
Back to top |
|
 |
Bob the Hamster OHRRPGCE Developer

Joined: 22 Feb 2003 Posts: 2526 Location: Hamster Republic (Southern California Enclave)
|
Posted: Thu Dec 03, 2009 1:32 pm Post subject: |
|
|
I plan on adding a separate layer for NPCs and heroes. Once I have done that, you will be able to put NPCs on top of layer 2 with
Code: |
slice to front(lookup slice(sl:walkabout layer))
|
And you will be able to set it back to normal with:
Code: |
slice to front(lookup slice(sl:map layer 2))
|
But I am not done with the map drawing cleanup sufficiently to implement the walkabout layer just yet. |
|
Back to top |
|
 |
Bagne ALL YOUR NUDIBRANCH ARE BELONG TO GASTROPODA

Joined: 19 Feb 2003 Posts: 518 Location: Halifax
|
Posted: Thu Dec 03, 2009 1:37 pm Post subject: |
|
|
I don't know much about slices.
Is there something I can read somewhere?
I get the impression that it's a layer with sprites and/or text with/without a background ... yes? _________________ Working on rain and cloud formation |
|
Back to top |
|
 |
Moogle1 Scourge of the Seas Halloween 2006 Creativity Winner


Joined: 15 Jul 2004 Posts: 3377 Location: Seattle, WA
|
Posted: Thu Dec 03, 2009 1:49 pm Post subject: |
|
|
See, James, I always thought "slices" was a confusing and misleading name.
A slice is basically any graphical element, even an invisible one. Slice layers (like the walkabout layer, or maptile layers 0-2) contain lots of slices, but they are also themselves slices. It's slices all they way down. _________________
|
|
Back to top |
|
 |
Newbie_Power

Joined: 04 Sep 2006 Posts: 1762
|
Posted: Thu Dec 03, 2009 2:22 pm Post subject: |
|
|
Quote: | See, James, I always thought "slices" was a confusing and misleading name. | The entire concept of slices is confusing to anyone, because they're too multi-purpose to be called sprites or layers.
When it comes down to it, there's no better name than slices because they're never used for one single purpose. Hitboxes, for example, or keeping track of x/y positioning. There's the obvious fact that slices track maptile layers and sprites alike. There are even non-graphical purposes, such as fake OOP or hierarchical trees/linked lists. _________________
TheGiz> Am I the only one who likes to imagine that Elijah Wood's character in Back to the Future 2, the kid at the Wild Gunman machine in the Cafe 80's, is some future descendant of the AVGN? |
|
Back to top |
|
 |
Bob the Hamster OHRRPGCE Developer

Joined: 22 Feb 2003 Posts: 2526 Location: Hamster Republic (Southern California Enclave)
|
Posted: Thu Dec 03, 2009 3:11 pm Post subject: |
|
|
I like the name slices because it doesn't mean much of anything else. My runner-up choice for naming them was "thingies". All the other logical names for them like sprites, layers, rects, boxes, panels, frames, widgets, windows, etc all seemed misleadingly specific.
When somebody hears "use a slice for that" they think "what the hell is a slice? I better read the documentation" which is a good and appropriate response.
Of course, eventyally we will have support for real arrays, and we might want to add array index slicing, in which case I will have shot myself in the foot.
Maybe "thingies" would have been the better choice ;) |
|
Back to top |
|
 |
Bagne ALL YOUR NUDIBRANCH ARE BELONG TO GASTROPODA

Joined: 19 Feb 2003 Posts: 518 Location: Halifax
|
Posted: Thu Dec 03, 2009 3:38 pm Post subject: |
|
|
There's a zillion slice-related PS commands.
Is there any documentation on how they're used, and/or what they can do? _________________ Working on rain and cloud formation |
|
Back to top |
|
 |
Moogle1 Scourge of the Seas Halloween 2006 Creativity Winner


Joined: 15 Jul 2004 Posts: 3377 Location: Seattle, WA
|
Posted: Thu Dec 03, 2009 3:44 pm Post subject: |
|
|
Not really.
Here's the explanation James gave me some months back:
Quote: | A slice is a rectangular thing. It has an X/Y position, a Width and a
height, and it can be attached to the screen (root) or it can be attached to any other slice.
A great way to get used to what slices are capable of is to try out the
"Screen Layout Editor" in custom. Right now it is not yet actually capable of being used to lay out screens, but it does let you connect slices together and see what happens when you move them around or resize them.
Anyway, on to coding examples. Suppose you want to put a large enemy
sprite on the screen.
variable(sl)
sl := load large enemy sprite(0)
We have now added a slice containing a copy of large enemy sprite #0 to
the slice tree. The slice tree gets redrawn automatically, all we need to do is add things to it, and move them around. Here is how we move a
slice:
set slice x(sl, slice x(sl) + 10)
That moves the sprite 10 pixels to the right.
You may notice in the plotscripting dictionary that there are two sets of functions for working with slice x and y
"slice x" "set slice x"
"slice y" "set slice y"
"slice screen x" "set slice screen x"
"slice screen y" "set slice screen y"
At first glance these might seem to be totally redundant. Indeed, if you check out the values for our newly loaded large enemy sprite, you will notice that the x/y and screen x/screen y are the same.
The difference is, the slixe x/y values are relative to the slice's parent. Every slice has a parent. When we first load a sprite, the default parent for it is "sprite layer" which is a "special" slice. the sprite layer slice has an x/y of 0,0 and a width/height of 320,200 just the same size as the screen.
One of the really cool things about slices is that you can attach them to parents. For example, lets load a small enemy sprite that resembles a top-hat and put it on the large enemy sprite we loaded before.
variable(hat)
hat := load small enemy sprite(0)
set parent(hat, sl)
set slice x(hat, 23)
set slice y(hat, -28)
I'm just guessin on the x/y here, because I don't know exactly where the head of your large enemy sprite will be, but the point is that we have detached the hat sprite from the screen, and attached it to the large enemy sprite. Now if we say:
set slice y(sl, slice y(sl) + 5)
then BOTH the enemy sprite AND his hat will move together.
Now suppose that in this way we have set up 5 different enemy sprites, each of them wearing a hat. That makes a total of 10 slices on screen. Does that mean that we need to keep 10 variables to store their handles? Well, not really. Sure, you could be tucking the slice handles away in a fake array using "write global", but you don't really need to.
The fact is, the children of a parent slice are already kinda like an array. SO lets see how you loop through them without needing to know their handles in advance.
variable(handle)
handle := first child(sprite layer)
while(handle) do, begin
#do something to each handle here
handle := next sibling(handle)
end
So first we use the "first child" command. This takes any slice and gives us the handle to its first child, or 0 if there are no children.
Slice handles are always non-zero, so then we can say "while(handle)"
for our loop.
At the end of the loop, we use the "next sibling" command to get the next slice handle, or 0 if there are no more (and as you know, a 0 will cause the "while" loop to stop)
Now if we loop through our hat-wearing enemy sprites in this way, the while loop is going to loop through 5 times, once for each enemy.
Why not for the hats? The hats are NOT children of the "sprite layer" anymore. Remember? we re-parented them with the "set parent" command.
The hats are now childrewn of the enemy sprites (and thusly they are grandchildren of the sprite layer)
So what if we want to loop through all the hats and manipulate them?
variable(handle, hat)
handle := first child(sprite layer)
while(handle) do, begin
hat := first child(handle)
if(hat) then, begin
#do something to each hat here
end
handle := next sibling(handle)
end
See? We can use the "first child" command on the enemy sprite's slice handle and get the hat. Now suppose we wanted to allow enemies to maybe wear more than one hat... or glasses... or gloves or something.
variable(handle, clothing)
handle := first child(sprite layer)
while(handle) do, begin
clothing := first child(handle)
while(clothing) do, begin
# do something with each article of clothing here
clothing := next sibling(clothing)
end
handle := next sibling(handle)
end
And yes, children can have children which can have children, and so-on, until you create a family tree of slices that is so big you run out of memory.
One other thing to note is that if you delete a slice using "free slice" (or "free sprite") then all of its children will be deleted too, as if you are chopping the whole branch off of the family tree.
Okay. Does all of the above make sense? If not, let me know what I need
to clarify, and if so we can move on to talking about containers and rects. |
_________________
|
|
Back to top |
|
 |
Baconlabs PURPLE IS MANLY

Joined: 15 Mar 2009 Posts: 335 Location: Tennessee
|
Posted: Thu Dec 03, 2009 4:44 pm Post subject: |
|
|
The very first time I read about "slices" was in the wiki page for the OHRRPGCE Mobile Phone plans, where "menu slices" were described.
To be honest, I just accepted the term "slice" as itself, something totally new and previously un-named. And it has to do with rectangles. |
|
Back to top |
|
 |
Bob the Hamster OHRRPGCE Developer

Joined: 22 Feb 2003 Posts: 2526 Location: Hamster Republic (Southern California Enclave)
|
Posted: Thu Dec 03, 2009 4:45 pm Post subject: |
|
|
Baconlabs wrote: | The very first time I read about "slices" was in the wiki page for the OHRRPGCE Mobile Phone plans, where "menu slices" were described.
To be honest, I just accepted the term "slice" as itself, something totally new and previously un-named. And it has to do with rectangles. |
True, I did steal the name from the OHRRPGCE FMF, although they aren't exactly the same. |
|
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
|