ZFGC
Resources => Coding => Topic started by: legendarylugi on January 05, 2009, 04:38:13 am
-
The title says most of it. XD
In GML, I'm trying to make it so if a cursor is in a given position, and you press a direction key, it jumps to a designated position.
But where it jumps to needs to be based on the object's current position. I tried having it Check Object and then Jump to Position, but that doesn't work (and I wouldn't expect it to).
So is there a function for "If object is at a given position, perform the next action," or something similar? I'm sure the answer is incredibly obvious, but for some reason it eludes me.
-
object.x
object.y
and then your code for it... If this.x == object.x blah blah pseudocode blah blah
O_O
-
"If object is at a given position, perform the next action,"
if (object.x==x && object.y==y)
{
}
Be more specific mamo O:
-
Perhaps I am thinking about this wrong, but the user who posted this topic might be referring specifically to the drag & drop actions rather than the GML code itself.
Does your code look similar to this?
(http://i8.photobucket.com/albums/a13/4Sword/ddcode.png)
Otherwise, it would seem odd to me why the built-in function instance_position(x,y,obj) would not work.
It might be depended on where you are checking the code at - in terms of the event.
-
Actually, 4sword, I tried using both GML and drag-and-drop. But yes, the drag-and-drop version did look like what you said, and then when I opted to script it instead, I couldn't find appropriate functions.
I knew near the start that Check Object wouldn't work, because it checks if there is an object at a position, rather than checking the position of the object...I just tried it because I didn't have another solution. You still gave me some very good advice. I'll try instance_position and then try what mam and AoDC said.
So thanks very much everyone, for your help. It should work now. XD
-
I checked and Check Object translates to position_meeting while instance_position is it's own function. What AoDC said is probably the same thing as what the function I gave does. But honestly, I don't know if what I said will really work.
-
Okay, so how do I look up an equivalent GML function for a drag-and-drop function?
For instance, the Jump to Position function, how do I find the GML equivalent? Because it seems it's called something else in GML.
-
There is an old program which does this, it was made by Xception from the GMC. It's in the attachment. Some of the functions may be depreciated as that was from around GM version 5. A lot of it is still relevant.
-
Wow, that's incredibly useful...and it works! I finally have it working. XD
-
Late, but here is a D&D -> GML reference guide for GM7:
http://gmc.yoyogames.com/index.php?showtopic=334704
HTML: http://www.blackratstudios.com/games/DD_to_GML_7/Drag_and_Drop_Icons_and_their_GML_Equals_Ver_7.html
DirectLink: http://www.blackratstudios.com/games/dd_icons_to_gml_Ver_7.zip
-
Okay, I have another question.
I've actually gotten quite a bit done since I got past that little snag, so I'd like to thank everybody again. But now I have another one.
I'm working on a banking system, and a functional(ish) version is almost complete.
I just need to know how to make it so when you collect rupees (or withdraw/deposit them in the bank), rather than just setting the value of your wallet, for it to gradually add to it (or take from it), like in the games. For instance, when you get a red rupee, rather than just adding 20 to the value, how do I get it to add one at a time?
-
The first solution that came to my mind and would be easy would be for something in a step event to where you had two variables for rupees - a rupee count and a rupee show. The shown value would be used by the HUD whatever that is showing the amount while the count would be the actual number. In a step event, you could have a condition check whether or not the count matched the shown and then increment/decrement the shown by a fixed number until it matched the actual count.
In a step event, it would look like this:
if (rupee_shown > rupee_count)
{
rupee_shown -= 1;
}
else if (rupee_shown < rupee_count)
{
rupee_shown += 1;
}
Each step, the value would be augmented until it matched, and the value of 1 I used could be changed to alter the speed of the change.
There might be another way to do it, but meh.
-
^^^That could work. XD Whatever the case, I like the idea of rewriting the code to be placed into the step event.
Perhaps make a variable called "worth" that has the value of the given rupee being collided with, and for every step subtract 1 from worth and add 1 to rupees, until worth is at 0? So everytime he collides with a rupee, it sets worth relative to itself, then in the step event starts shaving it back off into the wallet.
Well that sure was simple. :) I'll test it out right now.
EDIT: If it works, it will simplify the code a lot. Before I had to write a separate script for each rupee, now I can just right one that covers all types.
-
Your idea is also somewhat feasible, but the rupee needs to go away once it is collided with. This usually just involves removing the instance of that rupee. Then, that "shaving" really couldn't happen.
As for how multiple rupee values are to be handled, there are two ways I can think of to do that. One would be to have one rupee object that draws based on its worth, with it's worth immediately going to zero and the incrementation of the rupee count working under what I said to do.
The way it could work for you would be to a base rupee be a parent of all other rupees. In children of the parent, the collision events are inherited, and the only thing that would have to be different in each child would be the sprite of the rupee itself and the rupee worth.
-
^^^Oh, I don't need help with rupee increments, I already had that covered.
I was just saying that before, with the method I was using, I had a seperate "duplicate" script for each rupee, but now I only need one of it.
I guess you're right about "shaving" values into it, since there's no longer an object to run the script. I didn't think of that. (hits self in head). Hmmm, maybe I could put the script under LINK's step event, and set it to "other", so the Rupee is the one affected?
-
It would probably be more efficient under my method then; the rupee_shown and the rupee_count. And for all intensive purposes, having the rupee objects as one base parent object with children objects would be best. This is because the collision events are inherited and code itself doesn't have to be rewritten.
I should have probably made rupee_count in my example a global variable - i.e. global.rupee_count. This is so interaction with other objects outside of the HUD would be easier. The collision event defined in the parent base object of the rupee would just alter the global.rupee_count variable and then destroy the rupee object.
It's also a bad idea to load code into Link. Other objects harboring the code for things pertinent to them makes more sense then using "other" a lot.
-
It would probably be more efficient under my method then; the rupee_shown and the rupee_count. And for all intensive purposes, having the rupee objects as one base parent object with children objects would be best. This is because the collision events are inherited and code itself doesn't have to be rewritten.
Alright, I'll do that then. ;) I'm a newbie, so I have no reason to be stubborn. :P
It's also a bad idea to load code into Link. Other objects harboring the code for things pertinent to them makes more sense then using "other" a lot.
Yeah, I realize that it would basically mean the game was running unneccessary code at every step and eventually slowing things way down, but I guess it just sounded easier to give it to Link for now. But like I said, I'll try it how you said.
-
Well, I ended up doing it the way I originally said I would, so I guess I'm stubborn after all. :P
But I tweaked it to a less terrible and noobish form. So it's no longer under Link's step event, it's under the control object that draws the HUD and such.
BTW, I think you slightly misunderstood me about the rupees. I said that in an earlier form it required me to write separate scripts for each rupee, but once I got some inspiration from this thread, I realized how to make one that would work for all of them. So I don't need a parent rupee to get the other rupees to do what I want.
Unless of course you were suggesting the parent rupee for another reason.
-
Meh, I would think that the rupees would stay too long your way, when they should go away upon collision.
As for its location outside of Link's step event, that's good that it is in the control object.
I do not know what you mean by scripts; I know what a script is, but the way you are using the word is throwing me off. I get that if you write some code that decrements or whatever, that that code can apply to all rupees. What I do not know if you are doing is if you have multiple rupee objects, does each one have the same lines of code in their collision events?
By having a parent rupee object which defines the collision event for itself, you could have rupee objects of which there would be no code needed or written, other than the value of the different rupee in the create event of each. It's a lot more efficient.
You do know what I mean when I mention parent objects, right?
-
It sounds like he just has one rupee class that represents all types of rupees by using a variable to distinguish between which type a specific instance represents. It's actually more efficient than what you suggested 4Sword.
My guess is he's randomly picking which type the instance to be and setting the texture accordingly or he's just doing it in some script that spawns them.
-
I mentioned previously in this topic having a single rupee object that based what type of rupee it was on by its "worth" and then having its sprite be determined in the draw event. However, if you decrement the "worth" of the rupee with what I just mentioned, the rupee will change colors, and this is not what you would want. You could make it invisible before it destroys itself, but then it would still be running collision events; which might make it look like the rupee doesn't stay that long by increasing the number of collisions as the rupee itself isn't solid.
Another problem with that is that you have to assign a value to a rupee once it is created which involves more code. If this were C++, there would be an argument to the constructor to do this, but in Game Maker, you would have to set the code immediately after creating the rupee.
It's a lot less work to have a parent rupee as then all children are essentially empty except for the field where the parent rupee is declared as the child's parent. And really, my original way of doing it with a rupee_count/rupee_shown with that would be the best solution in my opinion. And this isn't really about the rupee spawning so much as it is about the rupee incrementation/decrementation to the number of rupees you have.
Perhaps there is something in what you are saying that I am missing.
Edit:
I thought about it a little more. If you had one rupee represent all rupee worths and you did not decrement from the worth of rupee incrementally to add to the rupee count, then that would work. Rupees are mostly generated due to the death or destruction of things, thus the rupee is created after before that death and destruction line in the code. Sometimes, the value assigned is not always the same for the same thing destroyed (like getting one or a five value rupee) and that is determined through probability.
Meh, the way I see it, the parent-child relationship avoids the decision statement in the draw event and saves a line of code, but meh.
-
I guess we have somewhat misunderstood eachother. :P
Okay, so to clarify what I'm doing, here's what I mean.
Okay, so right now I have a separate object for each rupee-type (for now, but that's subject to change), but the only thing they do is upon collision, set "worth" relative to ____ (whatever the rupee is), and then run "collect_script_B", which basically just tells it that if your wallet can hold at least part of the value of the rupee, destroy it, otherwise don't collect it.
The HUD object runs "collect_script_A" in the step event, which just tells it to add the rupees one at a time, subtract from worth one at a time, and play the rupee_get sound, until worth equals zero. Or, if your wallet is full, set worth to zero. So far it's working just fine.
So I don't get what you mean about the object not being immediately destroyed after collision. It's destroyed instantly.
-
Can I see your GMK file?
-
^^^I would love to show you my .gmk, but it's a little messy right now. I need to clean it up a bit first. :P
Anyways, I think we're getting bogged down on what ultimately, are miniscule differences of approach. What you would have done, and what I did, are all but identical, using the difference between 2 variables (one for the rupees and one extra variable) to mark how many rupees to add, one per step, with each type of rupee it's own object, but essentially "empty" except for marking the value of the rupee (and in my case running the script that would be run by the parent in yours).
The only difference, the ONLY difference that I see, is that your extra variable was the current rupees plus the rupees gotten, so adding to the rupees to your wallet until they reached that point, whereas my extra variable was just the value of the rupee you collided with, added one at a time to your wallet and removed one at a time for this second variable. Basically the same thing.
As for the rupees, like you I have multiple rupee objects, the only difference was that I didn't create a parent object for them, since the collision event, the only event they had, and the only thing that would have been in the parent in the first place, was different for each of them (added a different value to the worth variable), so a parent served no purpose the way I did it.
Like I said, the differences are a lot smaller than they're being made out to be.
EDIT: But now that I think about it, your way would be a bit simpler, because rather than having to change the values of 2 variables to add to the rupees, your way would only have to change one. So I think, yes, I will change it. ;)
-
lol, yeah my code gets messy a lot too; I also have the tendency to stop working on code if I dislike the way it looks in terms of variable names, structure, etc.
But as for the rupees, in Zelda games, there are a few values for the rupees themselves; a one, five, ten, twenty, etc. Saying you had just those first four, that would mean that you have four rupees, all with collision event code. If the collision event involves a function call, such as there is a script that is executed, then at least then the code would not be written more than once. While it isn't much to say, the purpose of most scripts is similar code with different passed in arguments.
If you had a parent rupee and then children rupees, it would be different. The parent object would define the variable for the rupee's worth as well as it would have the collision event defined. The children rupees would have no code at all other than an event_inherited() call in the creation event and a statement setting the worth of the rupee to a value.
So meh, instead of having four rupees all with collision code of their own or having four rupees with a function call to a script that had no arguments, you would have a parent rupee that defines everything, and smaller child rupee objects that save space by needing less code themselves. Meh, it's not the only way to do it, but for me, it would be the better practice. It probably sounds a little miniscule, but it adds up with the more similar objects you have.
-
^^^Ah, I see, that makes sense. I think I will do that, create a parent object for them. But I think I'll keep the rest as it is, using a worth variable to set the number of rupees to add.
BTW, how do I upload a .gmk to my posts?
Basically, I cleaned out the file, removed any unneccessary junk, and then took out everything to do with the banking part (withdrawing, depositing), keeping in only Link and the ability to get rupees...since I don't want to upload the banking part till it's finished.
Lol, now that it's all cleaned up, I realize that outside of the bank, when it comes to just collecting rupees, I've coded practically nothing. :P
-
I usually just create a .zip or a .rar file on my computer, open in up, add the GMK into that, and then go to the forum, go to make a post, click additional options before posting, and then attach the .zip or the .rar file.
-
Okay, I'll be right back with it. ;)
EDIT: Okay, it's just a very, very basic version. Press the F key to upgrade your wallet, press the arrow keys to move "Link" around (yes, his movement is preschooler level), and collide with rupees to collect them. Make sure you have the sound turned on, because an important part is the collect_snd.
I realize that I made a few of the variables global when they probably didn't need to be, but I just did that for now so I didn't have to think about it as much.
-
Here is a file with some things changed. Namely, I implemented the parent rupee object with its children, changed the resource names to the more appropriate Hungarian prefixes, implemented the rupee variables, altered up some of the Link code to make it more efficient, etc. I realize that you were using drag & drop a bit with scripts, but yeah, using the execute code found under the control tab lets you run your own code. Sometimes drag and drop does more than it needs to; e.g. setting the sprite, in your example, you just needed to change the index and you didn't have to redeclare what the sprite was.
I also put the rupee_shown/global.rupee_count check in the draw event just for simplicity. Mostly the draw event should just draw and not run code, but it still happens before the number is drawn so it is alright.
A few key things beyond all that, the global.rupee_max is altered when you upgrade you wallet. In the collision event for objRupeeParent, the global.rupee_count is altered by the smaller of the two values - them being the global.rupee_max or the global.rupee_count + worth. Basically, if the increment to the global.rupee_count is greater than the global.rupee_max, the global.rupee_count will equal just the global.rupee_max. This prevents you from exceeding the max if you are at it, or if you are like 5 under it and get a 20, it sets it to the max then. I actually learned this way of doing it from someone else.
But yeah, it's in the attachment. Attachment removed and reuploaded in next post.
-
Lol, don't worry about fixing "Link" 's movement, he was only in there to have something to collide with the rupees, nothing more than that...if it were a walking engine I would have put much more thought into him.
Anyways, I can't really check what you did, since I don't have a .rar opener on my computer. :-\ Could you maybe upload it as a .zip?
-
Meh, it seems the WinRAR made it into a rar, when other archives I made using WinRAR were compatible zip. Anyway, I think I might be able to just upload it without that, lol, silly me.
-
I really like your version, it does seem "smaller", more efficient. The only problem I have with it is the sndCollect no longer loops appropriately...that and the fact that I don't know what certain things, like cases are...but I can sort of infer what they are from the context.
-
That "problem" is easy to fix. Just remove the code about playing the rupee collect sound from the rupee collision and put it into the code inside the objControl for when the rupee_shown is altered positively.
And cases, or select-case statements are a quick way of doing if-else. For example:
switch (wallet)
{
case 2: global.rupee_max = 200; break;
case 3: global.rupee_max = 500; break;
case 4: global.rupee_max = 500000; break;
}
is equivalent to:
if (wallet == 2)
{
global.rupee_max = 200;
}
else if (wallet == 3)
{
global.rupee_max = 500;
}
else if (wallet == 4)
{
global.rupee_max = 500000;
}
-
^^^Thank you very much for showing me that. XD
EDIT: BTW, I realize that the looping of the rupee sound is actually kind of annoying right now, so I will try to fix that.