Duplicating objects....

Finally got my computer back up and running...

Before I discovered Construct I was using Gamemaker (just a little) and the RPG Maker series. RPG Maker XP had a very handy feature called "self switches", and I was wondering if Construct has an equivalent function to it.

Basically, if I wanted to make a treasure chest I would have the first page of events be triggered by the action key, and that would turn on self switch "A" (the first switch). Under the page for switch "A" I would put the actions that I want the chest to perform (increase party gold by 500, display message "found 500 gold", change graphic to "chest opened", etc.).

After all that I would turn off switch "A" and turn switch "B" on. Switch "B" would simply display an "Empty" message to prevent you from gaining an infinite amount of gold.

Now, the difference between doing this with regular switches and self switches is that once I finish creating the chest using self switches I can copy and paste as many chests as I want and each of them will be treated as a new, unique item. Normally if you simply copy and paste an object then all of them would open at the same time and they would all be considered one single chest.

Soooo... what I'm wondering is; "Does Construct have an equivalent function to 'self switches'?"

Or, rather...

Is there any way to make an object like a treasure chest and have it possible for you to simply copy and paste new chests that all act the same but are considered new and unique objects?

The "paste clone" command doesn't do what I want...

http://www.mediafire.com/?csagmnte034

The .cap is pretty simple, just a character and a treasure chest with some events attached to it. If anybody understands what I'm looking for I would greatly appreciate your help.

**I won't be online again until Sunday so if anybody posts between now and then, thank you!**

http://www.mediafire.com/?9xygpzmjngq

Hope that works for now.

Thank you, Jeswen!

*sigh* I won't be able to test it until later tonight when I get home, but I'm crossing my fingers.

Oh, everyone else probably figured it out already but if you want to trigger objects using image points you have to have the name of your image points in quotation marks or it won't work. I realized this oh... I dunno, maybe 15 minutes after I posted the question.

Thank you again, Jeswen! That was exactly what I was trying to accomplish. I figured that it had something to do with families, or containers, or grouping...

I have to ask, how did you know that attaching a box to the main character's sprite makes copy and pasted objects work differently than usual? Is that just how most other programs do it, or are you just clever?

Accuracy is a problem, unfortunately. I didn't have a lot of time to work on it today but its surprisingly tricky to get your character to trigger only one chest at a time when they are lined up in a row.

I'm probably just trying to do it the hard way, though. I have an image point for every direction that the hunter is facing and the chests are set to be triggered if they are overlapped by one of the points. The annoying thing is that the "hit box" (for lack of a better term) also has to be touching the chest for the multiple copies to function individually.

I tried changing the hit box from solid green as you made it to a one pixel-wide cross, and that *almost* works. You can still trigger two chests at the same time if you are standing in exactly the right spot. I'm at work right now so I can't check, but I think I remember a "choose closest object" function? Could have sworn I saw it, at least... if so, that should probably do the trick.

http://www.mediafire.com/?lzjj102x7qy (the new .cap, complete with some ugly usage of image points... )

I also tried making the hit box solid and giving it four angles and and image point for each angle like I did with the hunter (and included an "always set hitbox's angle to hunter's angle) and I removed the hunter's image points, hoping that it would be more accurate that way... but for some reason its very selective about where exactly you are standing.

Well, I'll give it some more work tonight and tomorrow before work. This might be useful to someone so if I can get it working properly I'll post the .cap.

-later!

I have to ask, how did you know that attaching a box to the main character's sprite makes copy and pasted objects work differently than usual? Is that just how most other programs do it, or are you just clever?

The box just gives an additional condition that the chest must meet. In this case, must be touching the box and if it is not, it is ignored.

Here is an updated example that fixes that problem ... almost. It's still possible to open two if they are less than 1 px between, but maybe that is enough?

http://www.mediafire.com/?xnlic9yybcd

Lets bring the Hunter closer to the Chests. So its looks a little more natural.

And maybe even a Little more 2.5D.

Also lets try to use "bounding" collission dedection. Animated sprites tend to get stuck due

"pixel" dedection. Bounded is also a faster dedection. And its more a yes/no situation.

Black&White decissions. Easyer to stay out "stuck" situations.

We can not do this with the Hunters bounding box.

(I have no idea yet how to change the size of the boundingbox of a sprite. )

Therefor we make a new object. I named it TheEye. Its bounding box is holding the boundings of the movements.

And mayby thats good practice in general. To move a animated sprite arround, move a simple object and jump the sprite to its position, eventualy angle.

Secondly, because i think its more natural to open a chest only when the Hunter is facing it,

we need another way of dedecting this.

It also solves most of the problems with more chests opening because the Hunters bounding box is kinda big.

To do this i added an object that i called TheKey. It also just jumps to TheEye.

Another side-effect of dooing it all this way is : its so easy to debug. To see what exactly happens with your sprites and there connections. I left both, TheyEye and TheKey visible.

In the finished game both will be set invisible. But till then they are perfect debug instruments.

and here is the .cap

http://www.mediafire.com/?elbmjkmxzen

hoped to help

Cleansed.

run both caps

and see the differences

in your cap u can still open 2 boxes at the same time (probaly in mine too, but not that easy)

in your cap the hunter moves miles from the boxes when moving horizontal

in your cap you have to force the hunter to make BIG cirkels to get arround the boxes

in your cap it looks super 2d and flat

in your cap i can easly place 3 chests in a way that, althaught there is a way out, the hunter gets very stuck

My only target is to improve .caps and workflows

I am sorry if you take offense, its not intended by me

Jeswin and The Instance, to the rescue!

I'll try out the caps when I get home, but I probably won't be able to get any serious work done until this weekend (holidays tend to wreak havok on newspaper deadlines...).

I tried to explain to my boss that I'm learning how to use a program to make games, and that any of my peers would agree that it takes precidence over "real" work, but he wasn't convinced.

Thank you for the advice as well, Instance. I'm not sure if you can edit bounding boxes in Construct yet but it would be a great addition. When you're facing the front of the chest it would look much better if the top half of your character overlapped it.

Oh, and the sprites are just ripped from RMXP. I'm not all that concerned about how these test games look.

...and no, I take no offense whatsoever.

Cleansed.

When you're facing the front of the chest it would look much better if the top half of your character overlapped it.

Cleansed.

I hope I'm not fanning the flames, but TheInstance's example actually works very well. It fixes the problem where if you have a chest above you and to the side, or any other combination of two or more chests adjacent to you, all of them open.

I actually tried something similar to what he did back when Jeswin first helped out, but I messed up a few details and it didn't work quite right.

You can still trigger two chests at the same time if you are standing exactly in the middle of them, but as far as I can see that is the only remaining problem. I found out today that I'm going to have all of Saturday afternoon and Sunday evening off, so in addition to trying to fix that myself (although I very much appreciate the help, I really should stop asking for help whenever I run into a problem... ) I can get some more spriting work and begin a real demo.

(looks up to the heavens and calls out in a loud, strong voice)

Oh mighty Mod Powers that be, your humble servant requests that you lock this thread... lest we all suffer the wrath of Jeswin's growing annoyance with it!

The thread is fine! It's TheInstance -aka- j0h. He's usually a little hostile whether he means to be or not, but it doesn't matter. Point is, no need to lock.

As for solving opening two when you're right in the middle, may I suggest using an order system of sorts? Let's say you are at two chests which normally would both open, perhaps add a condition to open the one with a lesser X first, then the next one etc etc.

Other option is to use random with the existing conditions. Have Construct decide for you which to open first

EDIT: I'll go and clean up my posts above to be less intrusive.

I should not explain my motives so mutch .. but ...

I seem to be taken wrong so mutch ..

I am not really interrested in specific, isolated problems and in the solutions for them.

You never get a working system by solving each detail appart and isolated.

What i try to do is,

look at the isolated questions/problems, dig into them, and generate general rules,

starting from them.

I do this for myself, but can as wel *publish* my conclusions, and hope someone ads or takes from it.

You can read back, and see thats the case.

The cap that i made was just to illustrate. Nothing more nothing less.

And now allow me to dream a second. A few weeks ago i posted a .cap.

I really wish someone would look into it. And tell me why the T-blok is lagging. I cant find it !!

I really wish someone would tell me how i can make an event wait till the previous event has done moving its objects. Thats a big problem in that cap. And i illustrated that problem in many .caps

have a great weekend off.

Oh and, you can size the Thekey object to 1 pixel width, and separate the chests by 2 pixels. This will solve your problem totaly. TheKey is now 2 pixels, i think.