[Closed] Script Question (mainly for bobo)

hmm, well, it did link if i put the operatore in the source, but… still to no avail.

ok, here’s a sample file … ive created a sample scene also with 5x5x5 mapped boxes…

i was also hoping if you could give me your scene file so that I could try and see why its not working…

just post here if u encounter more problems, I’ll try my best to help

hmm, alrighty… messed with things, got a couple of errors.

first of all, what i did was set your array to fragments instead of boxes so taht it would apply to mymesh and it doesn’t like that.

heres what it does

1. all the bits get scrunched to down to 0,0 (or as close as they can) and the original shape is lost

2. get a birth script error

– Error occurred in i loop
– Frame:
– i: 125
– Unable to convert: undefined to type: Matrix

i messed around with blocks, they work fine, then what i did is i DOUBLED the amount of blocks, and guess what? i get the same error. so from what i can tell the script is essentially being overloaded and dies. i tried deleting about half my particles and voilia! they work! (although, they DO stillg et reset)

alright, figured out why it all collapsing, it has to do with your TM_reset, it starts out undefined andt hus its resetting everything. however, i DO see its use because its reseting the particles to their original positions. of course, i only need to do this once but still…

well, the way to solve the whole thing about all the particles not reseting, just run it through once (i had with with autokeyframe on, may not be necessary), then when your done, just tun the pflow off! simple as that. still question remains at why the pflow freaks out at more than 101 particles…

count part solved…

in this code of the script operator

on Proceed pCont do
(
count = pCont.NumParticles()
if count != 0 then
(
for i = 1 to count do
(
pCont.particleIndex = i
j = pcont.particleID
ChunksArray[j].Transform = pCont.particleTM
)
)
)

you had for i IN 1 to count do
change it to = and voila! it works. u should make this a plugin, its pretty cool.

hmm, unfortunetly it does NOT like spawning new particles fromt eh geometry ah well, thats something that ill just have to mess around with to see if i can get working… be cool tho.

i see…
about the TM_reset, this variable is responsible for resetting your transforms…
here’s how it goes…
when you first create a scene with fragments, the variable ChunksArray_TM is empty, it has no transform information stored in it… this variable is not the same as the ChunksArray…
ChunksArray: this is the collection of object fragments the we manipulate.
ChunksArray_TM: this is thier transform information (position, scale, rotation)

so say I created a set of boxes…
we now turn on pflow, you noticed that we have a script operator in our global, topmost event.
there is a line there stating this:

count = pCont.NumParticles()
 if count != 0 then

initially, if it were to count the particles, there would be none, so it won’t evaluate the script because the particle count is initially zero (at the start of the frame). so this is basically unfuncitonal at the start…
now, this is where the birthscript comes in… this is what gets evaluated at the start of the flow.

• so starting off, first we get the array or collection of objects and store it to ChunksArray.
  global ChunksArray = $Fragment_* as array

• then we also set another variable as global (this is so that it could be read from anywhere)
  global TM_Reset

• this next line will check if there were chunks collected
  if ChunksArray != undefined do
  (

• so at the start, we defined the global TM_Reset just as is… so right now, it is UNDEFINED

• this next line will check if it is UNDEFINED, if it is, then we set a new value to it, which is the value TRUE.
  if TM_Reset == undefined do TM_Reset = true

• now that TM_reset has the value TRUE, this next line will evaluate:
  if TM_Reset do
  (

• this line will create a new global variable for ChunksArray_TM… and it contains the transform information (the initial transform information) of each chunk.
  Global ChunksArray_TM = for i in ChunksArray collect i.transform

• and lastly, we set the variable TM_Reset to false…
  TM_Reset = false
  )

• the reason is simple, its only because we wouldnt want to overwrite the initial (starting) transform information data everytime we slide back up to frame zero.

so now what we have are:
ChunksArray, with all the fragments, or boxes etc… in it
TM_reset is now false
and
ChunksArray_TM is now defined and is theoretically locked because of TM_reset being false.

the script will now work with these values…

now comes a time where you’d want to add fragments…
if we add fragments:

1. go to frame 0, and the birthscript will evalute, getting the new fragments and storing it inside ChunksArray.
2. TM_reset is still false so this block of codes wont evalute::sad:
   if TM_Reset do
   (
   Global ChunksArray_TM = for i in ChunksArray collect i.transform
   TM_Reset = false
   )
3. this will be the cause of chunks going crazy. basically because the data from the ChunksArray_TM is old, it is not updated, it has no transform info from the new ChunksArray collection…
4. the way to fix this is, go to the listener and type in TM_Reset = Undefined…
   this way these lines will evaluate accoridngly:
   if TM_Reset == undefined do TM_Reset = true
   if TM_Reset do
   (
   Global ChunksArray_TM = for i in ChunksArray collect i.transform
   TM_Reset = false
   )

thats just it i suppose… whenever you want to add fragments, just make sure you reset the Transform information in ChunksArray_TM by setting the TM_reset to undefined…
this also goes with assigning new framents or boxes etc…

whew… i hope this helps! (i hope im getting better at explaining stuff… hehehe)

hehe, hmm… im not particularly sure about the “in” and the “=” being any different. although I usually use “in” in my for loops. I wonder… i’ll try and test some later.

im also doing the same thing, setting the playback to a non-realtime mode thus turning animate button on, so that we’d get keys animated for our chunks! hehe.

perhaps the “in” is a type of variable which has a set numerical limit (probably defined by how many verticies, considering the max particles i could do before it crashes was 100 compared to your 125 blocks).

sorta like the difference between an integer in c++ and a float or long.