Clones

[Kjell]

As Ville is addressing the Scripting language, wouldn't it be useful to assign a Identifier ( int ) to each spawned Clone, and being able to access that Clone through a ZExpression using for example 21.Position.X ( 21 being the Identifier )? And while you're at it, don't forget the CollidedClone
property to accompany CollidedCategory

K

[jph_wacheski]

Yeah, some simple way of addressing the clones is definetly needed. I think the basics we need are two read only values;

count = number currently spawned (we can do this on spawn and destroy but it will be much easier if it is standard).

id = a unique number assigned to each clone,. this would be done every frame as the number of clones can change each frame.


bonus: the two functions I would be using often are;

clone_nearest(x,y,type);
clone_furthest(x,y,type);

again we can find these given the id and count but it would be nice to just have these standard functions,.

and yes the CollidedClone value will make many things possible,. with this additions ZGE will be much more scriptable,.

also, a simple way to address other instances would be very nice,. like a 'with' statment,. so; with obj_target position.x+=1; (all clones) or with obj_target.21 position.x+=1; (specific clone)

[Kjell]

Hmm, personally I'd prefer the Identity of Clones to be static ( indexing pointers to the objects in a single array ) instead of automatically changing when older Clones are destroyed. Also I'd rather not have clones categorized by Model type, since this makes it all the more difficult to set up your own organizing system ( groups / filters / layers ).

By the way, "with" is just a keyword GM uses to determine that code following that command concerns a instance. It's probably a mere sacrifice ( and a bad one in my book ) that had to be made since variables aren't explicitly defined.

K

[jph_wacheski]

Yeah, there are lots of ways to set this stuff up,. each has its +/-..,

So with static id what number does a new clone get when many have previously been destroyed ? and how do you search the array with missing numbers ??

The 'with' statement is just a way not to have to type model_name.whatever each time after you type 'with' once,. makes a load of sence when you are sending a bunch of value changes to the other object,. but sure is just a convinence,. . as far as explicit variables, I find it strange that a variable defined in the 'definintions' area are not localised., that makes more sence to me,. so I can use things like instance.power and not have to change my variable power for each instance,. .

[Kjell]

Hey jph,

You'd need a counter ( int ) to keep track of the index / marker used by the Spawned Clones per Scene. And the Array holding the data of the Clones shouldn't be accessible directly, I was just thinking in terms of Pascal.

Concerning GM and the "with" statement, I'm aware that you can use "with(object){}" in GML to address all spawned instances / clones of a object. This is perfectly fine, but covers only one of many concepts regarding organizing instances. When you have "groups" of clones consisting of various objects ( models in ZGE ) that you want all to change a value of, you'll need to iterate through your own array / group / filter / layer anyway.

K

[jph_wacheski]

the 'with' statment I'm talking about is just for script simplification; if I say

Code: Select all

with boom.21 {} 

then all stuff in curlys is refering to the 21st instance of model type boom, like the script resides on that model instance,. or it could be

Code: Select all

with boom {}

then it is all instances of the type boom,. and could include user defined "groups" like

Code: Select all

with boom."group" {}

etc. just a simplifer for typeing script,. more work in writing the interpiter but more speed when writing games.

yeah, you need a counter,. I am thinking of more than just on_collision for the id stuff,. like the nearest, furthest functions,. so you do need some way to get the id numbers, based on the counter,. ?

[Kjell]

Hey jph,

Again, personally I wouldn't track clones by type. So for example when you first Spawn five doors ( indices from 0 to 4 ) and then a window, the window would get id 5. The counter is only necessary internally.

For functions like nearest / furthest it's probably best to create a component instead. That way you can also return both the instance id and the distance. The problem of what selection to use remains though .. perhaps by default it would consider all of them, and optionally you could reference a array containing the indices of the clones you want to check.

Unfortunately ZExpression doesn't support integers ( nor strings ) as of yet

*A general ZExpression iterator could be useful though, something along the lines of PHP's foreach(), but as a simple for construct is missing still, that should have higher priority.

K

[VilleK]

Internally the model instances are only grouped per collision-category so we need more datastructures in the engine to quickly look up models by type, by id, by z-order etc.

I think it is powerful in GM to express things like "with all enemies do", but I agree other criteria would be useful too.

Interesting discussion here. There is definitely a need to query instanced models from expressions and one of my goals for the improvements I make to the scripting system is to make this possible.

[Kjell]

Hej Ville,

Just had a look at the source. .. which I should have done sooner ObjIds is a single dimensional Array you're storing the pointers in right? How / where / what kind of data structure are you using to store the instance / collision group combinations? Or are you just using the public property of the objects.

K

[VilleK]

The instances are in Application.Models which is a list of lists. Each list holds the instances of a specific category. ObjIds is a temporary structure only used during cloning, it is reset for each clone (see TZComponent.Clone-method).

[Kjell]

Hmm,

I see .. shouldn't the instances manager / registry be separate from the Collision categorization? I'm guessing the reason for going with this approach is because you weren't using the registry for anything else then Collision checking? Well, that and rendering .. which would explain why the rendering order is dependent on collision category ( when you'd just loop through the individual category lists )

Somehow I feel like if you do open up this area it would "require" for quite some additional aspects for it to function in a flexible fashion.

K