Is it possible to transfer the value of either an existing variable or a formula result into a vector3 for scaling a prefab? Failing that, can I scale a prefab outward evenly along all axis using a non-vector3 variable?
  • I could not find an option for this. I re-wrote change scale into custom node that should be able to do this. It constructs Vector3 from 3 float variables X,Y,Z
    https://pastebin.com/U6x6Bqpj
  • Another alternative would be using Makinom, which has a vast amount of Vector3 manipulation options :)
    Please consider rating/reviewing my products on the Asset Store (hopefully positively), as that helps tremendously with getting found.
    If you're enjoying my products, updates and support, please consider supporting me on patreon.com!
  • Thanks for both of these responses, and especially for the code. Incidentally, what's the danger of inserting custom nodes? Could an update break them?
  • edited December 2019
    Well, this does not modify the source code just adds new event module.
    So far I have not had a case where event module breaks with update, but it's possible if underlying mechanics change. For example how ORK accesses variables etc.
    In this case I don't think that's likely as everything used is pretty fundamental and all I changed was variable type.

    Generally it has been really useful for me to add custom nodes, and it's easy if you find similar node in ORK and look it up in source code. You can then use that node as basis for your own new node.
    For example I have StartEventOnObject that just allows you to start Event on object with event interaction in a scene. I use this to split game events.
    SetRandomPosition randomly shifts object position in a radius. So, you can randomize you blood decals etc.
    I wrote bunch of easy ways to address other plugins and custom code.
    Sometimes I combines some of ORK's nodes together so I could call multiple things from one node.
    Post edited by hellwalker on
  • edited December 2019
    Custom nodes usually don't break anything, although that depends on what you do in them :)
    Generally, if something in ORK's API changes that's used by your node, you'll have to update the code of your node, but that's pretty much it.

    The only thing that can 'break' something is if you remove the custom node's code and still have it in one of your events - in which case the node becomes a useless empty node, but keeps the original node's data alive in case it ever comes back. The event should still work, though.
    Post edited by gamingislove on
    Please consider rating/reviewing my products on the Asset Store (hopefully positively), as that helps tremendously with getting found.
    If you're enjoying my products, updates and support, please consider supporting me on patreon.com!
  • That's good to know, thanks. I've asked this before, but is it possible to set a child object's base size to 1 in Unity units, rather than defaulting to 1/1 as a percentage of its parent's size? I'm also curious whether there's a simple way to destroy all of a prefab's children when the prefab itself is destroyed. The method I'm aware of forces me to destroy the additional objects individually, lest they remain in the scene as clones.
  • No, changing the scale of a game object that's parented to another one will always be within the parent's scale - it's just how Unity operates. You'd have to unparent the game object, change the scale and reparent it again.

    Regarding destroying child objects - that should actually happen automatically when the parent is destroyed.
    Please consider rating/reviewing my products on the Asset Store (hopefully positively), as that helps tremendously with getting found.
    If you're enjoying my products, updates and support, please consider supporting me on patreon.com!
  • "No, changing the scale of a game object that's parented to another one will always be within the parent's scale - it's just how Unity operates. You'd have to unparent the game object, change the scale and reparent it again."

    Doesn't that still change it by a percentage based on the parent's scale? Would I have to scale it down to zero first and then to one, or whatever size I want to make it? Why does re-parenting the object after this step not readjust the scaling to the parent's, and if I set the new scale to 1/1/1, re-parent it and scale out to 5/5/5, would that be scaled from the object's new scale setting or the parent's?

    "Regarding destroying child objects - that should actually happen automatically when the parent is destroyed."

    It may be that changes made to a prefab's child prevent it from being destroyed along with the parent. If my prefab is an empty game object, for example, and I resize one of its child objects, the child object always remains as a clone after the parent is destroyed unless I destroy the child *before the prefab. The clones do not persist after changing scenes, however.
  • For scaling thing you can try it in unity editor. Unparent child, then scale, reparent, unparent. The readout of scale parameter will change but the actual size won't.

    Codewise one way that could work is with objects lossyScale, but I think if the object is rotated in weird ways lossy scale might not be 100% accurate. (https://docs.unity3d.com/ScriptReference/Transform-lossyScale.html)
    public static void SetGlobalScale (this Transform transform, Vector3 globalScale)
    {
    transform.localScale = Vector3.one;
    transform.localScale = new Vector3 (globalScale.x/transform.lossyScale.x, globalScale.y/transform.lossyScale.y, globalScale.z/transform.lossyScale.z);
    }


    But unparent/scale/reparent will actually give you the most accurate results.
  • Thanks, @hellwalker. Will it work if I add to a combatant an empty game object with children, unparent/scale/reparent the empty game object as part of a default spawning event and then try to scale the children from the empty game object's new size (1/1/1)?
  • edited December 2019
    Hmm. Ok, what happens number wise is that child object scale get's changed based on percentage scale compared to parent object.
    For example if you put x1 cube(C) into x2 cube(P), the x1 cube(C) will now be .5x cube. If you put it in x4 cube(P), it will be .25 etc.

    For example if you put x1(1,1,1) cube(C) into x2(2,2,2) cube(P), and then resize x2 parent cube to x20 cube. The child cube will still remain as 0.5x cube, but if you unparent child it will be 10x cube now. Because you uniformly scaled parent cube, the child cube got scaled as well. But since relatively it was still half the size of parent cube, it's LocalScale still reads 0.5.

    So in your case, if you have (C) cube of global scale x10 and local scale x0.5 inside (P) cube of global scale x20. Then you move (C) cube into empty object of x1 scale, it will now read local and global scale of 10 cause it's 10 times bigger then x1 empty.

    If you double the size of empty now so it's x2 scale. The child will also be doubled to global x20 scale and but local scale will remain x10(Because relatively child is still 10 times bigger then parent).

    If you now reparent this to original x20 (P) cube, since their global scales match and both are 20, the local scale of the (C) cube will now be 1.

    I guess you could use this information in some way to avoid re parenting. For example if you store child object local scale in a V3 variable (Transform to variable node), multiple this variable by two and assign this variable this back to child object scale. The scale is now doubled.




    Post edited by hellwalker on
  • Thanks, everyone, for all of your input. I think the only way to reliably use this feature is via spawning (and constantly re-spawning) radii objects at the location of combatant objects rather than parenting them. Even then, I might be barking up the wrong tree. All of those check, re-check, spawn, destroy etc. events add up to some serious performance lag pretty quickly.
  • I'd suggest a different approach: using Combatant Triggers.
    A combatant trigger is a component you attach to something with a trigger (i.e. collider with Is Trigger enabled), which will keep track of combatants within it. E.g. add one to your player (or any other combatant) and you can get combatants that are in the trigger via the event system (Add > Combatant > Trigger nodes).
    You can add tags to the combatant triggers to create different 'zones' ald also check for how long a combatant has been in the trigger, e.g. checking if a combatant has been in the back of the combatant.
    Combatant triggers can also be used in battle AIs :)

    Alternatively, you can also use a Search Combatants node to find combatants within range of something - or a Search Objects node to find game objects in range.
    Search Combatants should perform better, as it just checks the combatants registered to ORK, while Search Objects will use Unity's functionality to find objects, which can be quite heavy.
    Please consider rating/reviewing my products on the Asset Store (hopefully positively), as that helps tremendously with getting found.
    If you're enjoying my products, updates and support, please consider supporting me on patreon.com!
  • @gamingislove It would still be extremely useful to be able to scale outwards along all axis by a factor as determined by a formula. So long as you're using an object with a defined scale to start, like a sphere object set to 1/1/1, you could always trust the degree to which the formula would scale it outwards and balance your game then accordingly. This would be good for things like explosions that might encompass a larger area based on the underlying power as defined through ORK data.

    If a dragon sneezes a flaming booger, for example, and that booger hits something and explodes, the explosion radius might become larger or smaller based on factors like the dragon's size and violence of the particular sneeze in question, all of which could factor into an ORK formula made specifically to calculate the blast radius scaling for flaming dragon boogers starting from a base size. Honestly, how can anyone expect to create a proper RPG without sufficient means for interacting with flaming snot globules? Even "The Elder Scrolls 76," when it finally releases some time in 2032, or thereabouts, will probably have some way for modders to eventually include that feature, right after they've finished with fixing all of the bugs and making the game characters butt naked.
Sign In or Register to comment.