User mods, screenshots & videos > Vehicles
Small Truck
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 !!! :D
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 ! :D
Navigation
[0] Message Index
[#] Next page
Go to full version