jed

Are these editable planes or primitives.

Apologies for my vague instructions - it was kinda late Dragging a field onto a node works for any node, and is quicker and more accurate than going through submenus - where items often have similar names

I don't use pose morph or set driver, but as I understand SD it just makes an XPresso tag with a range mapper with 1 to 1 correspondence. So my guess is to make an XP window, drag each pose tag in, for the driver pose drag the sliders to the RHS to make a port and ditto LHS of the driven pose. Then connect with wires. If both are 0-100% there shouldn't be a problem and a rangemapper won't be required. [ RHS of node is output, LHS is input ] might work...

Is this @Vertex Helix in the park ?

If you mean write data to user data from within Python, so it can be read from XPresso - make a null to hang your user data on, and create some data identify the null in python - SearchObject etc, and drag the data field into Python. This makes the correct syntax, but you may have to edit the text to suit. Here I'm writing True to a Bool - BTW the 2 in the code refers to this number try to use correct data types (bool, int etc) - XPresso allows mixing datatypes, but Python gets a bit picky sometimes.

I've got to admit, I'm a bit out of my depth with your type of button. I tend to use 'ordinary' user data buttons - like this button.c4d

I think this works - makes a list of nodes in the XP window, searches for a constant node by name, then writes a value. I used frame as dummy data. I find it easier to read + write to user data write2me.c4d code is from a reply in cg soc a while ago. you might be able to adapt it.

I think using a formula node and X group is a bit over the top

I'm not sure if replacing 'order=ROTATIONORDER_DEFAULT' with 'order=0' is correct. ROTATIONORDER_DEFAULT had a color that suggested reserved word ie correct syntax, but SDK says parameters order(int).

I might have fixed it by trial and error. I found a couple of Python outputs that should have been vector, but console was still borking at rotation order. I changed it from ROTATIONORDER_DEFAULT to order=0 and the yellows went away. MOCAM_R20v09.c4d well, things now move in the viewport...

@C4DS is a 'global' required in the code quoted above ? # construct a matrix from Position and Rotation, # input ports are Position and Rotation, output prt is NewMatrix import c4d def main(): NewMatrix = c4d.utils.HPBToMatrix(Rotation, order=ROTATIONORDER_DEFAULT) NewMatrix.off = Position  I also noticed a box 'TimingNodeStart' in the XGroups that doesn't seem connected

I see a lot of yellow Some Python troubleshooting tips - There's a log of python errors in menu > script > console. If you have several Python nodes, you should rename them Python 1, Python 2 etc to see which node the error message refers to. While XPresso is very forgiving when you mix data types (eg connect integer to string) Python is not. You should go through all the Python nodes and check port data types. If you hover the mouse over a port it shows the data type. This must match what the code is expecting. Here the code expects a vector but the port is real in this case you should double click the port to remove it and make a new one of type vector You can get info on unfamiliar functions using search at C4D Python SDK good luck !

@C4DS thanks

@C4DS a related question. What does -> mean ? I don't think I've seen it in Python, but have seen it elsewhere.

I use a oneshot monoflop to play sounds the sound doesn't render, but I've had some success recording 'what you hear' in C4D using Audacity, and adding it in After Effects.

@mabad thanks for comment. The soundtrack is Cubase - my new year's resolution is to stop using commercial music in clips.

You're welcome.

I've had trouble posting python scenes to members with older versions recently, so a description will have to do. In this scene I used GetTags() to get a list of tags from the object, then tags[0] to reference the actual tag by index. For the correct syntax for things like sliders, I find just dragging the field into the Python window works (with a bit of editing). Not sure if this works with your R15. def main(): global Output1 # for test length = Input1 # constraint length cube = doc.SearchObject('Cube') # obj with tag tags = cube.GetTags() # get all tags on obj constraint_tag = tags[0] # get 1st tag (or whatever) # drag field from attrib manager to get syntax # may need some editing constraint_tag[50004,9] = length # set constraint length Output1 = length # test

I can give you an explanation of the looney gears XPresso if you want - The 1st part generates rotation by addition (actually subtraction because I wanted it to go the opposite way). I get the rotation by adding a small amount to a variable once every frame. The amount added is effectively the speed. This method allows speed up + down smoothly (and backwards). The variable value is user data, and must be reset @ F0. If you use the usual multiplication method to get rotation angle = seconds * constant if you try to vary the speed by changing the constant, stuff jumps around, goes backwards etc. The looney gears needs fine control to get the numbers lined up For the cog math, I assumed the outer ring was a regular cog with the same teeth, so just get the different cogs rotation by teeth ratio. The regular epicyclic is the same, but a bit more complex because the planets have local rotation 'inside' the carrier rotation. Here's Mr Looney Gears himself on YouTube

So my intuition about error message 'line 1 position 11' was correct ? I just checked my messages from the original problem, and the guy says 'I watched your video and I tried the file. Alas, it doesn't seem to work for me when I loaded it up and put the two object references into the boxes, I move the slider but nothing happens I'm afraid. I'm using R16 at home, I don't know if that's why... I'll try again when I get to work tomorrow, where we have R20 ' It seems it was a R16 problem. I think we have been very fortunate in the past with C4D backwards compatibility. There's some changes with R20, but MAXON seem to try to keep problems to a minimum eg I recently fixed an old floor generator for a Cafe member to make it work in R20 - the only R20 difference was a couple of cloner ports had changed slightly. So the big question is - can I assume any Python scenes are OK to share back to R17 ? BTW, thanks for looking into this - hex editors are a bit beyond me...

@C4DS Here's the actual R20 file I sent to a Cafe member that started this story - see if you can find out what's going on. The compile error message says 'line 1 position 11' which is the end of the line. This can mean the error is in whatever follows. mover_R20.c4d I tried to recreate the problem with this file in R16 I still think it's PEBKAC ...

@C4DS I'm wondering if this is what they call PEBKAC - problem exists between keyboard and chair. Anyhow, I managed to reproduce the problem and not reproduce it ie 2 files, 2 different results - probably me doing something stupid...

I like to re-create crazy things I see online in C4D eg this prime number gear puzzle looney gears.c4d here's a more conventional epicyclic gear model epicyclic.c4d

Yeah - make new Python window, paste the text. Just deleting the 1st line 'import c4d' and re-typing it seems to work also.

I'd always assumed that Python code was fairly portable - it's just text, right ? Seems like it's not... I recently got a message 'thanks for the script, but it didn't work'. The guy was on an older version of C4D than me, and my bit of Python failed. I did a test with a file created in R20 that I attempted to open in R16, and got this This can be fixed by copy/paste the text into a new R16 Python window, or just deleting the 1st line 'import c4d' and rewriting it. R16 is Python 2.64, R20 is Python 2.7.14 and the difference is enough to break your scene. Makes me wonder how many 'bad' scenes I've given people in the past. You can get your version here - D'OH ! as Homer Simpson would say...