Using ReadMemory()
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 06/09/2004 at 15:55, xxxxxxxx wrote:
Allocate the memory, read from disk and do what you wish. You do not free the memory until you are finished with it whether you parse it into other data structures or keep as is. Don't always take the docs literally. They are done with the best intentions but things of this magnitude often have small errors. If you find report it to Mikael Sterner and it will be resolved in good time.
darf
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 06/09/2004 at 16:07, xxxxxxxx wrote:
Thanks, darf!
Not making a 'normal' (simplistic) Tag plugin means that every nasty approach must be used. I can't use BaseContainers for arrays of UCHAR and Real (which may be thousands or tens of thousands of elements each). There is little choice but to make member variables in the TagData and implement Read(), Write(), CopyTo().
Still can't figure out how to get to the TagData after PluginTag::Alloc(ID). Seems to be impossible (?). I get a PluginTag*, I need the TagData to set up all of the values.
A real example (please, not limpy Tlookatcamera.cpp) would probably save me days, if not weeks, of arduous wall banging!
Robert
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 06/09/2004 at 17:37, xxxxxxxx wrote:
?
Ermm, if you allocate the handles ( list of pointers ) to the allocated data you would have full access to that data in any of the functions within the class you derived from TagData. Are you concerned with loading/saving the data or accessing it within other functions? If you are trying to access the pointers from other plugins I would suggest setting up a message for retrieval of the data ( avoids the other plugins requiring the intimate knowledge of the original TagData class. Make sense?
darf
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 06/09/2004 at 20:30, xxxxxxxx wrote:
I cannot access the derived TagData class. Pray tell how to get to it when PluginTag::Alloc() returns a PluginTag* for the TagData type. This is how one programmatically creates a custom tag (i.e.: Tag plugin). Therefore, I have no methods within the PluginTag to get the data, unless I can retrieve the TagData from there somehow. Let me know if you know how to do it.
My full plugin is a CommandDataPlugin. This (and other soon to be done) TagPlugins will be registered together and work together, exchange data, and whatnot. This TagPlugin is not standalone, nor does it even use an AM. It is there solely to respond to user-caused changes in an object (by feeding a VertexMap tag with new weights).
The new weights (and other values) are derived elsewhere and must be sent to the TagData, which I don't have access to. I implemented Message() in TagData and tried using tag->Message(MSG_CHANGED, data) with data pointing to a struct with all of the relevant data. This seems to work, but cannot verify that the data is actually being sent intact and stored by the TagData.
Robert
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 07/09/2004 at 05:35, xxxxxxxx wrote:
!?
So you need a Menu Command plugin that can access data from objects? Will it only act on selected objects? Should it search for all objects with these tags?
You are wanting to store vertex data within the tags?
Do the tags themselves need to access the data of the other tags?
darf
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 07/09/2004 at 06:42, xxxxxxxx wrote:
The Command plugin loads the objects, sets up textures on them, rigs them, sets up morphs, and more.
Actually I'm wanting to store three sets of weight maps, links to the affected bone and 'dummy' vertex weight map, and miscellaneous info.
The Message() approach seems to be working. Not certain if it's the best or expected approach, but it is the only way to access the TagData from the Command plugin classes that I can find. The weights are calculated in the Command plugin (which has all of the relevant information - and there is much of it).
Robert
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 07/09/2004 at 10:50, xxxxxxxx wrote:
Unless your Command plugin has access to the class derived from TagData Message is the best option IMHO. Otherwsie you can get the Tag from the object's list of tags and cast it with the your class definition. This would give you direct access to the tag's data. In development that sucks because your class definitions have to be updated ( unless you can keep a simple one project setup ). I use Messaging so any of my plugs can talk to others. It is kinf of a nodal system where they all respond to certain messages so they can work better together for previews and what have you.
darf
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 08/09/2004 at 07:29, xxxxxxxx wrote:
One idea (maybe too late) on the question how to access your TagData, when you only have a PluginTag*:
Sine a PluginTag is a GeListNode, its GetNodeData() function should return the TagData*.
Michael
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 08/09/2004 at 08:15, xxxxxxxx wrote:
Nope. Tried that already. Tried it with 0 ID and the ID for the plugin tag and it crashed C4D faster than a M$ OS on SP2.
Otherwise, I don't know what ID the TagData has.Robert
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 09/09/2004 at 03:55, xxxxxxxx wrote:
Strange, I just tried this with a self-written Expression. At least from within TagData, (plugin->GetNodeData() == this) holds.
The docs for GetNodeData() says: "Note: You can only use the virtual functions of this object if you are in the same module that registered the node!"
Does this warning apply to you?Michael
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 09/09/2004 at 13:31, xxxxxxxx wrote:
I find it amusing that the only way to tell the PluginTag what it already knows - its TagData - is to set it forcibly from within the TagData itself. The process to create a plugin tag within plugin code:
PluginTag* plugintag = PluginTag::Alloc(ID_TYPE);
The ID_TYPE (generic here) corresponds directly to the extended TagData class which is what is actually registered (it's Alloc method is used to create the extended class instance of TagData associated with the PluginTag). But you get back a PluginTag* (BaseTag extension) which doesn't have any access to the TagData just literally allocated.
The entire plugin is the 'same module', and compiled together, including the plugin tags. This is the same module that registered the node (i.e.: TagData).
For now, I'll stick to the Message() method since at least I can guarantee success and avoid crashes.