Create LIFE?
-
@baizuo (View Post)
I think you can't do LIFE_PGOL for life(pgol) :O
Also, you can use tpt.element("elem") to get IDs, use it for whatever. When strings were passed to element functions, I think that was what happened as well.
You could cheat around this withtpt.create("life", x, y)
tpt.set_property("ctype", "pgol", x, y) -
Oh! I didn't see that LIFE use ctype as identifier now :P
Thank you for your cheat help :)
-
The correct way to do this now is with the new api, although there is still no way to get the actual GoL types with an identifier right now. The real create function takes some extra value for the type, which are set to ctype for LIFE.
sim.partCreate(-1,x,y,elements.DEFAULT_PT_LIFE + bit.lshift(7,8))
where the 7 is the GoL type, 7 being PGOL. I'm sure some identifiers will be made for life types eventually.
-
Can't wait for the new APIs wiki!
By the way the code looks...ugly
Is there any way to make it feels more...object-oriented?
Things like
sim.partCreate(sim.MEANINGFUl_VARIABLE, x, y, elements.element("DEFAULT_PT_LIFE").lifeType("PGOL"))
I don't know much about programming and none offence :)
-
This functions go directly to the main simulation create function, unlike the others which had a bit of checking.
The first argument is what type of create it is, which in almost every situation you will want -1, which is how something like CLNE creates. -2 is from the user brush (changes ctype of some elements). -3 ignores pmap checks and will cause stacking. Anything >=0 will replace/create that particle ID.
And yes as I mentioned there is no nice way to get life types yet, which are 0-23, and will still probably need to be shifted and added to create them anyway.
-
So this is not really an API function, but a internal function right?
So glad that I don't have to handle LIFE now, waiting for update
