MighT

The frames on which the number changes (or when you are freezing the number) change in your code. It has noting to do with the actual numbers shown. Simply uncomment your "print my_list" and select a few objects in Object Manager or do other things. As long as time is at frame zero, the list will be rebuilt and thus change all the time.

I don't think, you got the point. In C4D every randomness is stable. Nobody wants a render to change, just by rendering it twice. If you render frame 42 of an animation. Restart C4D and render frame 42 again, you'd expect an identical result. So, no, it's not a matter of "how random do you want this to be". In your example the result will change, just by hitting render twice. It will even change, just by changing the selection in the OM... In regards to performance: a) I did not compare Xpresso to Python. I only mentioned the inefficient use of a list in Python. b) It's not the construction of the list, that's inefficient, but the lookup. c) I mentioned, it won't matter much in this case. But I thought, this would all be about learning. And adding just enough small inefficiencies in one scene/script/program can make a big difference in the end.

Thanks for making me aware of the Freeze node. Never noticed it. It makes the "blue" part of my Xpresso setup a bit easier. The problem I see with the given Python solution: It's not stable. With every new playback (actually every change to the scene while on frame zero, the number will change on different frames. The fix is easy, just initialize Python's random module properly by inserting the following line: ... # make list of frames when output changes if frame == 0: my_list = [0] random.seed(42) ### Init random module for a in range(1, 500): # number of value changes ... One more note: Though not really relevant in this case, using a list like this seems a bit inefficient. A dict should perform better, especially for the lookup.

Here's a little something: test_random_float_text.c4d I have added a bunch of result nodes, so the principle is hopefully not too difficult to comprehend. It could certainly be improved in many ways. Currently it uses a probability for the change, which may violate your 5-10 frames requirement. Or one could add a parameter for the number of digits. Or... The Xpresso setup: I just realize, I used the term "Edge Detection". This has nothing to do with polygon edges. Rather try to imagine the output of the Compare node as a graph (it's basically a line jumping between False/0 and True/1). It's detecting the rising edge of this graph, so when it jumps from False to True. Cheers

Oh, one more: I'm not to fond of the "Latest Posts" below a thread. Simply because "End" key, as well as my automatically unlocking mouse wheel, scroll past the point I'm interested in.

Sure. In long threads I often have to search, who said what and when. This is of course solely caused by my age related dementia. Maybe also to quote an early post. If the entire thread is on a single page, I can simply press Ctrl-F and search what I'm looking for. Way quicker than having to resort to the forum search for this purpose. On the other and I can understand, why some prefer paged threads. The perfect compromise for me would be, if it could be made a profile option. Beat me, if it already is and I just didn't notice, yet.

Thumbs up from my side for improved performance. Actually performance of this forum (or rather the lack thereof) is the main reason I also visit others. Personally I'd vote for entire threads on a single page. For one single reason: I can make use of browser's search function. Just my two cents. Cheers

I can't really compare, nor would I want to start another "Subscriptions Pros/Cons" discussion. Just want to add, that S22 contained some significant changes to UV generation/editing, too.

As nobody seems to jump onto this, I thought I should add a few words. It's absolutely possible to implement something like this. It's not done with just two lines of code, though. In general I do such things on a "pay what you want" basis. I'm just a bit low on time currently, so I wouldn't be able to do it right away. If you are interested, simply contact me via PM. Cheers

I'd like to pick up the point of change in culture. Before I continue, I'd like to stress, this is not a problem unique to C4D Café. It may even be less of a problem here, due to the efforts of our moderators. To me it seems there's an increasing "everything's free" "take what you can and leave" consumer mentality. More often than not, users asking questions, do not even take the time to think about how to ask a question properly (i.e. which information is needed for somebody to provide an answer). So it already takes time to find out, what the actual question is. And then it seems to be too much effort to even say thanks. This may also be caused by people asking the same question on multiple forums and being done with it as soon as they received an answer in one of them, completely ignoring people may still invest their spare time in one of the others to come up with answers. As an example I'd like to point out Cairyn's amazing work in answering programming related questions not only in this forum. Compare this to the poor contribution on his Patreon page, which actually provides even more useful content. All in all a not very motivating situation.

Can you show us the Xpresso setup and Python code?

@3D-PangelI guess, MAXON is fine with Neutrino, if they may call you Cathrin from now on.

You need to backup the original position in world space and set this after insertion. Easiest done by storing the global matrix (GetMg() and then later SetMg()). Explanation: An object only knows about its relative position (relative to the parenting object, that is). Its global position in world space is not stored anywhere, but is the result of the "accumulated" positions of all parents in the hierarchy and the object's relative position (same for scale and rotation of course). By just changing the object's position in the hierarchy, it will keep its relative position, which in combination with the new parent leads to a new position in world space. Cheers

Something like this? In general my rates are "pay what you want". Or for something like this: nothing. Cheers color_to_rot.c4d

There's an issue with the undo handling. The AddUndo(UNDOTYPE_NEW) needs to be called after the insertion of the object. Here the docs (see the Note: "In case of creation... after insertion..."). Also AddUndo(UNDOTYPE_CHANGE), while it needs to be called before the actual change, it may only be called on entities which are part of the document. Think about it. The undo functions are functions of BaseDocument. The undo system wants to keep track of changes inside a document. For a change (matrix, parameter change,...) of an entity (entity, because it's the same for objects, tags, materials...), which is already part of the document, you call AddUndo() before the change, because C4D needs to back up the state before the change (simplified, it will copy the entity's BaseContainer onto the undo stack). For a new entity, though, it will need to keep some reference to the new entity, in order to be able to remove it on undo (simplified, internally it will store a BaseLink (sorry, link to C++ docs, BaseLink class does exist only in C++) to the new entity on the undo stack). This can only work´reliably, if the entity is already part of the document, as BaseLinks are always evaluated in a document context, so AddUndo() has to be called after the insertion. You may be of the opinion, I'm nit picking, because you script seems to be working. Yet, I'm not. Wrong usage of the Undo functions can severely damage C4D stability. For your script the steps are: 1) Create Null 2) Insert Null 3) AddUndo(NEW, Null) 4) Actually no AddUndo(CHANGE, Null) needed at all, as you just modify a freshly inserted object. Where would be the point in backing up it's initial state in the same undo step as its creation? If the user presses undo, the object will be removed, there's no use of C4D restoring the initial state prior to removal... Cheers

Hi, I should be able to help. PM me, if you like. Cheers

The pie is a lie. Sorry, couldn't resist.

My recommendation would be to make use of a User Data parameter as storage for the distance travelled and simply sum the distance per frame into this. For example it could look like so: The additional Time/Equal/Condition node group is needed to reset the distance on frame 0, otherwise it's pretty straight forward. The "Distance Travelled" port is the User Data parameter of type Real added to my travelling cube, but you could add this parameter to basically any other object or tag you like and see fit. And the scene: test_xpresso_distance_per_frame_3.c4d Cheers

It's hard to tell the issue from just this screenshot, without knowing more details, especially about "Travelinger"... Here's how I'd do it: And here's the scene file: test_xpresso_distance_per_frame_2.c4d Cheers