Hi,
For my Blob Planets game, I have design a Planet game object (file) with a script with lots of property, in particular the planet_radius. Each planet has a collision object which size is set at runtime with the planet_radius, and they dont have a sprite, but a mesh component that is generated at runtime…
So In the Editor, in my main collection I can place my planets objects, I can edit the properties, but I cant see the actual size of the planet (the collision object always has the default size) nor the planet mesh…
So I can barely place things correctly (I will have enourmous planets and tiny one…)
→ is it possible to make the editor show the actual size? I cant “override” the planet scale because it modifies the Planet game object file for all planets!
At first I wanted to just put a factory and have all data in a lua table, but I still need to SEE things to place and size them correctly…
How do you place things you dont see?
As a workarround, I was thinking to create a simpler PlanetData gameobject with a script just carrying the visual properties (or event just setting position) and a mock sprite to show things.
Then in the init phase I scan these objects, spawn actual planets instead, then delete the mock objects.
Is this the way to go?
Why exactly cannot you just scale the planets?
Here I have 3 GO created from single file with different scales:
If for some reason you need to keep them with original scale later on, you can change scale to 1 in the runtime.
thanks, yes I know I can use the scale, but in fact my objects don’t have visuals except for the collision shapes. The object is a bit complex, I a have a collision shape for the planet, a trigger zone for gravity activation, and 2 mesh generated at runtime, one for the planet, one for the atmosphere.
Then the “planet_radius” control the collision sphere diameter, the “zone_offset” control the trigger zone sphere diameter (it is added to the planet sphere), and the “atmo_offset” controle the size of the atmosphere (size of mesh)…
but if I scale the game object, the visuals doesn’t change, because I see only collision shapes and they dont scale! Unless I change the shape diameter… but this would be for all gameobjects… you cant overload the sphere diameter for one instance in editor.
Even If I could set the scale, I would have to compute the good scale to match my planet_radius property by hand…
In fact the Editor lacks a mechanism to show things that depends on user data, or maybe a “on_editor(self)” function in script that allows us to tweack the editor visuals..
I think the other ways around would be better: using a PlanetData gameobject with true sprites that I can define the size of and see things would be better, then my planet use the size of sprites to compute my properties instead of the other ways around. If the PlanetData has a script that register the object in a lua table, I can have my controller that just spawn all planet in a post-init message.
the last option is to create an in-game editor…
Other ideas?
I guess you could add a child game object(not a game object file) to each one of the planets(this will not change the planet file).
The child could have the same collision objects as the planet but you can modify the collision shape’s size for the child object. So you use the child object as a visual placeholder.
Once you are done with the design, you can delete them or if you want to have them present while you design other planets, you could create a script that deletes them at runtime.
Probably you can use editor scripts to add/delete this visual placeholders automatically, and also size them according to the planet script properties(I’ve never done this but I think it should be possible).
1 Like
The collison shapes should scale (I tested it on Defold 1.12.2 and 1.10).
Maybe the problem is you are scaling them in X/Y but not Z?
Only X/Y (shapes are spaced, but same size):
Scale on X/Y/Z:
Visible without visuals aswell:
(btw I should had used capsule instead of box with two spheres 
old project…)
yes you’re right! Thank you, my bad I was using the blue handle for scaling so it was only x/y, not x/y/z!
I dont understand why scaling on x/y dont scale visual… but anyway, this is good!
Even if I don’t see the atmospheric zone and force zone, I can at least compute the planet_radius from scaling value at init!
Many thanks!
I tried to do something with a mock collection and 3 objects with each mock sprite (because you can override only game object properties, not component properties!)
But then in runtime I could not identify all the objects from one collection without maintaining a lua table at hand… because you cant get the url of a “sibling” gameobject, for example! or can we? can we get all game objects of a given collection?
I don’t recall any way to list the children of a collection or other game objects within the same collection (though that doesn’t necessarily mean it doesn’t exist — I’m still a beginner with Defold).
If the planets were created using a factory, you could store their references at creation time, but that’s not the case here.
However, since each planet already has a script, they can “register” themselves. You would need to create something (for example, a game object with a script) that receives messages sent from the planets during their init() function. This object could store references to all planets or organize them into systems or groups. But this is something you’ll need to implement yourself.
Take a look at this example script which registers objects: sample-third-person-playground/shadow_mapping/model_tiers.script at master · defold/sample-third-person-playground · GitHub
It register each game object to the global shadow quality system. This script is simply part of each game object like rock, tree, grass etc.
And here where it is registered: sample-third-person-playground/shadow_mapping/tiers.lua at master · defold/sample-third-person-playground · GitHub
