Well seems im getting the logic ,my way was mutch close to you’r whole the structure and classes ,but i wanted to get a list of nodes as start of action point ,while you start it from virtual class and avoid problems i got in thnx 
soo i should get unit : list of units
unit.getSword ray from /to
enemyUnit : list of enemyUnits
unit.getNode collide with if collision is done
i dont need to take virtual unit class from node ,couse i have it as enemyUnit that gave me that node i tried to collide with .
Well thnx you really mutch for your help,i vould probably had to hit the wall soo many times before changing my logic (and it gives soma pain 
) Thnx really mutch
1 Like
Note that if you really must link your game objects to your nodes (i.e., get a game object after doing a scene graph collision or traversal), you can always use Spatial user data: getUserData()/setUserData().
Use with caution, however - it’s easy to abuse this system and make a mess for yourself, just like relying on Controls to model game objects. The more you can keep a clean separation between your game objects and visualization (like what @yaRnMcDonuts showed you) the better off you are.
You’ve effectively given your spatial hp. The fact that you’ve put it in a child object doesn’t matter. The spatial is still the game object.
Proper separation, you’d have a separate Unit object. It would have hp, position, rotation, etc… every frame you’d move your loaded models to the position of your units. Your game logic would operate on the Unit objects.
Presumably you are not actually pointing a gun at your screen and shooting the objects. I imagine there is a mouse click and then scene picking involved, etc… already half a dozen layers of abstraction. So why operate directly on the Spatial instead of getting the game object for the spatial and operating on that?
What if one of your units wants to shoot another unit? Is it also going to do mouse picking?
But anyway, if you want to continue down the road you are on (until it all collapses under its own weight and you rewrite from scratch and can address all of these issues) then there are other ways to do what you want that don’t require extending Spatial/Node.
UnitStats could have been a control, for example.
Of if you just want to shove values onto your spatial then there us setUserData()/getUserData().
I will note that in my own games, usually the only user data I have is the object ID so I can find the game object for the spatial in those cases I need it. (100% of the time because of user interaction.)
https://jmonkeyengine.github.io/wiki/jme3.html
As Paul stated,
https://jmonkeyengine.github.io/wiki/jme3/advanced/custom_controls.html
Everything you need is there, including the link to userData.
This is a common issue for new game developers. You’re not alone.
Your game object (e.g. a car) will be (for the purpose of simplicity) a class, and will contain properties it has. A car has properties. A has-a relationship. It is an car. An is-a relationship.
It is a car. It has a model/spatial.
None of your objects are spatials or geometries, they just have them as a property. Hence 99.9999% of the time, don’t extend the scene objects, use them as a property.
2 Likes
I should also add that we all abuse this kind of system daily; using the location of the spatial as our gameobject reference location. It works fine, but won’t on a client-server level. You should in fact use a vectorD for precision and set the spatial location - and that is what Paul means when he says “it will only take you so far” - before the problem becomes apparent.
This is bad:
This is better:
UnitStat extends AbstractControl
spatial.setControl(UnitStat)
or
unitStat.setSpatial(spatial)
however, as @pspeed said, the best solution would be to learn ES. But I assume you’re still in the “programming exercise/throwaway code” time waster so you’re good with whatever you’re happy with.
Today I wonder how people can write games without ECS. I started as well with spatials as game obejects and painted my self into any possible corner
But note that in this thread I never specifically mentioned an ECS. You can have game objects without entities… it’s just a lot more hand-coding. Less of a learning curve though.
If you are used to an ECS then hand-coding game objects will feel like a chore. I know because I’ve done it a few times recently. Once for sim-eth-basic a while back and then again for the demos for my physics engine because I wanted to be sure the physics engine was not accidentally tied directly to an ES.
But it’s totally possible.
2 Likes
Hey Paul have you ever checked out Unity out of curiosity? And how long was your recovery from that stroke I imagine you had once you saw that not only you can only use spatials as game objects there but that you can’t even have any code not attached to a spatial as a control-like script thing?
I mean I’m basically the king of extending Node and even I can’t stand Unity’s approach.
I heard a rumor that ECS is coming for Unity as well. Btw I also heard that bigger game project use unity stuff for the visual and code the rest (server side I guess) them self, I mean it’s C# and there should be not much limitations…
If your game object is a node or spatial, what purpose does it serve on a server?
I like to stick to singleplayer. But if I were doing server stuff I imagine I’d use a headless scene graph as well. Otherwise good luck getting anything meaningful like world transforms from a bunch of data objects if you want the server do do anything more than relay packets between players.
Then again I don’t know anything about multiplayer so shrug.
1 Like
I’m making a single player as well