Outerra forum
User mods, screenshots & videos => Other => Topic started by: fly77 on December 02, 2018, 05:14:10 am
-
I was trying to make a throwable object by following the structure of objdef file of the crate. Created a package of a rock and moved it to the outerra program's packages directory
C:\Program Files (x86)\Outerra\Anteworld\packages\outerra. However I don't know which keys to press to throw the physical object. So I tried if it can be brought to life by placing it in the editor, but all objects even if they have a mass parameter, when placed by the editor do not seem to move in any way in the game..they are just static. Is there any way to place/throw objects made by us that have physics in outerra, besides creating them as vehicles or planes or boats - as this would require to "enter" each object to bring it to life?
-
Hm, this part isn't completed.
All objects (including vehicles) can be placed as static, it depends on the method used to instantiate them. Throwable objects have to be created as dynamic, but I think scenery editor doesn't recognize them as such and creates them as static ones. It should be using a hybrid mode, where they would be dynamic initially but then static in the final scenery, to avoid wasting cpu cycles on them. But we also need to add ability to wake them up on interaction.
The shortcuts create those few dynamic objects as dynamic ones directly. Currently you'd be able to test if your object works as dynamic probably only though alt+c console (or a script from vehicle) like this:
var x = $query_interface("ot::js::dynamic_object.create", "outerra/crate/crate", #pos, #rot);
x.extra_impulse({x:0, y:0, z:0}, {y:10}, false);
Can't test right now because my Vega GPU again corrupts the displays whenever I run OT ...
You may not be able to apply extra impulse until the object is ready (first time pkg loading).
-
Hmm. I tried
Alt+C
$query_interface("ot::dynamic_object.create", "outerra/crate/crate", {x:0,y:0,z:0}, {x:0,y:0,z:0});
but got error: interfacace creator ot::dynamic_object.create not found
-
I forgot js there: "ot::js::dynamic_object.create"
-
Thanks a lot ! It works !
-
Trying to get the right shoot direction for a missile object from an aircraft carrier missile launcher using quaternions..not easy as I struggle to understand how to get the proper quaternion for my missile launcher. For the moment without the commented line of code it shoots to the front of the ship horizontally following the heading of the ship. Also the missile flies OK as the impulse is applied in front of the tip and drags it towards its tip. But: I don't know how to modify the quaternion to allow for pitch of the launcher. As soon as I start trying some quaternion multiplications as in the commented line of code the shoot direction doesn't follow any more the ship heading and seems to shoot in crazy direction. What I was trying with the code is to implement Qpitch * Qship * Conjugate(Qpitch) . Is this what is needed ? Also I am not sure if the definition of Qpitch is ok. Thought it could be Qpitch = {x:1*Math.sin(missile_pitch/2),y:0,z:0,w:Math.cos(missile_pitch/2)} as cannon normally points to the forward direction of ship (y model axis) and rotation for pitch should be around x model axis. Result however is not as expected. Any hint ? Where is/are the error/s ?
function Quatmult(q,p){
var r =[];
r.x = q.x*p.w + q.y*p.z + q.w*p.x - q.z*p.y;
r.y = q.z*p.x + q.w*p.y + q.y*p.w - q.x*p.z;
r.z = q.w*p.z + q.z*p.w + q.x*p.y - q.y*p.x;
r.w = -(q.y*p.y + q.x*p.x + q.z*p.z - q.w*p.w);
return r;
}
function QuatConjug(quat){
var Quat = [];
Quat.x = -quat.x;
Quat.y = -quat.y;
Quat.z = -quat.z;
Quat.w = quat.w;
return Quat;
}
function toQuatRot(angle,axxis){
var Quat = [];
Quat.x = axxis.x*Math.sin(angle/2);
Quat.y = axxis.y*Math.sin(angle/2);
Quat.z = axxis.z*Math.sin(angle/2);
Quat.w = Math.cos(angle/2);
return Quat;
}
function update_frame(dt, engine, brake, steering, parking){
shipQuat= this.geom.get_rot();
pitchquat = toQuatRot(missile_pitch,{x:1,y:0,z:0});
tempquat = Quatmult (pitchquat,Quatmult(shipQuat,QuatConjug(pitchquat))); // trying invane to get pitch for missile launch direction
cannonQuat = tempquat;
$throw = this.$query_interface("ot::js::dynamic_object.create", "outerra/missile/missile", ecef, cannonQuat);
$throw.extra_impulse( {x:0, y:10, z:0}, {x: 0 ,y: 10000, z:0 }, false);
}
-
Quaternions aren't easy to work with, and one has to realize they just define rotations around a vector. Here it means that quaternion is used to transform from default orientation (y+ forward, z+ up) in ECEF space to the desired one.
Take a look at these functions that compute quaternion from provided fwd & up vectors (https://github.com/Outerra/anteworld/blob/c7727033c4f64574baa04e2e03d2b955b2454d1e/include/ot/glm/glm_ext.h#L456).
Their JS versions are actually in lib/vectors.js. In theory you could $include("/lib/vector.js") and then do something like ot.vectors.Quaternion ...
-
Thank you very much cameni for the suggestion. I will try it.
Hmmm i tried $include("/lib/vector.js")
and got
Error: error opening file C:/Program Files (x86)/Outerra/Anteworld/lib/vector.js
-
Hm it's possible there was a recently fixed error in $include from vehicle scripts (if the path is ok). For now you could try extracting it into your directory, getting rid of the wrapper js magic ...
-
you mean using the functions from https://github.com/Outerra/anteworld/blob/c7727033c4f64574baa04e2e03d2b955b2454d1e/include/ot/glm/glm_ext.h#L456
and getting rid of all the stuff like "inline detail::" or "template<..." so to get a clean javascript code ? is this what you mean by wrapper ? If so how can I achieve this ? unfortunately I am not very fluent in all this. I have the impression that's a bit over my capacities.
By the way also on airplane models js files I get error opening file if i try $include("/lib/vector.js"). The vectors file however is indeed in the path C:/Program Files (x86)/Outerra/Anteworld/lib/
Also trying $include("C:/Program Files (x86)/Outerra/Anteworld/lib/vector.js"); gives same error.
maybe I'll just try to understand the code you mention and reproduce it or some of it by myself. Anyway thanks !
-
Hmm.. by fiddling around with code, trying different quaternion multiplication ordering, apparently I got the missile launcher pitch working now ! What I have done is performing the simple quaternion multiplication Qship * Qpitch, that is do the pitch rotation first (I reasoned that as the reference orientation (starting orientation) is the one with the model aligned with its x,y,z axes parallel to the ECEF x,y,z axes probably the rotation around x for the pitch should be done first and then apply the ship orientation. Also there seems to be no need for the Q*P*conj(Q) formula here. Just multiply two quaternions to get the two rotations combined... :)
Now it fires at the desired pitch angle while keeping aligned with the ship heading which is what I wanted. By the way also works for azimuth (Quaternion rotation around z). I simply did the multiplications in the order: Qship * Qazimuth*Qpitch. Wow !
The "last" thing that is missing now is to get a "splash" or an "explosion" when the object falls into water or lands on ground. Would also be used for thrown bomb objects from a plane. I tried to throw a "vehicle" (that might have a script to trigger a splash or explosion when low above ground ) but it gives an error. For the missile fortunately it seems I can fire a "plasma-thing" in the same direction and with same speed as the thrown object. I also set "bounce" to 0 and "rolling_friction" to 1 in the physics parameters for the missile object so that hopefully it won't move too far from the impact location. Unfortuntaly it still bounces away quite a lot. Is there another physics parameter I could set to get it "stuck" where it falls ? kind of "stickiness" ?
function update_frame(dt, engine, brake, steering, parki
pitchquat = toQuatRot(missile_pitch,{x:1,y:0,z:0});
shipQuat = this.geom.get_rot();
shipQuat = Quatmult(shipQuat,pitchquat);
}
-
I found that I can reduce bouncing my adding a very high value of rolling_friction and using a (spherical?) collision box for the missile , plus setting bounce to very large negative value. Still it bounces but less. A trick to get the missile stuck in the crater seems to be to shoot the plasma-thing ahead of the missile so that he crater is made first and then hoping that the missile flies exactly into the crater. I hope I can get the tuning right. =|
-
I tried the command "launch_tracer" from explosions.h as it seems to allow for another way to drag an object (missile) along a plasma thingy (tracer?) . At least this is what I understand from the documentation on github (" //@param entid object id to be dragged by tracer" ). I tried as follows from a plane (mig29) but while no error occured and I can hear my missile launch sound I could not see any plasma thing nor my missile object nor any visual effect (no light flash) anywhere. I also tried with "outerra/crate/crate" but nothing happens. What is wrong ? Is the command "active"?
var $explosions;
var bomb_flag = 0;
function initialize(reload){
...
this.register_event("air/controls/eject", function(v){ bomb_flag ^= 1; });
$explosions=this.$query_interface("ot::js::explosions.get");
}
function update_frame(dt){
if (bomb_flag ==1){
$explosions.launch_tracer( {x:10, y:20, z:-10}, {x:0, y:300, z:0}, 3, {x:1,y:1, z:0}, 0.5, 0.2, 0, 0, "outerra/missile/missile");
this.snd.play(missile_sound_src,missile_sound,false,false);
bomb_flag = 0;
}
}
-
The parameter has to be an id of existing object (get_eid), not a name.
-
Still stuck with the "launch_tracer". I still could not figure out how to get the id of my missile object .... that I want to shoot from the carrier vehicle..whatever I used for get_eid() I get error "has no method get_eid"...for instance I tried $throw.get_eid() or with obj as defined below obj.get_eid() but get the same error. I get no error if I do this.geom = this.get_geomob(0) this.geom.get_eid() it gives me a number (apparently the id of the carrier but how to get that of the missile ?)
world = this.$query_interface("ot::js::world.get");
obj = world.create_instance("outerra/missile/missile" , pos, rot, false); creates an apparently static missile
$throw = this.$query_interface("ot::js::dynamic_object.create", "outerra/missile/missile", ecef2, shipQuat); OK creates a dynamic missile but don't know how to get_eid()
Another trial that gave no error but still no moving missile was the following:
tracer = this.fire(mdc, {x:plasmaquat.x, y:plasmaquat.y, z:plasmaquat.z}, 100, 30, {x:1,y:1, z:0});
pos = this.geom.get_world_pos_offset(mdc);
bullet = world.create_instance("outerra/missile/missile", pos, shipQuat, false);
$explosions.launch_tracer( mdc, {x:0, y:1000000, z:0}, 3, {x:1,y:1, z:0}, 0.5, 0.2, 0, 0, tracer , bullet , 0 );
It created the missile at right spot and orientation, gave no error, but the missile is a static one and remains in place. IF i try the same with $throw.id() again no error, the missile is dynamic and $throw.id() increases by 1 with each shoot but the missile is not deagged along with the tracer....by the way what is a tracer ?? is it the plasma-thing ?
Also if I try the following I get no error and even bullet.id() is a number that changes with every shoot but missile remains static
$explosions.launch_tracer( mdc, {x:0, y:1000000, z:0}, 3, {x:1,y:1, z:0}, 0.5, 0.2, 0, 0, tracer , bullet.id() , 0 );
-
Try calling .get_geomob(0).get_eid() on the created object.
-
Got it working ! The missile gets shot with the tracer. Also the missile gets stuck very nicely in the ground on impact ! :) However I had to shoot a tracer first in init_vehicle using $explosions.launch_combo. Strangely even if I destroy the tracer it still works but if I never create the tracer before it won't work. Don't undertsand it but its fine. Quite nice and it makes a crater and smoke on impact! :D :D :D
Only thing it makes no splash when hitting water.
function init_vehicle(){
tracer = $explosions.launch_combo( ecef, {x:45*plasmaquat.x, y:45*plasmaquat.y, z:45*plasmaquat.z}, 3, {x:1,y:1, z:0}, {x:0.3,y:0.3, z:0.3}, 1, 0.1, 0.1, 20, true, true, true );
$explosions.destroy_tracer( tracer );
}
function update_frame(dt, engine, brake, steering) {
$throw = world.create_instance("outerra/missile/missile", ecef, cannonQuat, false);
var ent_id = $throw.get_geomob(0).get_eid();
// $explosions.destroy_tracer( tracer );
$explosions.launch_tracer( ecef, {x:45*plasmaquat.x, y:45*plasmaquat.y, z:45*plasmaquat.z}, 5, {x:1,y:1, z:0}, 0.5, 0.2, 0, 0, tracer , ent_id , 0 );
$explosions.launch_combo( ecef, {x:45*plasmaquat.x, y:45*plasmaquat.y, z:45*plasmaquat.z}, 3, {x:1,y:1, z:0}, {x:0.3,y:0.3, z:0.3}, 1, 0.1, 0.1, 20, true, true, true );
}
-
Strange "flying house bullet" appearing from time to time. My "outerra/tank-ammunition/tank-ammunition" of course looks differently. By the way, while my bullet is removed from the scene after impact, not so the "flying house" that remains stuck in the impact crater. Also the type of "flying house" is not allways the same. Seems to occur only (but not allways) when the tracer is looked at against the backdrop of the sky, especially if zooming in.
function update_frame(dt, engine, brake, steering, parking){
.......
$throw = world.create_instance("outerra/tank-ammunition/tank-ammunition", ecef, bulletquat, false);
entid = $throw.get_geomob(0).get_eid();
mdc = {x:0,y:2,z:0};
ecef = this.geometry.get_world_pos_offset(mdc,this.muzzle_id);
$explosions.launch_tracer( ecef, {x:450*plasmaquat.x, y:450*plasmaquat.y, z:450*plasmaquat.z}, 1, {x:1,y:1, z:0}, 0.5, 0.2, 0, 0, tracer , entid , 0 );
tracer = $explosions.launch_combo( ecef, {x:450*plasmaquat.x, y:450*plasmaquat.y, z:450*plasmaquat.z}, 1 , {x:1,y:1, z:0}, {x:0.3,y:0.3, z:0.3}, 7, 0.1, 0.1, 20, true, true, true );
$throw.remove_from_scene();
....
}
-
Hope this "flying building" bug will be solved in the next version 😁
-
I am trying to dynamically create a "programmatically configurable missile" (modelled as a vehicle script )
launched from a plane's script when a "fire" key is pressed.
To spawn the missile I use
world.create_instance("outerra/missile/missile", this.geom.get_world_pos_offset({x:-15, y:0, z:4}), this.geom.get_rot(), false);
Everything works fine and I can create as many of these dynamic missile objects as I want,
however to make the missile configurable so that from the plane script I can choose missile speed, explosive power etc.
I am trying to use my global variables plugin.
So to make the missile configurable it calls this plugin and everything works fine up to a certain point.
For instance I can spawn the plane and set the missile speed to the desired value by repeated key presses.
Then I exit the plane and from the F3 menu spawn the missile. It starts flying at the speed set in the plane script
delivered to the missile script via the plugin. I can repeat this as often as I want and for as many missiles I want.
However when I instead try to spawn the same missile from the plane scripts world.create_instance command
I can just create 2 instances of the missile..at the third outerra crashes even if the missile script has nothing inside
besides a void update_frame(){}
function init_vehicle(){
...
plugin = this.$query_interface('xt::js::global_variables.get');
...
}
The same happens when I declare the missile as watercraft instead of vehicle.
On the other hand if I declare it as JSBSIM aircraft ..for instance "jsbsim/c172r",
adding the corresponding FDM folder I can dynamically create as many missiles as I want
(still with the missile calling the plugin interface) without crashing.
I'd like however to declare the missile as vehicle or watercraft .
So why can I spawn 2 but not more of these objects when its declared as vehicle or how could I spawn programmatically more of these "configurable" vehicles ?
-
Can you submit the crash report?
-
yes I submitted it.
by the way here is the simplugin.hpp. Note that from the missile javascript I don't call anything of the plugin at the moment except getting its interface as described above - and I am not going to call anything vehicle/geomobj etc.. related...I will use it just to send and retrieving my global variable's values. I could cancel the vehicle , geomob etc.. related stuff from the plugin if this helps. Note that if I create the missile without the missile getting the plugin interface I can create as many as I want without problem even from the script.
#pragma once
#include <comm/intergen/ifc.h>
//wrap in special comments to inject into the generated interface header too
// can also use /*ifc{ ... }ifc*/ to include only in the client header
//ifc{
#include <ot/vehicle_physics.h>
#include "ot/explosions.h"
#include "ot/environment.h"
#include "ot/canvas.h"
//}ifc
///Plugin's base implementation class, exposing a xt::engine interface
class simplugin
: public policy_intrusive_base
{
public:
simplugin();
~simplugin() {};
///Interface declaration: [namespace::]name, path
ifc_class(xt::global_variables, "ifc/");
///Interface creator
ifc_fnx(get) static iref<simplugin> get()
{
return new simplugin;
}
//interface function examples
ifc_fn double readDat(int index);
ifc_fn bool writeDat(int index, double data);
ifc_fn void writeEcef(int index, double x, double y, double z, int id);
ifc_fn double readEcefx(int index);
ifc_fn double readEcefy(int index);
ifc_fn double readEcefz(int index);
ifc_fn int readEcefId(int index);
ifc_fn void writeQuat(int index, double x, double y, double z, double w, int id);
ifc_fn double readQuatx(int index);
ifc_fn double readQuaty(int index);
ifc_fn double readQuatz(int index);
ifc_fn double readQuatw(int index);
ifc_fn int readQuatId(int index);
ifc_fn void init_chassis(iref<ot::vehicle_physics> obj);
ifc_fn void init_vehicle(iref<ot::vehicle_physics> obj);
ifc_fn void update_vehicle(float dt, float throttle, float brake, float steer);
ifc_fn void firething();
ifc_fn void turretthing(float v, float dt);
ifc_fn void mantletthing(float v, float dt);
private:
iref<ot::geomob> m_geomob;
iref<ot::sndgrp> m_sndgrp;
iref<ot::explosions> m_explosion;
iref<ot::environment> m_environment;
iref<ot::canvas> m_canvas;
int _counter;
iref<ot::vehicle_physics> _vehicle;
};
-
The crash happens somewhere in c4e (chromium, in Javascript), but the last caller above it is the global_variables_plugin.dll.
You can attach your debugger to outerra.exe and get a better info what the plugin was doing when it crashed.
-
do you mean inside visual studio I need to under debug/connect to process choose outerra.exe ..and then recompile the plugin ? I have done the debug/connect to outerra.exe in VS then fired the 3 missiles an outerra ...outerra crashes and I sent you once more the crahs-report. Is this what you meant ?
-
You do not need to recompile if your dll already has debug info.
Simply attach to outerra.exe in visual studio debug, then do what you need to do to cause the crash, which will break in the visual studio where you can see the call stack.
-
OK in visual studio first thing I see after crash is this message
(https://i.postimg.cc/d1kzmkpk/plugin-crash.jpg) (https://postimages.org/)
(https://i.postimg.cc/Wz0CxR2s/info.jpg) (https://postimages.org/)
AFTER trying again I get another one
(https://i.postimg.cc/RVNn1MZr/info2.jpg) (https://postimages.org/)
OK I'll try again doing what the messages suggest. (loading symbols from...)
-
OK now I got something in call stack but it seems that i still have not loaded symbols even though after ending debug I get this in the VS output window..but I have the impression I am doing something wrong with this debug. Anyway the strange thing is that I am not calling any action fro the plugin...just getting its interface.
'outerra.exe' (Win32): caricamento di 'C:\Program Files (x86)\Outerra\Anteworld\outerra.exe' completato.
'outerra.exe' (Win32): caricamento di 'C:\Windows\SysWOW64\ntdll.dll' completato. Simboli caricati.
'outerra.exe' (Win32): caricamento di 'C:\Windows\SysWOW64\kernel32.dll' completato. Simboli caricati.
'outerra.exe' (Win32): caricamento di 'C:\Windows\SysWOW64\KernelBase.dll' completato. Simboli caricati.
'outerra.exe' (Win32): caricamento di 'C:\Windows\SysWOW64\ws2_32.dll' completato. Simboli caricati.
'outerra.exe' (Win32): caricamento di 'C:\Windows\SysWOW64\msvcrt.dll' completato. Simboli caricati.
'outerra.exe' (Win32): caricamento di 'C:\Windows\SysWOW64\rpcrt4.dll' completato. Simboli caricati.
'outerra.exe' (Win32): caricamento di 'C:\Windows\SysWOW64\sspicli.dll' completato. Simboli caricati.
'outerra.exe' (Win32): caricamento di 'C:\Windows\SysWOW64\cryptbase.dll' completato. Simboli caricati.
'outerra.exe' (Win32): caricamento di 'C:\Windows\SysWOW64\sechost.dll' completato. Simboli caricati.
'outerra.exe' (Win32): caricamento di 'C:\Windows\SysWOW64\nsi.dll' completato. Simboli caricati.
'outerra.exe' (Win32): caricamento di 'C:\Windows\SysWOW64\advapi32.dll' completato. Simboli caricati.
'outerra.exe' (Win32): caricamento di 'C:\Windows\SysWOW64\crypt32.dll' completato. Simboli caricati.
'outerra.exe' (Win32): caricamento di 'C:\Windows\SysWOW64\msasn1.dll' completato. Simboli caricati.
'outerra.exe' (Win32): caricamento di 'C:\Windows\SysWOW64\Wldap32.dll' completato. Simboli caricati.
'outerra.exe' (Win32): caricamento di 'C:\Windows\SysWOW64\normaliz.dll' completato. Simboli caricati.
'outerra.exe' (Win32): caricamento di 'C:\Program Files (x86)\Outerra\Anteworld\luajit.dll' completato. Modulo compilato senza simboli.
'outerra.exe' (Win32): caricamento di 'C:\Windows\SysWOW64\opengl32.dll' completato. Simboli caricati.
'outerra.exe' (Win32): caricamento di 'C:\Windows\SysWOW64\gdi32.dll' completato. Simboli caricati.
'outerra.exe' (Win32): caricamento di 'C:\Windows\SysWOW64\user32.dll' completato. Simboli caricati.
'outerra.exe' (Win32): caricamento di 'C:\Windows\SysWOW64\lpk.dll' completato. Simboli caricati.
'outerra.exe' (Win32): caricamento di 'C:\Windows\SysWOW64\usp10.dll' completato. Simboli caricati.
'outerra.exe' (Win32): caricamento di 'C:\Windows\SysWOW64\glu32.dll' completato. Simboli caricati.
'outerra.exe' (Win32): caricamento di 'C:\Windows\SysWOW64\ddraw.dll' completato. Simboli caricati.
'outerra.exe' (Win32): caricamento di 'C:\Windows\SysWOW64\dciman32.dll' completato. Simboli caricati.
'outerra.exe' (Win32): caricamento di 'C:\Windows\SysWOW64\setupapi.dll' completato. Simboli caricati.
'outerra.exe' (Win32): caricamento di 'C:\Windows\SysWOW64\cfgmgr32.dll' completato. Simboli caricati.
'outerra.exe' (Win32): caricamento di 'C:\Windows\SysWOW64\oleaut32.dll' completato. Simboli caricati.
'outerra.exe' (Win32): caricamento di 'C:\Windows\SysWOW64\ole32.dll' completato. Simboli caricati.
'outerra.exe' (Win32): caricamento di 'C:\Windows\SysWOW64\devobj.dll' completato. Simboli caricati.
'outerra.exe' (Win32): caricamento di 'C:\Windows\SysWOW64\dwmapi.dll' completato. Simboli caricati.
'outerra.exe' (Win32): caricamento di 'C:\Program Files (x86)\Outerra\Anteworld\openal-mob.dll' completato.
'outerra.exe' (Win32): caricamento di 'C:\Windows\SysWOW64\shell32.dll' completato. Simboli caricati.
'outerra.exe' (Win32): caricamento di 'C:\Windows\SysWOW64\shlwapi.dll' completato. Simboli caricati.
'outerra.exe' (Win32): caricamento di 'C:\Windows\SysWOW64\winmm.dll' completato. Simboli caricati.
'outerra.exe' (Win32): caricamento di 'C:\Windows\SysWOW64\version.dll' completato. Simboli caricati.
'outerra.exe' (Win32): caricamento di 'C:\Windows\SysWOW64\dnsapi.dll' completato. Simboli caricati.
'outerra.exe' (Win32): caricamento di 'C:\Program Files (x86)\Outerra\Anteworld\crashrpt.dll' completato.
'outerra.exe' (Win32): caricamento di 'C:\Windows\SysWOW64\userenv.dll' completato. Simboli caricati.
'outerra.exe' (Win32): caricamento di 'C:\Windows\SysWOW64\profapi.dll' completato. Simboli caricati.
'outerra.exe' (Win32): caricamento di 'C:\Windows\SysWOW64\wsock32.dll' completato. Simboli caricati.
'outerra.exe' (Win32): caricamento di 'C:\Windows\SysWOW64\IPHLPAPI.DLL' completato. Simboli caricati.
'outerra.exe' (Win32): caricamento di 'C:\Windows\SysWOW64\winnsi.dll' completato. Simboli caricati.
'outerra.exe' (Win32): caricamento di 'C:\Windows\SysWOW64\api-ms-win-core-synch-l1-2-0.dll' completato. Simboli caricati.
'outerra.exe' (Win32): caricamento di 'C:\Windows\SysWOW64\imm32.dll' completato. Simboli caricati.
'outerra.exe' (Win32): caricamento di 'C:\Windows\SysWOW64\msctf.dll' completato. Simboli caricati.
'outerra.exe' (Win32): caricamento di 'C:\Program Files (x86)\Outerra\Anteworld\c4e\c4e.dll' completato.
'outerra.exe' (Win32): caricamento di 'C:\Windows\winsxs\x86_microsoft.windows.common-controls_6595b64144ccf1df_5.82.7601.18837_none_ec86b8d6858ec0bc\comctl32.dll' completato. Simboli caricati.
'outerra.exe' (Win32): caricamento di 'C:\Windows\SysWOW64\psapi.dll' completato. Simboli caricati.
'outerra.exe' (Win32): caricamento di 'C:\Windows\SysWOW64\secur32.dll' completato. Simboli caricati.
'outerra.exe' (Win32): caricamento di 'C:\Windows\SysWOW64\winhttp.dll' completato. Simboli caricati.
'outerra.exe' (Win32): caricamento di 'C:\Windows\SysWOW64\webio.dll' completato. Simboli caricati.
'outerra.exe' (Win32): caricamento di 'C:\Windows\SysWOW64\nvapi.dll' completato.
'outerra.exe' (Win32): caricamento di 'C:\Windows\SysWOW64\dxgi.dll' completato. Simboli caricati.
'outerra.exe' (Win32): caricamento di 'C:\Windows\SysWOW64\uxtheme.dll' completato. Simboli caricati.
'outerra.exe' (Win32): caricamento di 'C:\Windows\SysWOW64\nvoglv32.dll' completato.
'outerra.exe' (Win32): caricamento di 'C:\Windows\SysWOW64\wtsapi32.dll' completato. Simboli caricati.
'outerra.exe' (Win32): caricamento di 'C:\Windows\SysWOW64\wintrust.dll' completato. Simboli caricati.
'outerra.exe' (Win32): caricamento di 'C:\Windows\SysWOW64\ntmarta.dll' completato. Simboli caricati.
'outerra.exe' (Win32): caricamento di 'C:\Windows\SysWOW64\winsta.dll' completato. Simboli caricati.
'outerra.exe' (Win32): caricamento di 'C:\Windows\SysWOW64\mscms.dll' completato. Simboli caricati.
'outerra.exe' (Win32): caricamento di 'C:\Windows\SysWOW64\icm32.dll' completato. Simboli caricati.
'outerra.exe' (Win32): caricamento di 'C:\Windows\SysWOW64\clbcatq.dll' completato. Simboli caricati.
'outerra.exe' (Win32): caricamento di 'C:\Windows\SysWOW64\dsound.dll' completato. Simboli caricati.
'outerra.exe' (Win32): caricamento di 'C:\Windows\SysWOW64\powrprof.dll' completato. Simboli caricati.
'outerra.exe' (Win32): caricamento di 'C:\Windows\SysWOW64\MMDevAPI.dll' completato. Simboli caricati.
'outerra.exe' (Win32): caricamento di 'C:\Windows\SysWOW64\propsys.dll' completato. Simboli caricati.
'outerra.exe' (Win32): caricamento di 'C:\Windows\SysWOW64\AudioSes.dll' completato. Simboli caricati.
'outerra.exe' (Win32): caricamento di 'C:\Windows\SysWOW64\wdmaud.drv' completato. Simboli caricati.
'outerra.exe' (Win32): caricamento di 'C:\Windows\SysWOW64\ksuser.dll' completato. Simboli caricati.
'outerra.exe' (Win32): caricamento di 'C:\Windows\SysWOW64\avrt.dll' completato. Simboli caricati.
'outerra.exe' (Win32): caricamento di 'C:\Windows\SysWOW64\msacm32.drv' completato. Simboli caricati.
'outerra.exe' (Win32): caricamento di 'C:\Windows\SysWOW64\msacm32.dll' completato. Simboli caricati.
'outerra.exe' (Win32): caricamento di 'C:\Windows\SysWOW64\midimap.dll' completato. Simboli caricati.
'outerra.exe' (Win32): caricamento di 'C:\Program Files (x86)\Outerra\Anteworld\c4e\ffmpegsumo.dll' completato.
'outerra.exe' (Win32): caricamento di 'C:\Program Files (x86)\Outerra\Anteworld\c4e\icudt.dll' completato. Modulo compilato senza simboli.
'outerra.exe' (Win32): caricamento di 'C:\Windows\SysWOW64\dhcpcsvc.dll' completato. Simboli caricati.
'outerra.exe' (Win32): caricamento di 'C:\Windows\SysWOW64\hid.dll' completato. Simboli caricati.
'outerra.exe' (Win32): caricamento di 'C:\Windows\SysWOW64\mswsock.dll' completato. Simboli caricati.
'outerra.exe' (Win32): caricamento di 'C:\Windows\SysWOW64\WSHTCPIP.DLL' completato. Simboli caricati.
'outerra.exe' (Win32): caricamento di 'C:\Windows\SysWOW64\wship6.dll' completato. Simboli caricati.
'outerra.exe' (Win32): caricamento di 'C:\Program Files (x86)\Common Files\microsoft shared\Windows Live\WLIDNSP.DLL' completato.
'outerra.exe' (Win32): caricamento di 'C:\Windows\SysWOW64\rasadhlp.dll' completato. Simboli caricati.
'outerra.exe' (Win32): caricamento di 'C:\Windows\SysWOW64\FWPUCLNT.DLL' completato. Simboli caricati.
'outerra.exe' (Win32): caricamento di 'C:\Windows\SysWOW64\gpapi.dll' completato. Simboli caricati.
'outerra.exe' (Win32): caricamento di 'C:\Windows\SysWOW64\cryptsp.dll' completato. Simboli caricati.
'outerra.exe' (Win32): caricamento di 'C:\Windows\SysWOW64\rsaenh.dll' completato. Simboli caricati.
'outerra.exe' (Win32): caricamento di 'C:\Windows\SysWOW64\ncrypt.dll' completato. Simboli caricati.
'outerra.exe' (Win32): caricamento di 'C:\Windows\SysWOW64\bcrypt.dll' completato. Simboli caricati.
'outerra.exe' (Win32): caricamento di 'C:\Windows\SysWOW64\bcryptprimitives.dll' completato. Simboli caricati.
'outerra.exe' (Win32): caricamento di 'C:\Windows\SysWOW64\cryptnet.dll' completato. Simboli caricati.
'outerra.exe' (Win32): caricamento di 'C:\Program Files (x86)\Outerra\Anteworld\plugins\charctrl\charctrl_plugin.dll' completato.
'outerra.exe' (Win32): caricamento di 'C:\Program Files (x86)\Outerra\Anteworld\plugins\COPY-global_variables_plugin.dll' completato.
'outerra.exe' (Win32): caricamento di 'C:\Program Files (x86)\Outerra\Anteworld\plugins\global_variables_plugin.dll' completato.
'outerra.exe' (Win32): caricamento di 'C:\Program Files (x86)\Outerra\Anteworld\plugins\grid_overlay_plugin.dll' completato.
'outerra.exe' (Win32): caricamento di 'C:\Program Files (x86)\Outerra\Anteworld\plugins\screencapture_plugin.dll' completato.
'outerra.exe' (Win32): caricamento di 'C:\Program Files (x86)\Outerra\Anteworld\plugins\tir-trackir-plugin.dll' completato.
'outerra.exe' (Win32): caricamento di 'C:\Program Files (x86)\Outerra\Anteworld\plugins\vehicle_plugin.dll' completato.
'outerra.exe' (Win32): caricamento di 'C:\Program Files (x86)\Outerra\Anteworld\otbullet.dll' completato.
'outerra.exe' (Win32): caricamento di 'C:\Program Files (x86)\NaturalPoint\TrackIR5\NPClient.dll' completato.
'outerra.exe' (Win32): caricamento di 'C:\Program Files (x86)\Outerra\Anteworld\jsbsim_wrapper.dll' completato.
'outerra.exe' (Win32): caricamento di 'C:\Program Files (x86)\Outerra\Anteworld\JSBSim.dll' completato.
Il thread 0x1664 è terminato con il codice 0 (0x0).
Il thread 0x183c è terminato con il codice 0 (0x0).
Il thread 0x454 è terminato con il codice 0 (0x0).
Il thread 0x152c è terminato con il codice 0 (0x0).
Eccezione generata in corrispondenza di 0x0FE2B731 (c4e.dll) in outerra.exe: 0xC0000005: violazione di accesso durante la lettura del percorso 0x00000024.
Il programma '[7972] outerra.exe' è terminato con il codice 0 (0x0).
(https://i.postimg.cc/rsc2VyZD/info3.jpg) (https://postimg.cc/BLhVN303)
-
You won't have pdbs from the exe or c4e, but you should have a pdb for your own dll plugin.
-
However when I instead try to spawn the same missile from the plane scripts world.create_instance command
I can just create 2 instances of the missile..at the third outerra crashes even if the missile script has nothing inside
besides a void update_frame(){}
function init_vehicle(){
...
plugin = this.$query_interface('xt::js::global_variables.get');
...
}
Perhaps the problem you have presented could derive from the global management of variables in the instances of models that use the physics of vehicles (and boats) and from which the models that use Jsbsim are immune.
When you create your missile as a "vehicle" the variable "plugin" with which you get the interface of your plugin, is shared by all the other successive instances of the same missile that you try to create.
plugin = this. $ query_interface ('xt :: js :: global_variables.get');
It could create such confusion as to crash the whole program ...
Maybe (I'm not sure but it would be an attempt) you can solve it by calling the interface with: "this.plugin".
this.plugin = this. $ query_interface ('xt :: js :: global_variables.get');
The variable would no longer be global but would be unique and different for each missile instance created.
I hope I have been of help. :)
-
Hi andfly. Thanks for the interest. I tried that also but it doesn't change anything. Still crashing in the same way.
-
You won't have pdbs from the exe or c4e, but you should have a pdb for your own dll plugin.
I have the global_variables_plugin.pdb file in the same visual studio folder where the global_variables_plugin.dll has been created
still get the same degug call stack message in c4e.dll and no other message. This time I could launch 3 missiles before crashing though.
after stopping debug...VS output continue sto show the c4e error message "Eccezione generata in corrispondenza di 0x0FF9B731 (c4e.dll) in outerra.exe: 0xC0000005: violazione di accesso durante la lettura del percorso 0x00000024."
maybe I'd better consider seriously the missile as an aircraft (which seems also more natural) and define its flight behaviour using JSBSIM instead of vehicles extra_force command...allthough that requires me an "extra effort" to get more familiar with JSBSIM
-
This is the call stack I see (with VS 2019)
(https://i.imgur.com/EUtqCfD.png)
My bet is the global var plugin does something wrong in the creator method.
The difference between aircraft and vehicles is that every aircraft has a separate javascript context, and also a separate JSBSim instance. Because of that aicraft are memory (and cpu) hungry.
Vehicles of the same class share a lot of stuff, and also share a javascript context. It's the reason why there's init_chassis that's run once on the first vehicle instance, to initialize stuff that's common for all instances of given vehicle class. I'm not sure what your plugin does, but from its name it sounds like you'd bind it in init_chassis and set the return value into a global variable, for all instances to use?
-
Also this may help you:
https://stackoverflow.com/questions/654696/how-to-debug-external-class-library-projects-in-visual-studio
In any case, when you attach the debugger, you should be able to put a breakpoint into your dll code and the debugger will stop there, and you can step through it - hopefully it will show the full stack in that case.
-
Thank you. Will help me to learn something but to get things going in the meantime I will go the JSBSIM route.
Funny how with JSBSIM I can shoot many missiles that just keep flying around randomly by their own like sailplanes ^-^ Need to give them some THRUST !
(https://i.postimg.cc/Z5mbJd5x/sailplane-missiles.jpg) (https://postimg.cc/BXh9gtDj)
-
Another even more esoteric thought ...
When I built the models that used the "world.create_instance" I initially had some crash problems.
The instances were created in a "for-next" loop and (I assumed ) that the overlap of the instructions did not leave enough time for the method to be executed in full before the next call ... or (easier) than the creation of the new instance was carried out with coordinates too close to the previously created instance.
I had solved it by implementing a timer that forced the method to be executed no earlier than 0.5 seconds from the previous call.
This avoided overlapping the models.
You could try avoiding to execute the method in rapid succession or, better still, by varying the position under the wing where the missiles must appear:
this.geom.get_world_pos_offset ({x: -15, y: 0, z: 4})
(changing the value in x, different for each missile).
-
hmm...well I fire the missiles by pressing a button and I wait between consecutive launches. So I have no overlap between consecutive missiles. So that is not the cause of the crashes in my case.
Then I tried also launching the missile from farther away as you say - for example this.geom.get_world_pos_offset({x:-24, y:0, z:-5})- just to be sure that the launched missile does not "overlap" with the plane.
This also does not change anything in the crashes. It is something related with the fact that the missile tries to get the plugin interface. Seems outerra doesn't like that too many vehicles created from a script try to get the plugin interface. If I spawn the missiles from F3 as I said I also have no problem.
Same happens if instead of my global variables pluging I get the interface of the example-vehicle plugin..just as a test. So also it is not the special fault/mistake in my plugin as also the example vehicle plugin creates the same problem. Its also not a graphic overload problem as it does not happen when missiles don't try to get the plugin interface o rthey are spawned from F3
-
It's nothing with OT, the crash happens in your dll.
More specifically, it crashes in c4e that is given some gibberish js object from your dll. We have tests that create hundreds of objects and they work normally.
Can you show the code?
-
Sure
here are simplugin.hpp and simplugin.cpp.
Note that I'd be glad to remove all lines of code except those related with read write to variables..but when I cancelled them I got errors in compiling. I got the code from republic of texas and it works without problems when I spawn the missile (getting the plugin) from F3
#pragma once
#include <comm/intergen/ifc.h>
//wrap in special comments to inject into the generated interface header too
// can also use /*ifc{ ... }ifc*/ to include only in the client header
//ifc{
#include <ot/vehicle_physics.h>
#include "ot/explosions.h"
#include "ot/environment.h"
#include "ot/canvas.h"
//}ifc
///Plugin's base implementation class, exposing a xt::engine interface
class simplugin
: public policy_intrusive_base
{
public:
simplugin();
~simplugin() {};
///Interface declaration: [namespace::]name, path
ifc_class(xt::global_variables, "ifc/");
///Interface creator
ifc_fnx(get) static iref<simplugin> get()
{
return new simplugin;
}
//interface function examples
ifc_fn double readDat(int index);
ifc_fn bool writeDat(int index, double data);
ifc_fn void writeEcef(int index, double x, double y, double z, int id);
ifc_fn double readEcefx(int index);
ifc_fn double readEcefy(int index);
ifc_fn double readEcefz(int index);
ifc_fn int readEcefId(int index);
ifc_fn void writeQuat(int index, double x, double y, double z, double w, int id);
ifc_fn double readQuatx(int index);
ifc_fn double readQuaty(int index);
ifc_fn double readQuatz(int index);
ifc_fn double readQuatw(int index);
ifc_fn int readQuatId(int index);
ifc_fn void init_chassis(iref<ot::vehicle_physics> obj);
ifc_fn void init_vehicle(iref<ot::vehicle_physics> obj);
ifc_fn void update_vehicle(float dt, float throttle, float brake, float steer);
ifc_fn void firething();
ifc_fn void turretthing(float v, float dt);
ifc_fn void mantletthing(float v, float dt);
private:
iref<ot::geomob> m_geomob;
iref<ot::sndgrp> m_sndgrp;
iref<ot::explosions> m_explosion;
iref<ot::environment> m_environment;
iref<ot::canvas> m_canvas;
int _counter;
iref<ot::vehicle_physics> _vehicle;
};
#pragma once
#include "simplugin.hpp"
#include "v8/v8.h"
#include <ot/vehicle_physics.h>
#include <ot/vehicle_cfg.h>
#include <ot/explosions.h>
#include <ot/environment.h>
#include <ot/canvas.h>
#include <ot/dynamic_object.h>
#include <ot/static_object.h>
#include <glm/gtc/quaternion.hpp>
#include <ot/location_cfg.h>
#include <algorithm>
#include <string>
#include <array>
ot::wheel wheel_params;
ot::vehicle_params physics_params;
const double PI = 3.141592653589793;
std::array<double, 100> globalData;
std::array<double, 100> globalLat;
std::array<double, 100> globalLon;
std::array<int, 100> globalId;
std::array<double, 100> globalEcefx;
std::array<double, 100> globalEcefy;
std::array<double, 100> globalEcefz;
std::array<double, 100> globalQuatx;
std::array<double, 100> globalQuaty;
std::array<double, 100> globalQuatz;
std::array<double, 100> globalQuatw;
std::array<int, 100> globalQuatId;
uint fnt ;
uint img ;
uint img2 ;
std::array<double,2> screensize;
double simplugin::readDat(int index)
{
return globalData[index];
}
bool simplugin::writeDat(int index, double data)
{
globalData[index] = data;
return true;
}
void simplugin::writeEcef(int index, double x, double y, double z, int id)
{
globalEcefx[index] = x;
globalEcefy[index] = y;
globalEcefz[index] = z;
globalId[index] = id;
}
double simplugin::readEcefx(int index)
{
return globalEcefx[index];
}
double simplugin::readEcefy(int index)
{
return globalEcefy[index];
}
double simplugin::readEcefz(int index)
{
return globalEcefz[index];
}
int simplugin::readEcefId(int index)
{
return globalId[index];
}
void simplugin::writeQuat(int index, double x, double y, double z, double w, int id)
{
globalQuatx[index] = x;
globalQuaty[index] = y;
globalQuatz[index] = z;
globalQuatw[index] = w;
globalQuatId[index] = id;
}
double simplugin::readQuatx(int index)
{
return globalQuatx[index];
}
double simplugin::readQuaty(int index)
{
return globalQuaty[index];
}
double simplugin::readQuatz(int index)
{
return globalQuatz[index];
}
double simplugin::readQuatw(int index)
{
return globalQuatw[index];
}
int simplugin::readQuatId(int index)
{
return globalQuatId[index];
}
quat Quatmult(quat q, quat p) {
quat r = quat(0, 0, 0, 0);
r.x = q.x * p.w + q.y * p.z + q.w * p.x - q.z * p.y;
r.y = q.z * p.x + q.w * p.y + q.y * p.w - q.x * p.z;
r.z = q.w * p.z + q.z * p.w + q.x * p.y - q.y * p.x;
r.w = -(q.y * p.y + q.x * p.x + q.z * p.z - q.w * p.w);
return r;
}
double rad2deg(double rad)
{
return rad * (180.f / PI);
}
double deg2rad(double deg)
{
return deg * (PI / 180.f);
}
simplugin::simplugin() {
m_sndgrp = ot::sndgrp::create();
}
float axle2coef = 1.f;
glm::quat toQuatRot(float angle, glm::vec3 axis) {
glm::quat returnQuat = glm::quat(0, 0, 0, 0);
returnQuat.x = axis.x * glm::sin(angle / 2);
returnQuat.y = axis.y * glm::sin(angle / 2);
returnQuat.z = axis.z * glm::sin(angle / 2);
returnQuat.w = glm::cos(angle / 2);
return returnQuat;
}
void simplugin::init_chassis(iref<ot::vehicle_physics> obj)
{
iref<ot::geomob> geomob = obj->get_geomob(0);
wheel_params.radius1 = 0.7f;
wheel_params.width = 0.45f;
wheel_params.differential = true;
wheel_params.suspension_max = 0.2f;
wheel_params.suspension_min = -0.35f;
wheel_params.suspension_stiffness = 5.f;
wheel_params.damping_compression = 0.2f;
wheel_params.damping_relaxation = 0.12f;
wheel_params.grip = 1.f;
wheel_params.slip_lateral_coef = 3;
obj->add_wheel_swing("halfaxle_l0", "tire_l0", wheel_params);
obj->add_wheel_swing("halfaxle_r0", "tire_r0", wheel_params);
obj->add_wheel_swing("halfaxle_l1", "tire_l1", wheel_params);
obj->add_wheel_swing("halfaxle_r1", "tire_r1", wheel_params);
obj->add_wheel_swing("halfaxle_l2", "tire_l2", wheel_params);
obj->add_wheel_swing("halfaxle_r2", "tire_r2", wheel_params);
obj->add_wheel_swing("halfaxle_l3", "tire_l3", wheel_params);
obj->add_wheel_swing("halfaxle_r3", "tire_r3", wheel_params);
float a0 = geomob->get_joint_model_pos(geomob->get_joint("tire_l0")).y;
float a1 = geomob->get_joint_model_pos(geomob->get_joint("tire_l1")).y;
float a2 = geomob->get_joint_model_pos(geomob->get_joint("tire_l2")).y;
float a3 = geomob->get_joint_model_pos(geomob->get_joint("tire_l3")).y;
float m = 0.5f * (a2 + a3);
axle2coef = (a1 - m) / (a0 - m);
}
void simplugin::init_vehicle(iref<ot::vehicle_physics> obj)
{
m_geomob = obj->get_geomob(0);
m_explosion = ot::explosions::get();
m_environment = ot::environment::get();
m_canvas = ot::canvas::create("main");
fnt = m_canvas->load_font("ui/default.fnt");
img = m_canvas->load_image("ui/basic.imgset/airspeed");
img2 = m_canvas->load_image("ui/basic.imgset/airspeed_pointer");
screensize[0] = readDat(0); /* x */
screensize[1] = readDat(1); /* y */
_vehicle = obj;
float3 offsetPos = float3(1, 1, 1);
double3 offset = m_geomob->get_world_pos_offset(offsetPos);
glm::quat rotation = m_geomob->get_rot();
auto firstbullet = m_explosion->launch_combo(offset, float3(75), 10, float3(1, 1, 0), float3(0.3, 0.3, 0.3), 7, 0.1, 0.1, 20, true, true, true);
m_explosion->destroy_tracer(firstbullet);
}
coid::uint exps;
quat QuatConjug(quat QuatIn) {
quat Quat = quat(0, 0, 0, 0);
Quat.x = -QuatIn.x;
Quat.y = -QuatIn.y;
Quat.z = -QuatIn.z;
Quat.w = QuatIn.w;
return Quat;
}
float turret_axis = 0, mantlet_axis = 0;
float turret_rot = 0, mantlet_rot = 0, armor_pitch = 0;
void simplugin::turretthing(float v, float dt)
{
turret_axis = -v;
}
void simplugin::mantletthing(float v, float dt)
{
mantlet_axis = v;
}
unsigned int index;
void simplugin::firething()
{
glm::vec3 mdc = glm::vec3(0, 0, 7);
double3 offset = m_geomob->get_world_pos_offset(mdc);
//mantlet_rot = std::max(0.f, std::min(0.5f, mantlet_rot));
_vehicle->log(coid::token((std::to_string(mantlet_rot) + " Hio").c_str()));
float armor_pitch = mantlet_rot;
float armor_azimuth = -turret_rot;
glm::quat cannonQuat = m_geomob->get_rot();
glm::quat unitquat = glm::quat(0, 1, 0, 0); // default muzzle orientation
glm::quat pitchquat = toQuatRot(armor_pitch, glm::vec3(1, 0, 0));
glm::quat headquat = toQuatRot(armor_azimuth, glm::vec3(0, 0, 1));
glm::quat tempquat = Quatmult(pitchquat, Quatmult(unitquat, QuatConjug(pitchquat)));
tempquat = Quatmult(headquat, Quatmult(tempquat, QuatConjug(headquat)));
glm::quat plasmaquat = Quatmult(cannonQuat, Quatmult(tempquat, QuatConjug(cannonQuat)));
glm::quat bulletquat = Quatmult(cannonQuat, Quatmult(headquat, Quatmult(pitchquat, unitquat)));
auto bullet = ot::static_object::create("outerra/crate/crate", offset, bulletquat);
m_explosion->launch_tracer(offset, float3(827 * plasmaquat.x, 827 * plasmaquat.y, 827 * plasmaquat.z), 1, glm::vec3(1, 1, 0), 0.5, 0.2, 0, 0, 0, bullet->get_geomob(0)->get_eid(), 1);
}
float engine_force = 27000.f;
float brake_force = 28000.f;
float wheel_friction = 200.f;
void simplugin::update_vehicle(float dt, float throttle, float brake, float steer)
{
m_canvas->draw_text(fnt, screensize[0]/2, screensize[1] / 2, "ciao", uchar4(0, 255, 0, 255));
float speed_kmh = _vehicle->speed();
float applied_engine_force = engine_force * abs(throttle);
_vehicle->wheel_force(-1, applied_engine_force);
_vehicle->steer(0, steer);
_vehicle->steer(1, steer);
_vehicle->steer(2, steer * axle2coef);
_vehicle->steer(3, steer * axle2coef);
float applied_wheel_friction = brake_force * brake + wheel_friction;
_vehicle->wheel_brake(-1, applied_wheel_friction);
for (ot::impact_info i : m_explosion->landed_tracers())
{
m_explosion->make_crater(i.wpos, 10);
}
turret_rot += turret_axis * 0.4 * dt;
mantlet_rot += mantlet_axis * 0.1 * dt;
}
-
Yes, you're right, you said that the problem consisted in the continuous call of the plugin interface but I had forgotten about it fixing myself on the immediate aspects of the repeated creations ...
However...
Another possible even more esoteric trick ...
While waiting for Cameni to inspect your dll code, which has assured us that there is no interface call limit imposed by Outerra, we could try another way.
Instead of considering the characteristic of sharing the variables by instances of the same model as deleterious, we can try to exploit their advantages.
Instead of "this.plugin" we reuse the "plugin" variable which will go global for all missiles.
We put a preliminary check on the line of code that requires the interface.
function init_vehicle () {
...
if (! plugin) {
plugin = this. $ query_interface ('xt :: js :: global_variables.get');
}
...
}
The first missile, finding the variable still undefined, will make the call to the plugin interface, but all the others, created subsequently, will find the variable already defined and should not make the call but only use the "plugin" variable to read or write the values you intend to share.
Since the call of a single missile does not block the program, the problem could be solved.
-
OK andfly I will try.
For cameni: note that the same happens with the default example vehicle dll downloaded from github when I add this line of code
function init_vehicle(){
$plugin = this.$query_interface('xt::js::engine.create', this);
}
to the missile JS and firing the missile from my tank through
world.create_instance("outerra/missile/missile", ecef, bulletquat, false);
I can fire two missiles from the tank but when firing the third one outerra crashes.
Why two ? I was thinking that vehicles can be entered in two ways..first without animated character and second entry is with animated character...so there is "two" ways vehicles can be entered and two "vehicles" that I can fire. maybe the world.create_instance("outerra/missile/missile", ecef, bulletquat, false) gets confused with these ways of entering vehicles. while F3 spawn doesn't
when I spawn the missile from F3 it always enters it "without animated character" ..but that's just a crazy theory as I can not imagine any reason of the "two" times working...and why there is no problem with "JSBSIM aircrafts" missiles
#pragma once
#include <comm/intergen/ifc.h>
//wrap in special comments to inject into the generated interface header too
// can also use /*ifc{ ... }ifc*/ to include only in the client header
//ifc{
#include <ot/vehicle_physics.h>
//}ifc
///Plugin's base implementation class, exposing a xt::engine interface
class simplugin
: public policy_intrusive_base
{
public:
simplugin(const iref<ot::vehicle_physics>& vehicle);
///Interface declaration: [namespace::]name, path
ifc_class(xt::engine, "ifc/");
///Interface creator
ifc_fn static iref<simplugin> create(const iref<ot::vehicle_physics>& vehicle);
//interface function examples
ifc_fn void set_value( int x ) { _value = x; }
ifc_fn int get_value() const { return _value; }
ifc_fn void do_something();
private:
int _value, _counter;
iref<ot::vehicle_physics> _vehicle;
};
#pragma once
#include "simplugin.hpp"
#include <ot/vehicle_physics.h>
////////////////////////////////////////////////////////////////////////////////
simplugin::simplugin(const iref<ot::vehicle_physics>& vehicle)
: _value(0), _counter(0)
{
_vehicle = vehicle;
}
////////////////////////////////////////////////////////////////////////////////
iref<simplugin> simplugin::create(const iref<ot::vehicle_physics>& vehicle)
{
DASSERT_RET(!vehicle.is_empty(), 0);
return new simplugin(vehicle);
}
////////////////////////////////////////////////////////////////////////////////
void simplugin::do_something()
{
//blink lights
if (_vehicle)
_vehicle->light_mask(UMAX32, (++_counter & 64) != 0);
}
-
SOLVED !!
andfly your trick works !!
If I use inside the missile JS
if (! $plugin) {
$plugin = this.$query_interface('xt::js::engine.create', this);
}
or
if (! $plugin) {
$plugin = this.$query_interface('xt::js::global_variables.get');
}
I can now fire as many configurable missiles as I want ! No more crashes !
THANKS andfly !
Also learned something new: seems that "objects" (or what is the plugin ? an interface ? ...I am ashamed to be so ignorant but willing to learn) created inside JS appear to be global unless we put this. in front ..will experiment if this can be exploited and if it is also valid for other objects? variables ? .
(https://i.postimg.cc/L41Vb2HL/multimissiles.jpg) (https://postimg.cc/dDJd7MZV)
-
Mmm ...
Verify that $plugin is truly shared and that all missiles can access the plugin.
To my knowledge only vehicle and boat models (possessing an init_chassis function that is performed a unique way and only for the first instance) can share variables.
If the variable is also shared by instances of a Jsbsim model, a new magnificent scenario opens which I am not aware of and which widens the possibilities of interaction.
The curiosity was whether the trick worked with instances of a vehicle model ...
However I thought it would be interesting to do other tests too.
Try to create (with create_instance), in the main model script (the plane), a dozen different models (missile, bomb, tank, etc.), then NOT instances of the same model, which try to recall the interface of the plugin and check if it gets to the block of the program.
Then, also, try to create successive instances of the same missile (as originally) but, in the missile code, request the interface of one of the main modules of Outerra (such as world or canvas or explosion etc ..) and check if there is they are problems.
We do not know how the code relating to numerous instances of the same model is compiled and stored. While there seems to be no limit to the amount of mathematical and graphical code there may be a particular procedure for recording the connections to the interfaces that could possibly be "unique" for each model and the subsequent attempt to redefine them in each instance could create problems ...
If, however, we notice substantial differences in the treatment of interface calls between personal plugins and Outerra modules, then ... our plugins are missing something or have imperfections that differentiate them from the well-structured Outerra code and limit their potential.
On the other hand .... if even the request for an interface to an Outerra module by successive instances of the missiles, causes the crash ... perhaps the responsibility could be attributed to the world_create_instance method which would not carry out a complete creation like that carried out by creating new instances directly from the main menu of Outerra ...
The fact that from the Outerra menu you can create a large number of instances of the same model, without any problem, suggests ...
-
Yeah, like I wrote yesterday: vehicles share the JS context. That means you overwrote the $plugin variable each time you set to it in init_vehicle, which runs for each new vehicle but in the same JS context. The old value (a reference to interface) got orphaned and thrown to he garbage collector. Not sure why it crashed, but perhaps something to do with the global plugin interface being repeatedly created and destroyed.
Do it just once in init_chassis.
(By setting it into this.$plugin you made a copy for each vehicle instance, which works but it's a waste for global/shared stuff).
Also we need to implement a better crash catcher that shows which plugin crashed, otherwise we'd be getting "OT crashed" reports all the time :)
-
Do it just once in init_chassis.
Here is the egg of Columbus.
The simplest and most elegant solution. 8)
-
Right !
but about "vehicles share the same JS context" : i tried to set a variable var $myvariable =100; in one vehicle (the t817 of outerra root directory) and then read it in a vehicle of another type (my tank in my packages folder) but it does get $myvariable undefined. If I remember well the context of shared variables was just for HTML (like config.HTML) ..maybe just vehicles of same type.
for andfly: yes I can create lots of different models each one using the same plugin. worked fine !
this.ot_world.create_instance("outerra/t817/t817", this.geom.get_world_pos_offset({x:+0, y:0, z:-20}), this.geom.get_rot(), false);
this.ot_world.create_instance("outerra/c172/liveries/Red/Red", this.geom.get_world_pos_offset({x:+40, y:0, z:1}), this.geom.get_rot(), false);
this.ot_world.create_instance("outerra/missile3/missile3", this.geom.get_world_pos_offset({x:-4, y:0, z:-1}), this.geom.get_rot(), false);
this.ot_world.create_instance("outerra/missile2/missile2", this.geom.get_world_pos_offset({x:-40, y:0, z:-1}), this.geom.get_rot(), false);
-
It does not work with different vehicles.
If you set a variable on the t817, share the variable with all the other instances of t817 (and only t817) that you call from the Outerra menu or even from a script that uses the world_create_instance.
Apparently the plugin does not suffer from repeated calls to its interface made by different vehicles ...
Perhaps the problem is precisely the repetition of calls made by different instances of the same vehicle ??
:( =| =|
-
About shared JS context for vehicles , yes I now checked that variables are indeed shared by the SAME type of vehicle..great !!
A check for planes shows that plane JS context does not share variables among planes, not even of the same type. Will live with it.
So I modified the missiles to get the reference to the plugin interface just in the init_chassis for "vehicle type missiles" to avoid repeated calls to get it.
For "JSBSIM-aricraft-type missiles" while there is just initialize_reload apparently there is also no need to do the check as it seems plane JS context does not share variables with anything and so there is no risk of repeated calls.
... Works fine and i can still create as many instances as I want from the jet's or the tank's scripts.
regarding the question wether the created objects can use simultaneously also the outerra normal interfaces the answer is yes. In my missile code I already request the world and explosions interface.
finally also I can spawn different jets which all can launch missiles using the same plugin, so not only a script can create objects which reference the plugin but different scripts of any kind (same vehicle or different vehicle or plane or boat) all can reference the plugin and create objects that reference the plugin...no limitation at all in no direction !
So finally everything is fine and we have lots of working new possibilities to share info among vehicles/planes etc.. !! Its now time to exploit all these possibilities !
function init_chassis(){
$plugin = this.$query_interface('xt::js::global_variables.get');
}
function initialize(reload){
if (! $plugin) {
$plugin = this.$query_interface('xt::js::global_variables.get');
}
}
-
Bravo, very good!
Big work !! :D :D :D
-
well..its your interest in the issue that helped to solve everything very quickly ...so bravo to you ! :) :) :)
Wish you could return active in creating new mods