A feature tweek request for the developers.

When you use create object to create a family object, you get a random member of that family. I request that make it non-random by using an optional variable that will be treated as an index to the specific family member you want. If the variable is left null, then you get random selection still, so we don't mess up projects that utilize this random decision.

This would allow greater flexibility in projects that do a lot of procedural generation, along with I'm sure many other applications.

Example:

One of my projects does a lot of generating and destroying of enemy mobs. All the different types of mobs have lots of instance variables and behaviors they inherit from a common mobs family. When a map is saved (not a whole game save), the save routine has to record into an array all that data for each mob. The load routine has to then recreate those mobs from the saved data when the map is loaded back up. With the create object action as it currently is, there will have to be a create object action and associated supporting lines for each member of the mobs family. With a new variable, there would be just one create object action with a value for the family member index.

I would like to see this implemented by friday.

(jk)

I will be ponderously working around this problem, but I thought it might be useful for other users and future projects.

Thanks.

Your post includes the solution to your problem. Add a family variable to mobs family and assign a unique numerical value to each member of that family. When you save state, include the variable number in the save and then, when you want to recreate the correct member of the family, reference the variable to control which particular instance to create.

I think your demand to have it done by tomorrow is just daft, but I bet you could do this yourself by then (or is this a joke?).

Colludium

Your right. Unfortunatally. Your using a switch state system to create an object. However part of the problem with this design is variable association and large duplicatio of code. Since you can't reference the newly created object by it's Family UID until after the first tick. So

OnFunction.Create(TypeX)

if(param0)

Create ObjectTypeA

objectType.var1 = qwe

objectType.var2 = asd

objectType.var3 = zcv

objectType.var4 = tyu

objectType.var5 = ghj

if(param1)

Create ObjectTypeB

objectType.var1 = qwe

objectType.var2 = asd

objectType.var3 = zcv

objectType.var4 = tyu

objectType.var5 = ghj

if(param2)

Create ObjectTypeC

objectTypeC.var1 = qwe

objectTypeC.var2 = asd

objectTypeC.var3 = zcv

objectTypeC.var4 = tyu

objectTypeC.var5 = ghj

if(param3)

Create ObjectTypeD

objectTypeD.var1 = qwe

objectTypeD.var2 = asd

objectTypeD.var3 = zcv

objectTypeD.var4 = tyu

objectTypeD.var5 = ghj

Now imagine 20 of those. Possibly even with more customized paramater information. This is an attrocase horrible disgusting way to design a switch state creation. Why because you can't access the Family version of the object unteril after the first tick. And you might need to access by way of first tick. Instead a good design.

OnFunction.Create("type")

Family.Type = param0

System.Create(Family)

Family.var = qwer

Family.var = asd

.....

and that's it. That would have 20 family objects, 30 family objects. 1000 famiy objects... ok 1000 is far past excesive.

An alternative is to just make sure we can access the object by it's family ASAP rather than waiting a tick

OnFunction.Create("type")

if(param0 = type) Create Type....A

if(param0 = type) Create Type....B

if(param0 = type) Create Type....C

if(param0 = type) Create Type....D

if(param0 = type) Create Type....E

if(param0 = type) Create Type....F

if(param0 = type) Create Type....G

if(param0 = type) Create Type....H

... and then after alll those ifstatements

Family.var = qwer

Family.var = asd

.....

As it is. It kinda sucks for dynamic object creation. However there is a plugin to do what is requested. Also in the mean time. Just avoid this kind of object family creation.

Yes jayderyu, I see what you mean. I have always used On Created to control setting instance variables to minimize that sort of code repetition, but I can see how that it won't work in all situations.

Yttermayn, I withdraw my 'helpful' comment!

Colludium Lol, no problem. And yes, that was a joke- with the joke tag (jk). If you just spell out "joke", folks don't get spun up enough to get funny.

jayderyu Thankyou for the well thought out reply. Unfortunately, I'm only understanding about a third of what you are saying. I get that in your first example (atrocious, horrible, disgusting!), that we would have a function set up that would take the variable and create an object, chosen by that variable, then fill in all the appropriate instance variables.

For your last two examples, why do we need to set values of common family variables? Aren't the newly created objects inheriting those values from the family's set?

Note: regardless of how they are created, each mob type will have to have the values specific to that type set in it's own "on created" block. Does this help, or make it more confusing?

I need to go to abbreviation school!

Ok, so it kind of sounds like I might have to do something like this: All MOBS are actually just one object. The dungeon generator/mob spawner will spawn a "generic" mob and set some kind of mob index variable. An "on object created" event will then tweek the generic mob's stats, animation set, and sound set according to the "mob index" value to make a particular type of mob out of it.

Anybody see any pitfalls in this approach? I am pretty sure you can select animation sets by number, but I haven't worked with sound much yet.

Yttermayn, I've used a similar approach, and done exactly what you said, using either variables or their own animation string to determine what is what, and therefore how it should behave. I can't advise you about families, because I've yet to have a use for them, but I can tell you that your approach should work just fine, from what I can see.

Ok, so it kind of sounds like I might have to do something like this: All MOBS are actually just one object. The dungeon generator/mob spawner will spawn a "generic" mob and set some kind of mob index variable. An "on object created" event will then tweek the generic mob's stats, animation set, and sound set according to the "mob index" value to make a particular type of mob out of it.

Anybody see any pitfalls in this approach? I am pretty sure you can select animation sets by number, but I haven't worked with sound much yet.

This is the route I usually go.

I tried families a couples times but go back to making something else similar to what you mention. It works and thats good in my books.

DatapawWolf — Thanks, folks. Looks like I'll be going that way as well.