Update Plugins the Correct way?

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 16/08/2012 at 07:43, xxxxxxxx wrote:

Possibly, but prone to errors.
It must be a "official" way, right?

Cheers
Lennart

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 17/08/2012 at 08:12, xxxxxxxx wrote:

No one have this issue?

Tried setting a disklevel = 1 but that did not re-write the symbolcache file.
(I do not know how to "see" or use the disklevel in my code)

The only way I could make an updated plugin work, with new GUI/AM parameters,
was to do the regular additions for the new GUI/AM parameters in the
.h , .res and .str files.
Then in the .pyp file Init and use the parameter -number- instead
of the res name.
That is instead of "myplugin[C4D.MY_NEWPARAMETER]" I must use
the parameters numeric name, like "myplugin[1234]"

Then use old school try/except in the .pyp plugin code
for backwards compatability.
This of coarse makes any further development/updates very delicate
and elder plugins that have evolved over a longer period will in
essence be impossible to distribute as updates as many of them
not only have new parameters but also are re arranged.
So any number corresponding to a parameter are in practice lost.
I thought that the enumeric handling was supposed to secure this
problem but, to me, it falls flat on its face as the values are
"locked" into the "symbolecache" file.

For a workstation it is ok-ish to ask the user to trash the symbolcache
file, but for larger setups, NET, it is not.

I must be missing something basic, right?

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 21/08/2012 at 15:43, xxxxxxxx wrote:

So the options is to use the enumerics for the GUI
but their values in the .pyp Init and Execute for newly
added parameters?

That is what I do now.

Cheers
Lennart

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 21/08/2012 at 16:31, xxxxxxxx wrote:

Well, instructing the user to delete the symbolcache file is not convenient, but seems to be the only way to do it. Technically, Cinema cannot detect whether symbols have changed without doing the symbol-cashing once again which would be paradox.

-Nik

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 06/09/2012 at 17:22, xxxxxxxx wrote:

So I've ended up with using my own version checker.
At first install, the plugin itself generates a version file
in user prefs and it's all cool.

Any updated plugin(s) will check the version in that file at
start up. If it differs, the version file is updated and
the symbolcache file is deleted with a message to restart
Cinema and why, at users convenience.

It was the best solution I could come up with not
confusing the user.

Cheers
Lennart

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 19/09/2012 at 15:04, xxxxxxxx wrote:

So either everybody knows how and think I'm an idiot that don't get it,
or everybody is doing it their own way and think I'm an idiot that don't get it

I really don't know elsewhere to ask than here and at dev forum and no response...

As mentioned in last post I'm testing a system that writes and checks a check file in users prefs folder.
The result is that the user then need to restart Cinema when an updated version
of my plugins are released. By re start I mean a second time so the symbolcache file can be written.

While it works, I've not seen this in any other update of plugins and are still wondering how it's
suppose to be done.

Cheers
Lennart

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 20/09/2012 at 02:41, xxxxxxxx wrote:

Hi Lennart,

The only thing that occurs to me is what you are doing in the resource files. You said in your original post that you send out a new version with new .res, .h, and .str files. Are you reusing the symbol values in the .h file?

What I mean is, suppose in version 1 of your plugin you have a symbol, e.g. call it MY_SYMBOL, which in the .h file has value 2000. Then in version 2, you alter the resource so that some other symbol - e.g. MY_NEW_SYMBOL - has value 2000 and MY_SYMBOL is now 2100.

If you do that and then load an existing file which used version 1 of the plugin, it can get mightily confused and IME just won't work. You shouldn't re-use symbols like this, MY_SYMBOL should be at its original value for ever more and new symbols should be given brand-new values.

That's really the only thing I can think of. Although I don't use Python I can't see that C++ and Python plugins are any different in this respect and I've never seen this problem other than as I described above.

Cheers,

Steve

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 20/09/2012 at 05:10, xxxxxxxx wrote:

Hi Spedler.
No, only added symbols.
First release :
MYSYMBOL id 1001

Next release:
MYSYMBOL id 1001
MYNEWSYMBOL id 1002

Cheers
Lennart

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 20/09/2012 at 07:12, xxxxxxxx wrote:

Hm. Then I can't offer anything more I'm afraid. It seems very odd, though. I just copy new versions of plugins over old ones and they just... work. Is this symbol cache a Python-specific thing or is it always there?

Steve

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 24/09/2012 at 15:02, xxxxxxxx wrote:

It would mean a lot to me with some kind of input from Maxon support.

The other day I got an update of a Python Object Plugin, ForkRoot by Rui,
that has a new parameter (ID in .res etc).
Thing is that it doesn't throw an error and the parameter works.
However, it is "greyed" not orange (in the ScriptManager for example)
as a loaded res ID have if it is included in the symbolcache file.

If I trash the symbolcache file and re start Cinema, it is orange
and I can access it via code.

Apparently, a plugin registering can be different ?

Cheers
Lennart

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 25/09/2012 at 00:23, xxxxxxxx wrote:

@spedler: Its a Python-only thing, I think. COFFEEcan't implement NodeData plugins, so no descriptions need to be loaded for it, except it is used for scripts.
In C++, the symbols are included in your dynamic library, because you included the enumeration into your source-file.

@lennaert: I guess, Rui has just copied the symbols into his plugin directly, instead of using the c4d-module for it. This means, rui can use the symbol without worrying about the symbolcache. This is the only explanation that appears to me.

-Niklas

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 25/09/2012 at 05:43, xxxxxxxx wrote:

I've just got a msg from dev that it's the way it is atm.
So for now, running your own check system is the way.

Cheers
Lennart