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

It sounds a bit, as if you use the output of the random node to feed it into some other object's (a MoGraph random field, maybe?) seed value. I doubt that's a good idea, even if I can not explain, why this should lead to the described behavior. Anyway, I tried the random node (scene below) and for me it's nice and stable. Even after scene reload, I do get the identical values per frame. Maybe I misunderstood something in your question? Cheers test_random_node.c4d

Sounds interesting. PM me, if Chris didn't jump onto it, yet.

I opened it in R21

Right, sorry. Then I probably can't help it. Added a note to my original post.

Tested with R21, I have no R16. For the Sample node to work a Field (replacing Falloffs in earlier versions) is needed. If you add for example a "Solid" Field to your Sound Effector it will start working. Cheers

Unfortunately these flag's documentation is a bit "brief" and some are only used internally and/or are only valid at certain points in time. Next problem is, how is IsDirty() supposed to find out, who you are and when you called it last time (yes, in theory it would be technically possible, but I doubt also feasible)? I'm not a hundred percent certain (the PluginCafé certainly can give you a better founded answer), but I think, you won't get away without iterating the children yourself and storing/comparing the result from GetDirty(). You should also find lots of discussios already on this topic over in PluginCafé, you probably wouldn't even need to wait for an answer on your own question. Cheers

Please, believe me, what you are doing is wrong and will risk stability of C4D. Just because you can get something to work somehow, it does not get correct. I won't argue here, it is this simple. You can believe me or continue with this route, but then you are on your own, at least from my side. You can ask the moderators of this forum, why I feel entitled to be so definite in this case. Or you can ask in MAXON's Plugin Café to get more or less the same answer (I'd bet quite a few beers on this).

I'm sorry to be so direct. But this is plain wrong. You are really risking the stability of C4D. You can not use AddUndo() outside of Start/EndUndo(). And you shouldn't use AddUndo() inside of an Xpresso Python node. In fact you shouldn't make any scene changes from inside the Xpresso Python node. Period. And yes, I saw, that you try to limit the execution of the node with some "run" flag. But this doesn't change anything of what I said before. Without knowing more details I'd say, you should implement a Script (Menu Extensions -> Script Manager or in previous versions Menu Script -> Script Manager) or a CommandData plugin. Cheers

Cairyn is absolutely right, it's neither possible nor would many users appreciate such a break with C4D's conventions. Even if the dialog is not docked, the user can expect all dialogs "behave" if she or he saves her/his layout. This has also been discussed in Plugin Café a few times. It's certainly better to design a dialog with this in mind. Cheers