Sorry your browser is not supported!

I created a really cool pushbutton interface for my game. I have a strip bay, with flight strips in it. Then, when you click on the strip, a pushbutton interface is positioned on top of the strip, and presents the user with a series of buttons that are linked to other buttons. I created the interface standalone outside of my game to make sure it would work. It provides 276 different command combinations for the interface.

I am using animated sprites, as well as standard sprites for all of this. The stripbay is a sprite, the flight strip is a sprite, the interface is a sprite, and then the buttons themselves are animated sprites. I have numbered the images, and the sprites starting with the strip bay first.

I then set the sprite priority of all to match its position in the stacked layer(s).

1. strip bay - 2
2. strip - 3
3. interface - 4
4. buttons - 5
5. mouse cursor (also a sprite) - 6 or 1, to make sure it is drawn last.

At the end of the function creating the interface, I set the priority of all of the elements above in that order. The game loop then looks for a SPRITE COLLISION of the sprite_mouse with any other sprite. Now, regardless of the sprite priority, it does not detect anything stacked above the strip bay - level 1.

I've numbered the images/sprites/priorities backward and forward with the sprite_mouse either a 1 or, 1 level higher than every sprite created. It simply does not work.

Can someone please explain the EXACT rules for sprite priority when using the SPRITE COLLISION command. This is such a rudimentary concept, but yet I have spent weeks trying to make this work to no avail. The help system in DBPro leaves a lot to be desired, as well as the debugging features of the language. It is extremely difficult to check even just a single variable value while the app is running.

I've added sample image of what the interface looks.

You might be better of just writing your own function to check if one sprite's bounding rectangle lies within another and check for collisions in that way; I'm pretty sure that's how the built-in sprite collision functionality works. For a mouse cursor you would (probably?) only be interested in whether its tip pixel is overlapping the target sprite as well.
I'm unsure about what you're asking, I've never really used sprite collisions like that (or at least not for many years), but I'm having a hard time believing that sprite priority would play into what can collide with what. You can test this quickly by just removing the priority setting (if you don't manually set it the priority will be that the sprites are drawn in the order they were created if I recall correctly); does it work as intended then?

What happens if the sprite mouse overlaps more than one sprite button? The help file doesn't say.

I would use plains rather than sprites, plus pick object with the real mouse.

My solution is to use the "print console" command in "Matrix1's Dlls".Here is a code snippet to create the console window.



Then just call this anywhere in your code to get the value you need.



I can't help with the sprite commands because I use the Advanced2d dll instead.

[img][/img]

Thanks guys. I do have a function called "Commoutput" that will print anything I want to the screen in a text area. That sounds like the console idea.

The funny thing is, my interface with multiple buttons works fine outside of the game. I even added the sprite elements in my test version as found in the game. It just fails once inside the game. I had assumed the priority of the sprite(s) determines which sprite interacts with the collision command; which it does as expected in the standalone configuration.

My other alternative is to use the BlueGUI addon and create the buttons that way. But it too has some limitations.

I've attached a flash animation showing the interface in action. This is how it behaves standalone. So I am baffled as to why it stops working inside the game....

Well..I did make some progress. If I move the interface away from the strip bay, the sprite collisions are detected correctly. So there must be a value assigned to the underlying sprites that are receiving higher detection treatment. I'll have to experiment, or simply leave the interface elements outside of the stripbays to make them work.