mcjComeHere - The 2023 Version is Here - With 4 Figure Handling Options

2»

Comments

  • functionfunction Posts: 278

    Havos said:

    Check if  she has the X,Y and Z values applied to the hip. If so that will cause her to rotate around the world centre not herself. The x,y, and z translation should be on the root figure. Was the hip selected maybe when the script was applied?

    Thank you Havos, your suggestion gave me a clue, at least I can now rotate her by select the hip, not the figure.

    But for the mcj script, no matter I select the root figure or her hip to apply the script, still the same result, figure came, coordinates left in the world center, the root figure's coordinates are all 0, the hip coordinates became very large numbers. 

  • HavosHavos Posts: 5,308
    edited March 2023

    function said:

    Havos said:

    Check if  she has the X,Y and Z values applied to the hip. If so that will cause her to rotate around the world centre not herself. The x,y, and z translation should be on the root figure. Was the hip selected maybe when the script was applied?

    Thank you Havos, your suggestion gave me a clue, at least I can now rotate her by select the hip, not the figure.

    But for the mcj script, no matter I select the root figure or her hip to apply the script, still the same result, figure came, coordinates left in the world center, the root figure's coordinates are all 0, the hip coordinates became very large numbers. 

    Strange, I have that same script, and for me the translation is applied to the root, not the hip.

    Edit: Looks like I have the old version of the script not the new one. The old one moves the root, the new one moves the hip, which is pretty crazy as in reality you almost never want the hip to translate, rotate, maybe, translate, almost never. There is a parameter were you can specify the node to translate, but I could not get it to work, no matter what I typed in, it always moved the hip. I will stick to the old version of the script.

    The workaround for the new version is to place your figure inside a group, and then apply the translation to that. You can then unparent the figure from the group, and it should have the translation applied to the root. Not great, but it is a free script, so you can not complain.

    Post edited by Havos on
  • Merged the separate thread with the main thread, please don't post the saem topic in multiple locations.

  • functionfunction Posts: 278

    Havos said:

    Strange, I have that same script, and for me the translation is applied to the root, not the hip.

    Edit: Looks like I have the old version of the script not the new one. The old one moves the root, the new one moves the hip, which is pretty crazy as in reality you almost never want the hip to translate, rotate, maybe, translate, almost never. There is a parameter were you can specify the node to translate, but I could not get it to work, no matter what I typed in, it always moved the hip. I will stick to the old version of the script.

    The workaround for the new version is to place your figure inside a group, and then apply the translation to that. You can then unparent the figure from the group, and it should have the translation applied to the root. Not great, but it is a free script, so you can not complain.

    Hi Havos, thank you again. You gave a great help. I downloaded the old version and studied both, yes, the new one clearly pointed out that it will use the hip once the inherits is the DzSkeleton, not the DzBone, don't know what this mean, but thing becomes easy, just invalidate that sentence is enough.

    So finally I edited the line 132: [ if  node.inherits  "DzSkeleton" ] with a simple - in the word as this: [  if  node.inherits  "Dz-Skeleton"    ]. Now the script works fine, everything is correct. 

  • HavosHavos Posts: 5,308

    function said:

    Havos said:

    Strange, I have that same script, and for me the translation is applied to the root, not the hip.

    Edit: Looks like I have the old version of the script not the new one. The old one moves the root, the new one moves the hip, which is pretty crazy as in reality you almost never want the hip to translate, rotate, maybe, translate, almost never. There is a parameter were you can specify the node to translate, but I could not get it to work, no matter what I typed in, it always moved the hip. I will stick to the old version of the script.

    The workaround for the new version is to place your figure inside a group, and then apply the translation to that. You can then unparent the figure from the group, and it should have the translation applied to the root. Not great, but it is a free script, so you can not complain.

    Hi Havos, thank you again. You gave a great help. I downloaded the old version and studied both, yes, the new one clearly pointed out that it will use the hip once the inherits is the DzSkeleton, not the DzBone, don't know what this mean, but thing becomes easy, just invalidate that sentence is enough.

    So finally I edited the line 132: [ if  node.inherits  "DzSkeleton" ] with a simple - in the word as this: [  if  node.inherits  "Dz-Skeleton"    ]. Now the script works fine, everything is correct. 

    It was a good idea to edit the script. I deleted lines 132-139 completely as I can not think of any reason why I would want to move the hip.

  • mCasualmCasual Posts: 4,604
    edited March 2023

    i'll look into this soon, maybe add the option of moving figures either by the hip or by the root node

    I use mostly mcjParent to move things around sometimes in conjunction with mcjMakeTarget

    there's another script named mcjCometh here.

    for some of those scripts I sometimes would like if only the X-Z coordinates were changed, for cases when the Y location is already at the correct altitude

    oops looks like I did add "axis locking" in 2022 

    notably when working with gigantic scenes like the [correction] Moebius87 and Ajax dystopian city blocks

     

    in case you wonder what's that stick above the car, using (mcjParent I think)

    it's Y-rotation contains the strength of the attention William and Hanami

    have for one another and controls their body animation

    something like that

    and was 

     

     

     

    dfqerkt-f866abfd-c72a-4106-9544-36a5c8f6e42a.png
    2020 x 1180 - 2M
    Post edited by mCasual on
  • mCasualmCasual Posts: 4,604

    ah ok i will add a checkbox titled "move figures using root node"

  • HavosHavos Posts: 5,308

    mCasual said:

    ah ok i will add a checkbox titled "move figures using root node"

    it might be a good idea to make that the default. Since a lot of people will want to y rotate the figure after moving it then you want the hip x and z translations to be 0

  • mCasualmCasual Posts: 4,604
    edited March 2023

    i still have to make registry access D|S 5 compatible and package it,

    maybe maybe make sure it works with DS 1,2,3

     

    mcjComeHere2023.png
    1080 x 1215 - 1M
    mcjComeHere2023UI.png
    644 x 586 - 18K
    Post edited by mCasual on
  • mCasualmCasual Posts: 4,604
    edited March 2023

    Havos said:

    Check if  she has the X,Y and Z values applied to the hip. If so that will cause her to rotate around the world centre not herself. The x,y, and z translation should be on the root figure. Was the hip selected maybe when the script was applied?

    The script doesn't touch the rotations 

    if the hip node is far from the root node and the root node is rotated

    and you move the root node in front of the camera the figure/hip will still be far away

    OK I know the 4th option I'll add

    [Move Hip Here, by using the root node]

    thanks for making this idea resurface

    Post edited by mCasual on
  • mCasualmCasual Posts: 4,604
    edited March 2023

    The 4th option

    ( mcjComeHere2023 will be online in less than an hour )

     

     

    mcjComeHere2023.dsa.png
    364 x 364 - 134K
    Post edited by mCasual on
  • mCasualmCasual Posts: 4,604
    edited March 2023

    to me more complete we could have a script that brings the camera at a specific distance in front of the figure object

    because when the Scene is huge, for example a city, the built-in "frame object" of daz studio keeps us far and away

    this was a problem with my [correction] Moebius87 and Ajax dystopic city scene

    this could be quite useful come to think of it, the camera could be aligned to face-the-face of a figure, which is different from just framing the head

    mcjComeHere2023C_out.jpg
    1920 x 1080 - 145K
    Post edited by mCasual on
  • mCasualmCasual Posts: 4,604
    edited March 2023

    The 2023 version is at the same Bat Address same tacky basename: 

    https://sites.google.com/site/mcasualsdazscripts3/mcjcome

    ( which, by the way, was not intentional and due to cursor issues )

    mcjComeHere2023D.jpg
    904 x 490 - 45K
    Post edited by mCasual on
  • OmnifluxOmniflux Posts: 363

    mCasual said:

    i still have to make registry access D|S 5 compatible and package it,

    @mCasual are you able to expound upon this?

  • mCasualmCasual Posts: 4,604
    edited March 2023

    i've been told by someone not from Daz

    that the more direct access to the registry I used so far

    was/is deprecated and will/may be removed from DS5

    so I use this

    var oSettingsHelper = new DzSettingsHelper(); //Compatible with DS5
    
    function getSettingDS5( key, defVal )
    { 
        var path = "mCasualJacques/" + appName;
        var val = oSettingsHelper.get( path, key, defVal );
        return( val );
    }
    function setSettingDS5( key, val )
    { 
        var path = "mCasualJacques/" + appName;
        var val = oSettingsHelper.set( path, key, val );
    }
    function saveSetting( key, keyVal )
    {
        setSettingDS5( key, keyVal );
    }
    function saveBoolSetting( key, keyVal )
    {
        setSettingDS5( key, keyVal );
    }
    function getSetting( key, defVal )
    {
        return ( getSettingDS5( key, defVal ) );
    }
    function getBoolSetting( key, defVal )
    {
        return ( getSettingDS5( key, defVal ) );
    }

     

     

    Omniflux said:

    mCasual said:

    i still have to make registry access D|S 5 compatible and package it,

    @mCasual are you able to expound upon this?

    Post edited by mCasual on
  • functionfunction Posts: 278

    mCasual said:

    to me more complete we could have a script that brings the camera at a specific distance in front of the figure object

    because when the Scene is huge, for example a city, the built-in "frame object" of daz studio keeps us far and away

    this was a problem with my Stonemason dystopic city scene

    this could be quite useful come to think of it, the camera could be aligned to face-the-face of a figure, which is different from just framing the head

     Yes, yes, I always confused in a big scene, my camera or perspective view can not move to an object or figure by one click, when choose the object and RMB/LMB click the magnifier or [+] in the view port, DAZ brings me the whole picture of the scene, far away to the object.

    If you can solve this problem, it is a great help. By the way, really appreciate for your quick response and modification to this root/hip problem!

  • Silver DolphinSilver Dolphin Posts: 1,593

    Thank you!!!  Your scripts are always useful.

  • barbultbarbult Posts: 23,200
    edited May 2023

    This (2023) script always puts the selected item behind the camera instead in front of it. The old version works as expected, with the selected item placed in from of the camera. I had Y Translate Locked checked and Move Root Noide. I tried with a primitive cone to simplify things. Am I doing something wrong?

    I think I figured it out. It isn't behind my camera, it is too close to my camera to see it, I think. When Y is locked and the item is at Y=0, it can be below the view of my camera.

    Post edited by barbult on
  • mCasualmCasual Posts: 4,604
    edited May 2023

    barbult said:

    This (2023) script always puts the selected item behind the camera instead in front of it. The old version works as expected, with the selected item placed in from of the camera. I had Y Translate Locked checked and Move Root Noide. I tried with a primitive cone to simplify things. Am I doing something wrong?

    I think I figured it out. It isn't behind my camera, it is too close to my camera to see it, I think. When Y is locked and the item is at Y=0, it can be below the view of my camera.

    thanks i think it will be easy to fix, substracting vectors instead of adding

    i'll fix it right now and post the announcement below

    oops i see you were locking a coordinate

    there's also a script named mcjComethHere ( i forgot what it does exactly

    lets see ..

    https://sites.google.com/site/mcasualsdazscripts7/mcjco

    Select a figure, usually in the Scene Tab

    Run the script

    The figure now stands 4 meters ( 12ft ) in front of you

     

    Post edited by mCasual on
  • mCasualmCasual Posts: 4,604
    edited May 2023

    personally the script i use most to move things around is mcjParent

    it can parent things to one another but it can also move their World-Space positions and orientation, even in an animated way

    and while you're at it, get mcjMakeTarget, combined with mcjParent it has many many uses

    https://sites.google.com/site/mcasualsdazscripts/mcjmaketarget

    https://sites.google.com/site/mcasualsdazscripts3/mcjparent

     

    barbult said:

    This (2023) script always puts the selected item behind the camera instead in front of it. The old version works as expected, with the selected item placed in from of the camera. I had Y Translate Locked checked and Move Root Noide. I tried with a primitive cone to simplify things. Am I doing something wrong?

    I think I figured it out. It isn't behind my camera, it is too close to my camera to see it, I think. When Y is locked and the item is at Y=0, it can be below the view of my camera.

    Post edited by mCasual on
Sign In or Register to comment.