I've added my Baddie's movement here of what I mean for you guys can see.
Anyone who wants to use it feel free. It's pretty much just DavidN's platform tutorial with a bit of added AI.
But yeah if you just grab another baddie and place it in the level you'll see what I mean about it stuffing up.
I've also added the fire balls level of what we were talking about in case anyone else needs the same thing. Just one thing, I can't figure out how to make a fire ball shoot up randomly between 3 and 6 seconds. So if anyone knows how please let me know or just fill it in.
Axel, if you want to add the events you were talking about into this example you're more than welcome.
Okay, here's why your example file isn't working properly:
- The number of loops is being determined by the alterable value of one of your enemies. Just one. The last one placed, I believe. This means that if that one enemy has a Gravity value of 1, the other enemy won't be moving very far.
- You're stopping the loop once the enemy hits an obstacle. Since there's only one loop going for all of your enemies, this stops everyone's movement once anyone hits a wall or floor.
- You can't use a detector like that for the enemy unless you want to go through the trouble of spreading values and running fastloops to get that detector to work for every single enemy.
Anyway, those are the things I noticed. I'd say ditch the detector, make the gravity loop run a set number of times each time, and give the enemies an additional gravity value that's assigned before the loop is initialized and that depletes with every loop step.
I know it's late to be replying to this forum (since October last year) but I was just wondering if Axel ever did end up making that example file. I really need it so I can figure out the A.I. for my baddies.
Otherwise, if there anyone here who is a master at platform AI?
Basically I need a baddie with gravity who shoots when close. I know how to do the shooting when close part. But I can't place anymore than 1 baddie because I don't know how to run 1 fast loop that covers all the baddie placed in the level. Have a look at my example: http://eyeangle.sitesled.com/baddie_movement.zip - 15.39KB and you'll see what I mean.
Heh, sorry, I must've forgotten about this thread. But I'm quite sure I posted an example file just like that in another thread. I'll have a look on my webspace and see if I can find it...
Edit: Meh, I just remembered: I did a major cleanup a few weeks ago, removing most of the stuff I had on my webspace. The example, if I ever made it, probably went along with the rest of all the crap I had there. Nevermind that though, I'll download your engine and see what I can do.
I've been trying to find a good substitute for this whole "you need an index value to iterate through objects", since in TGF you only get 3 of those total. To be exact, I've been trying to figure out exactly why:
+Always
=Object: Set Flag 1 Off
=Loop: Start Loop 1 for (Number of "Object") Loops
+Loop: On Loop #1
+Object: Flag 1 is off
+Object: Pick an "Object" at random
=Object: Set Flag 1 On
=Object: Set Flag 2 On
+Loop: On Loop #1
+Object: Flag 2 is on
=(INSERT CODE HERE)
+Loop: On Loop #1
+Object: Flag 2 is on
=Object: Set Flag 2 off
theoretically, this should always pick one of the remaining objects and thus iterate through them, however for some reason when used in TGF, it will only refer to the very last created object, as if it were a dumb "always" event, with no iteration.
I've discovered that klik pretty much just sucks for multiple condition events concerning objects that have multiple instances. I usually do something like this for each event:
>Always
-set val A to 0 // val A keeps track of individual conditions for an event. For each condition that is true in the event block, add 1 to value A. If value A = the sum of the conditions at the end, execute that event's actions with that object.
> // condition 1
- add 1 to val A
> // condition 2
- add 1 to val A
...
> if val A = (sum of conditions)
-perform actions with object.
// repeat for different events (divide them into similar event blocks, all reseting the objects' val A to 0 first)
it takes several event lines to do this, but it will work. This is why scripting > klik.
I know it sucks, but it does so with very odd rules, and even after like a decade of beating it with a stick, I am yet to master all of its secrets. Its like trying to program in Malbolge sometimes.
The general rule is- given any single event, it starts off with by default ALL copies of an object selected.
So if you do this code:
*ALWAYS:
=Destroy Object
it will destroy EVERY copy of that object
however, what it seems to do is read top to bottom through the event conditions, and narrow the selected objects by that criterion. So for example;
*ALWAYS
+Object Flag 1 is off
+Object Value A = 0
=Destroy Object
it will first take ALL objects (always is non-specific)
then it will take only the remaining objects with flag 1 is off
then it will narrow those down to the ones with A = 0
so overall only the objects with BOTH Flag 1 on, and Value 1 = 0 will be destroyed.
However, I'm yet to figure out alot of the nuances, like how the "Pick an object at random" really works.
If I take that code outside of a loop, and instead modify it to run every X frames, for example:
*COUNTER = 0
=SET COUNTER TO (NUMBER OF OBJECTS)
=SET OBJECT FLAG 0 OFF
*COUNTER > 0
+OBJECT FLAG 0 IS OFF
+PICK AN OBJECT AT RANDOM
=SUB 1 TO COUNTER
=SET OBJECT FLAG 0 ON
=SET OBJECT FLAG 1 ON
*OBJECT FLAG 1 IS ON
=SET OBJECT POSX to (OBJECT POSX + 1)
=SET OBJECT FLAG 1 OFF
this will work as intended; the objects, regardless of how many there are, will move along at a uniform rate, although a little awkwardly so since they will take turns moving forward one step. However, they will always be within 1 pixel of each other. Hence it works EXACTLY as intended.
For all I can tell, what this is means is that somehow, the fastloop object in TGF completely screws up the "Pick an object at random" command, be it called from an object or called directly from the global.
I think the whole 'multiple conditioning arguments for multiple instances of an object' as you put it, is probably the #1 turnoff I've seen for newbies trying out click. Its extremely poorly set up for iterating through objects like a normal programming language does, and since the event stack and all that is basically a whole bunch of hocus pocus completely hidden from the programmer by the editor, it makes it very tough to explain to people. I dunno how many times I've seen questions like "how do I make more then one enemy respond to my event"
only problem for them is that if they're really serious about making some advanced games later on, they're going to have to learn all the "hocus-pocus." (i.o.w. study programming languages and experiment with the MMF's engine) That's why I became a wizard.
Yeah I've studied enough programming languages that I understand most of it, but several parts of TGF/MMF might as well be done by gremlins in my computer. Its sometimes impossible to predict how some things will work; for example why would my code properly pick objects outside of a loop but not function inside of a loop? Theres alot iffy parts like that, added to the lack of support for memory allocation (I get a set amount of variables to store in each object? *great*), and pisspoor iteration (I'd kill for a .getIterator command, or built in N-dimension arrays), it really stops it from being a 'professional' language. I just happen to like beating it with a stick, since while it might be more *difficult*, it sure does take less *time* then its counterparts.
Yeah, I've never had a problem with it outside of loops, but I just tested it with looks and it goes all screwy.
The pick one at random event is one of the most useful conditions in TGF, if used right (as in, you're not using to pick something randomly). Be warned, it doesn't like working with groups though.
Advertisement
Post Reply
Edited by the Author.
Edited by the Author.
