TEXTURE type



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

    On 03/12/2002 at 16:27, xxxxxxxx wrote:

    User Information:
    Cinema 4D Version:   8.012 
    Platform:      
    Language(s) :   C.O.F.F.E.E  ;

    ---------
    TEXTURE type container resource. is very strange
    although i point it at a path it drops an image name string in the basecontainer at the  id location.
    ok , i can derive a path from that.
    but the string is not always available !!!!
    mostly it will be  ""  empty :/
    its only available  during MSG_FILTER and MSG_DESCRIPTION_VALIDATE
    message checking.
    so if i try to access this string at some other stage  (like Init ),  i get nothing.
    the string  is just not there !!!!
    if i open close the image in AM itll put the string back and then sometime it gets removed again , which is a bit insane.
    this was a real pain  figure out and must be a bug of some kind.
    cheers
     
    Paul



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

    On 04/12/2002 at 01:42, xxxxxxxx wrote:

    TEXTURE items contains STRING data. (Doc bug.) Use GetString() and then GenerateTexturePath() to create a filename.



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

    On 04/12/2002 at 02:53, xxxxxxxx wrote:

    yes, we  talked about this , but my point is , the string is not always there.
    normally  data in a container is  there all the time until  the user either removes it or changes it.
    this string is not always there , which must be a bug.
    make a simple tag example and try to access the string  inside the Init part.
    the string is empty at this point and I could only get at it during the  message calls.
    use the texture item and try to get at the string during Init !!
    so if you  have stored an image using this item inside a tag and then try to reload the image inside init you wont get anything , cos the string is empty.



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

    On 05/12/2002 at 01:39, xxxxxxxx wrote:

    the  container is not available during   Init  !!!



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

    On 09/12/2002 at 09:48, xxxxxxxx wrote:

    Do you mean that GetDataInstance() returns NULL in ObjectData::Init()? Strange, but it might explain some problems reported in another thread. I haven't been able to confirm it here though. Anything special you can think of about your project or configuration?
    (This is no longer about TEXTURE I guess.)



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

    On 09/12/2002 at 09:59, xxxxxxxx wrote:

    ill try and explain it better :)
    imagine ive made a tag
    this tag has one  id that i use with the TEXTURE type  ,lets say 1000
    the tag has no executable
    it has an init and a message function
    i click on the file part in AM
    it asks me for an image file
    i select some image and its name is stored at  1000 in basecontianer
    i save the scene
    i load the scene back in
    the tag doesit Init pass first
    at this point, during init I can get the container using  getdatainstance()
    i look in this container at location 1000 for the string for my image
    its not there !!!!!!!!!!
    1000 is empty !!!!!!
    so i have to wait for the first message before i can  use this value
    at which point the string is suddenly there again  :/
    I hope that clears it up ?



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

    On 11/12/2002 at 00:38, xxxxxxxx wrote:

    Yes. That is not a bug but the expected behaviour. The data hasn't been loaded yet in Init(). That's just where you can set default values, that are then possible replaced when the saved data is loaded.


Log in to reply