Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[andfly]

A simple toy to have a little fun while waiting for the long-awaited release of the OUTERRA WORLD SANDBOX.
This MOD solves (in its own way) the lack of friction in the world of OUTERRA which does not allow to grab objects with pincers, or similar mechanical tools, to move or lift them.
The solution adopted is (once again) extremely imaginative because the vehicle can use a sort of "Tractor Beam", in "Star Trek" mode, capable of "binding" any object or model present on the scene to the movements of a turret, placed on the cabin of the small truck, which emits the beam.

Model link: https://drive.google.com/file/d/1-0cSAzxj2XkCbdvYEWPXCHUNk2dvtBK8/view?usp=sharing

Operation keys:
The "Arrow" keys move the turret that emits the beam.
The "F" key enables and disables the emission of the explorer beam which is used to choose the object to move.
The "O" key enables the "Tractor Beam" which captures the chosen object.
The "Z" and "X" keys lengthen and shorten the length of the tractor beam determining the distance variation of the constrained object.
The subsequent pressure on the "O" key stops the action of the beam and releases the object.

Operation, however, is very simple and intuitive.
For any doubt it is possible to consult the legend of all the commands, by pressing the "Ctrl + L" keys.

CURIOSITY :
It is possible to move any object both static (houses and buildings) and dynamic (vehicles, planes, boats).
Vehicles, when released, follow the law of gravity and fall to the ground below.
On the other hand, static objects remain in the position they are dropped even if they are in mid-air.
Furthermore, the position of static objects is recorded as a new fixed position of the object and remains permanent even in subsequent sessions of Anteworld.
So be careful not to leave buildings suspended in the air because you will always find them there.

The display of the object, while moving, only works for objects loaded "before" the small truck was loaded.
If you exit the model and load other vehicles, returning to the truck you can also move these vehicles but you will not see the vehicle during the move: only when it is released.
I believe it is a peculiar feature of the "Outerra Engine" which allows access to the "geometry object" of the objects only if they are already present when a vehicle is initialised ...
In any case it is irrelevant because the movement takes place perfectly even in these circumstances.

I haven't been able to optimize this model to the point of giving it the ability to load different instances of it.
Loading a second equal model inhibits the optimal functioning of both.
I haven't been able to figure out why but I suppose that continuously accessing the identities of the surrounding objects is quite a "delicate" operation and it's difficult to share it between instances using the same code...

However, even if with only one small truck at a time...

Have fun  !!! 

[fly77]

Hello Andfly ! How great to still have you here ! And what a nice mod !
Really imaginative and well done ! I love how the beam looks and the unloading of the truck.
I will immediately play with it. Thank you very much. Another contribution that makes outerra feel a little more like a game.
Step by step with such nice mods outerra playing raises to new levels.
Thank you very much !
I will go and test it out now 

[fly77]

can you post the mod release and video  also on outerra discord please ?! 

[fly77]

The mod works very fine ! Easy to use. Also I like the idea to include in each mod an ingame key help widget.
Some thoughts for further improvement: you know there is a distinction between purely static objects (.e.g. buildings) and static objects that have physics (e.g. crates placed in the editor). The crates placed in the editor are static but they have    "parameters" : "physics:{mass:100}", meaning that if you spawn them   $world.create_instance(this.seenObjUrl, pos,  rot, true) they will drop !    (with true  its going to be permanent ...even if you restart outerra, with false it just creating it for the current outerra session)
In this way any "static" object with "parameters" : "physics: that the user places in the editor or that he has previously dropped somewhere can be transformed into a falling object.
I did that in my landrock tributary 3500 mod upgrade of swifthyena ---see here https://forum.outerra.com/index.php?topic=5026.0
I made a bunch of such transportable "static objects with physics" in my transportable construction set. 

So if you can do the suggested upgrade (see below how) then all these and many more items will become "transportable"..Otherwise you are limited in transport to only the default physical crate, ball and barrel and only if you spawned them with TAB key

regarding your mod: I see you just do this.G_obj.set_pos(this.arr);  so you don't destroy or create objects...so my suggestion is when user presses release object key
you instead destroy the old grabbed object and create a new permanent one in its place.
  In this way any objects that have    "parameters" : "physics:  will drop. And if created with   $world.create_instance(this.seenObjUrl, pos,  rot, true)  they will stay where you dropped them even after restarting outerra

[andfly]

Hi Fly77

Your observations are very interesting.
Your considerations on static objects with physical parameters had escaped me and I learned new things.

Rightly so, with the operation of deleting the static object and recreating it with the "world.create_instance", if the object has physical parameters it is transformed into a dynamic object, useful for its transport and realism.
I state that I always prefer to use the "world.create_instance" with the "false" parameter in order not to alter the default landscape of Outerra and to have the certainty of finding it the same in subsequent sessions but, in this case, another problem would arise.
Static objects are all identified as type:1(fixed) with no differentiation between those with and without physical parameters.
If I use the "world.create_instance" with "false" I have an excellent result with objects that have physical parameters because I use them as dynamic objects and I am sure that any alteration is not reported in subsequent Anteworld sessions, indeed, even the first object inserted with the "scenery editor" (which was static) is deleted.
Unfortunately the same happens for houses and buildings.
The deletion of the static object remains permanent and the recreated object remains only usable in the current session.
Therefore, houses and palaces are lost, which never return.
On the other hand, using the method with the "true" parameter doesn't make me lose buildings but leaves the static objects with physical parameters that I don't want to remain.

The only solution that comes to mind would be to equip static objects, with physical parameters, with a very short initialization script that makes them dynamic (with the definition of the mass and perhaps an imperceptible "extra_force") and define them as "gameob" . Leaving the "visual_update" blank shouldn't have any slowdown consequences.
If you can think of a better solution then I would be very curious to know it.

I also thought of reading the type of the "hooked" object and, if I found it "fixed" i.e. static, instead of deleting it I made it invisible (obj.$ret.set_visible(false)) so I used the "world.create_instance" with "false" (creating a new object that I thought was dynamic) to play with its position, sure as not to alter the default Outerra landscape.
The procedure doesn't work: the new object, if I don't delete the previous one, remains defined as static (regardless of whether or not it has physical parameters) as a new instance of a static object still present in the scene.

For the moment I won't make any changes to the script because it seems to me that, in this way, it remains as non-invasive as possible but ... if you come up with new ideas ...

Thanks again for trying the little truck and expressing your very interesting opinions.

Good fun !   

[fly77]

yes I understand the problem...since the use of the gripping beam is not limited to physical objects
the mod needs to distinguish between objects that have parameter: physics and in this case apply create/delete methods to drop the object
and objects that do  not have parameter: "physics" and in this case use your method of just moving the object and not deleting/creating anything

"If you can think of a better solution then I would be very curious to know it."
yes there is:  it involves the use of the pkgview.h interface  and get_objdef  method...(i will post instructions here later) .. it allows reading the objdef file of an object and hence you can check the value of the "parameters" line
and take apropriate actions.

I'll report back later the detailed instructions 

[andfly]

Optimal ! 

[fly77]

here is how I identified objects that have "physics:{mass..." code line in the objdef file:

I used it in my Landrock upgrade to pick and drop any kind of objects.
the key is to use

virtual bool get_objdef_info( ifc_out ot::pkginfo::objdef& info ) const = 0;

So to test if a selected objects's objdef file contains a "physics:{mass..." code line I use

Code: [Select]

let this.objDefInfo = this.seenObj.$ret.get_objdef_info().info;
let this.isPhysicalStatic =  ( /physics:{mass/.test(this.objDefInfo.params) ) ;
you can also - if you wish - retrieve object category

this.seenObjCat=this.seenObj.$ret.get_objdef_info().objcat;
etc..

the documentation as usual is on github:

see here:
https://github.com/Outerra/anteworld/blob/master/include/ot/object_cfg.h

and here:
https://github.com/Outerra/anteworld/blob/master/include/ot/object.h ---> use this method

pkgview.h in fact is not needed..its also a very interesting interface. In case documentation is here now:
https://github.com/Outerra/anteworld/blob/master/include/ot/pkgview.h

it allows to "scan" throuh user directories to list all installed mods, search them , filter them according to type, category, parameters, tags inside objdef files..etc..

to use it :
$pkgView = this.$query_interface('ot::js::pkgview.create');

[andfly]

here is how I identified objects that have "physics:{mass..." code line in the objdef file:
... ... ...

I applied your recommendations and added code that tests for mass parameters to static objects.
These objects are transformed into dynamic ones and are subject to gravity.
The only drawback is that, being objects created "after" the spawn of the small truck, except for the first move, they are not displayed during transport but only at its conclusion.
As already noted, this is only an aesthetic inconvenience.
The shift is equally performed optimally.

To use the updated mod: re-download.

P.S.
I've also improved turret mobility which is now smoother, faster, and more accurate.

[KW71]

and-fly-77 The dynamic duo!  Kudos!

[fly77]

and-fly-77 The dynamic duo!  Kudos!

 

[fly77]

Hi andfly

I am trying to figure out what's going on with all this object moving and why they're not showing when moving them (if they were spawnd after the truck was spawned). Very strange.
In any case for your original version the problem seems to be solved if you use

Code: [Select]

this.obj.$ret.set_pos(this.arr);
this.obj.$ret.set_rot(this.arr_w);

instead of

this.G_obj.set_pos(this.arr);
this.G_obj.set_rot(this.arr_w);

That is move the object, not the geom object.

But it creates another problem. after relase it is thrown violently..and it doesn't appear its related to your application of extra impulse.

further trials needed 

[andfly]

and-fly-77 The dynamic duo!  Kudos!

Hi KW71   
Too good ...

Confronting one's ideas on topics of common interest is, first of all, very pleasant and then it helps to understand the intimate mechanisms of a splendid environment such as the Outerra engine.
If it becomes useful for building increasingly engaging and amusing models and situations, it is a good result not only for those who build them but also for all those who will use them.

[andfly]

Hi andfly

I am trying to figure out what's going on with all this object moving and why they're not showing when moving them (if they were spawnd after the truck was spawned). Very strange.
...

You are using the mod as it was originally born in my thoughts.
The original version used the method of moving the real object directly and not its geometry object, as it logically should have done.
But I encountered the same problems you are describing.
At each frame the moving object is subjected to the forces of physics (Bullet or JsbSim) and accumulates such a quantity of gravitational, lateral and rotational pushes (whose action is prevented by the continuous constraint to remain in the position assigned by set_pos) that, when released, it slams hard against the ground or sideways and unpredictably.
I tried to act on the definition of the collisions (set_collision_group) trying to make the object free of "physics" during the movement, but without success.
Changing the category of the object to type 1 (ie static and without physics) and then redefining it to its original category at the end of the transport also seems to be not possible.
Thus, the idea of displaying only the movement of his "geomob", and the optimal result achieved, seemed to me the most convenient solution.

Having found a solution, I was no longer interested in investigating further but... a small doubt remained...
You may have noticed that a very small "extra_force" action is performed when you drop the object.
It serves to be sure of "awakening" the physics of the object which otherwise, sometimes, even if it has a mass value, remains suspended at the release point.
A similar effect occurs when lifting the pickup truck body.
If an imperceptible "extra_impulse" is not performed which makes the whole model vibrate, the objects deposited on the platform do not "feel" that the container is being lifted and remain in their place, letting the moving container pass through them.
All these effects (noticed only during the construction of the model) and the solutions adopted to solve them leave the doubt that, in certain circumstances, the physics assigned by the objdef is not categorically unassailable but possibly manipulable.
But how ?
I haven't been able to find an answer but it remains a topic worthy of more thorough investigation...

As for the inability to access the "geomob" of an object that isn't already in the scene when you initialize the truck... again I have no answers.
I simply accept the evidence of the facts assuming that it is a prerogative of the "Outerra engine"

[andfly]

Truly ...
There would be another possibility, which I had thought about when I had the desire to build this Mod, but which I had immediately rejected due to the complications it involved.
However, since we are dissecting the various aspects of a problem, we might as well make a small mention even if it remains only theoretical.

The solution would be to recognize the type of object to be transported and, if subject to Bullet Physics, use the extra_force to suspend it and drag it where desired.
It would be necessary to trigonometrically calculate the coordinates of the point of arrival of the tractor beam and act with the appropriate extra_force or extra_impulse commands opposed on the object to make it remain on those coordinates.
Being commands that (with the worldspace=true parameter) can be applied directly to ECEF coordinates, the conversion to model coordinates would not be necessary and this should simplify the problem a bit.
I think, however, that it would be useful to have the forces processed by the code of an appropriate PID controller, to ensure stable positioning without too much unsightly vibration.

The power of this method would be that it would act physically on the object and its displacement would be much more believable and aesthetically valid because it would also be continuously subject to the forces of inertia.

Its limitation is that it can only be applied to objects governed by Bullet Physics, thus excluding static objects and airplanes.