A feature tweek request for the developers.

Discussion and feedback on Construct 2

Post » Thu Jul 03, 2014 8:02 pm

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.
B
11
S
4
G
1
Posts: 159
Reputation: 1,803

Post » Fri Jul 04, 2014 1:16 am

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?).
A big fan of JavaScript.
B
76
S
20
G
76
Posts: 2,285
Reputation: 47,554

Post » Fri Jul 04, 2014 1:34 am

@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.
B
92
S
18
G
9
Posts: 2,455
Reputation: 15,113

Post » Fri Jul 04, 2014 2:01 am

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!
A big fan of JavaScript.
B
76
S
20
G
76
Posts: 2,285
Reputation: 47,554

Post » Mon Jul 07, 2014 1:53 pm

@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?
B
11
S
4
G
1
Posts: 159
Reputation: 1,803

Post » Mon Jul 07, 2014 4:44 pm

I need to go to abbreviation school! :)
A big fan of JavaScript.
B
76
S
20
G
76
Posts: 2,285
Reputation: 47,554

Post » Tue Jul 08, 2014 1:45 pm

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.
B
11
S
4
G
1
Posts: 159
Reputation: 1,803

Post » Tue Jul 08, 2014 5:19 pm

@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.
ImageImageImageImage
B
62
S
19
G
51
Posts: 633
Reputation: 30,836

Post » Wed Jul 09, 2014 6:31 pm

Yttermayn wrote: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.
B
46
S
20
G
9
Posts: 545
Reputation: 9,315

Post » Wed Jul 09, 2014 7:06 pm

@DatapawWolf @humanescape Thanks, folks. Looks like I'll be going that way as well.
B
11
S
4
G
1
Posts: 159
Reputation: 1,803


Return to Construct 2 General

Who is online

Users browsing this forum: Yahoo [Bot] and 9 guests