Outerra forum

Please login or register.

Login with username, password and session length
Advanced search  

News:

Download Outerra Tech Demo. Unofficial Outerra Discord server, MicroProse Discord server for OWS.

Pages: 1 ... 4 5 [6] 7 8 ... 11

Author Topic: Limits of functionally designed models ?  (Read 118571 times)

PytonPago

  • Hero Member
  • *****
  • Posts: 2284
  • It´s way too complex, dont let me try to explain !
Re: Limits of functionally designed models ?
« Reply #75 on: September 12, 2013, 10:08:34 am »

AWW !!! Now i got it ! Thanks a LOT Cameni ! Been working on this three days and was depressed as a mosquito on synthetic blood. Here is my way of doing it for all people to see :

Code: [Select]
//handle extra actions

 
function action(k,v,dt)
{
    switch(k){
  case ATurretX: this.turx.set(v); break;
  case ATurretY: this.tury.set(v); break;
 
   
//this.log_inf("aOpenBool " + aOpenBool);
     
   // Hood oppening
     
  case AOpen: {
   
        if (v == 1 && aOpenBool == true) {
        this.geom.rotate_joint_orig(this.cc, 0, {x:1,y:0,z:0});
        }
   
         
      if (v == 1 && aOpenBool == false) {
aOpenTime = aOpenTime + (2 * 1);
this.log_inf("aOpenBool " + aOpenTime);
        this.geom.rotate_joint_orig(this.cc, 1.75, {x:1,y:0,z:0});
        }       
       
        if (v == 1) {
if (aOpenBool == false) {aOpenBool = true;}
else{aOpenBool = false;}
}
   
     }break;
         

   
 
 
 
 
  }

}

Actually just needed to change the "value" for "v" everywhere and giving all the stuff into - "case AOpen: { ... }break;" . So simple and so much hair lost till today ! :D Other question doe:

      - headlights-script, its just added there, but light-sources not yet done in OT, is that right ? (well, if i dont do that the Billboard (texture) way at least for the bulbs), anyway will try to add some honk-honk sound, finally some fun stuff into my model !

      - Is there a way to fix some of the views to a certain mesh ? I mean, if i will change the second-view position to be at the BM-21 targeting arm and i rotate it around, i will just stay at there whyte the camera, whyle the ocular goes away from me. I would like to change that position in accordance to the mesh im rotating. Maybe just make an addition to the action codes or somewhere else to define the mesh i chose and the camera position will update every image around its pivot whyte the mesh (maybe even have the "x:0, y:1, z:1" to determine, witch rotations from the mesh-rotation it should apply to the camera). I can think of a way of scripting this into the vehicle-script, but i think more people would like to use this (mostly mil-simmers find it useful).

So could be there the force app added to the scripts too later in some nice way ? ("AFire: this.geom.force_joint_orig ("mesh", "force strength", {x:0.87, y:0.25, z:0.64} - to define the force vector from the mesh-pivot point)")

P.S.: Sorry for pushing so much for new apps. : )
« Last Edit: September 12, 2013, 10:45:47 am by PytonPago »
Logged
We are still undeveloped as long as we don´t realize, that all our science is still descriptive, and than beyond that description lies a whole new world we just haven´t even started to fully understand.

PytonPago

  • Hero Member
  • *****
  • Posts: 2284
  • It´s way too complex, dont let me try to explain !
Re: Limits of functionally designed models ?
« Reply #76 on: September 12, 2013, 02:20:09 pm »

Gave up my little progress up in the Ural 4320-31 thread to download and try ... i took Murkz´s Luchs sound for the turret. Hope he does not kill me for that.  ::)
Logged
We are still undeveloped as long as we don´t realize, that all our science is still descriptive, and than beyond that description lies a whole new world we just haven´t even started to fully understand.

cameni

  • Brano Kemen
  • Outerra Administrator
  • Hero Member
  • *****
  • Posts: 6721
  • No sense of urgency.
    • outerra.com
Re: Limits of functionally designed models ?
« Reply #77 on: September 12, 2013, 03:23:38 pm »

- Is there a way to fix some of the views to a certain mesh ? I mean, if i will change the second-view position to be at the BM-21 targeting arm and i rotate it around, i will just stay at there whyte the camera, whyle the ocular goes away from me. I would like to change that position in accordance to the mesh im rotating. Maybe just make an addition to the action codes or somewhere else to define the mesh i chose and the camera position will update every image around its pivot whyte the mesh (maybe even have the "x:0, y:1, z:1" to determine, witch rotations from the mesh-rotation it should apply to the camera). I can think of a way of scripting this into the vehicle-script, but i think more people would like to use this (mostly mil-simmers find it useful).
This will come later, a way to attach camera points to model nodes.

Quote
So could be there the force app added to the scripts too later in some nice way ? ("AFire: this.geom.force_joint_orig ("mesh", "force strength", {x:0.87, y:0.25, z:0.64} - to define the force vector from the mesh-pivot point)")
Force? I don't know what you mean, what do you want to achieve?
Logged

PytonPago

  • Hero Member
  • *****
  • Posts: 2284
  • It´s way too complex, dont let me try to explain !
Re: Limits of functionally designed models ?
« Reply #78 on: September 12, 2013, 04:25:41 pm »

Quote from: cameni
Quote
So could be there the force app added to the scripts too later in some nice way ? ("AFire: this.geom.force_joint_orig ("mesh", "force strength", {x:0.87, y:0.25, z:0.64} - to define the force vector from the mesh-pivot point)")
Force? I don't know what you mean, what do you want to achieve?

The force app witch we discussed much earlier ... where talking about an analog to the crater-creator, just giving some force-push to the objects. I thought it would be interesting if at fire, the vehicle would not use some animation for the back-kick of rockets, but a real force ... just old debate stuff thoughts. Dont have to mind that one.  ;)
Logged
We are still undeveloped as long as we don´t realize, that all our science is still descriptive, and than beyond that description lies a whole new world we just haven´t even started to fully understand.

cameni

  • Brano Kemen
  • Outerra Administrator
  • Hero Member
  • *****
  • Posts: 6721
  • No sense of urgency.
    • outerra.com
Re: Limits of functionally designed models ?
« Reply #79 on: September 13, 2013, 02:49:08 am »

That's going to be a part of the projectile firing system, automatically exerting kickback force at the point from where it was fired.
But there's also a way to produce arbitrary forces, for example in the upcoming support for boats the propelling is done as an extra force.
Logged

PytonPago

  • Hero Member
  • *****
  • Posts: 2284
  • It´s way too complex, dont let me try to explain !
Re: Limits of functionally designed models ?
« Reply #80 on: September 13, 2013, 03:14:59 am »

... for example in the upcoming support for boats the propelling is done as an extra force.

Sounds nice ... the water will have some water-wolume-based counter forces to the boats ?
Logged
We are still undeveloped as long as we don´t realize, that all our science is still descriptive, and than beyond that description lies a whole new world we just haven´t even started to fully understand.

cameni

  • Brano Kemen
  • Outerra Administrator
  • Hero Member
  • *****
  • Posts: 6721
  • No sense of urgency.
    • outerra.com
Re: Limits of functionally designed models ?
« Reply #81 on: September 13, 2013, 03:25:18 am »

Yes, computed from provided approximate volume shape. Boats are technically ground vehicles, just with extra params. You can easily make an amphibious vehicle too.
Logged

John514

  • Hero Member
  • *****
  • Posts: 543
  • Certified TARDIS driver.
Re: Limits of functionally designed models ?
« Reply #82 on: September 13, 2013, 04:51:52 am »

Sound really good! Will the same parameters apply for hand-held guns as well?
Also, how will sails work in ships?
Logged
You mustn't be afraid to dream a little bigger, darling

Note: I do not claim to know everything.
I just like to help people around the forum.

cameni

  • Brano Kemen
  • Outerra Administrator
  • Hero Member
  • *****
  • Posts: 6721
  • No sense of urgency.
    • outerra.com
Re: Limits of functionally designed models ?
« Reply #83 on: September 13, 2013, 05:18:37 am »

Sound really good! Will the same parameters apply for hand-held guns as well?
It may, but it would require a proper character animation or IK.

Quote
Also, how will sails work in ships?
I guess .. one can compute the forces from wind and area and orientation and just apply them.
Plus some animations ...
Logged

PytonPago

  • Hero Member
  • *****
  • Posts: 2284
  • It´s way too complex, dont let me try to explain !
Re: Limits of functionally designed models ?
« Reply #84 on: September 13, 2013, 06:07:59 am »

You can easily make an amphibious vehicle too.

Well, have to start making a BTR-80 for testing when it comes.  :D
Logged
We are still undeveloped as long as we don´t realize, that all our science is still descriptive, and than beyond that description lies a whole new world we just haven´t even started to fully understand.

PytonPago

  • Hero Member
  • *****
  • Posts: 2284
  • It´s way too complex, dont let me try to explain !
Re: Limits of functionally designed models ?
« Reply #85 on: September 13, 2013, 09:42:48 am »

Got a question about : http://xtrac.outerraworld.com/trac.fcgi/wiki/geomob

 - i want to turn certain parts invisible and just cant find out, where to put the scripts .. as i understood from the Sh-2 script, the "set_mesh_visible_id" should be at "function update_frame" section, and "get_mesh_id"  at the "init_chasis" part (when given to "init_vehicle", he cant get it and says it hast the geometry defined), bud doesnt work straight at that .. do i have to define some variable (the mesh itself)  ? I tried it like the shavrov has whyte some id variables set, but no real thing happens.
Logged
We are still undeveloped as long as we don´t realize, that all our science is still descriptive, and than beyond that description lies a whole new world we just haven´t even started to fully understand.

cameni

  • Brano Kemen
  • Outerra Administrator
  • Hero Member
  • *****
  • Posts: 6721
  • No sense of urgency.
    • outerra.com
Re: Limits of functionally designed models ?
« Reply #86 on: September 13, 2013, 10:36:27 am »

get_mesh_id can be anywhere, but it's usually in init_chassis because you need to get the id of mesh just once, and then you store it in a global variable. Then you can use the id with functions that take mesh id as argument, usually in update_frame or in action.
Logged

PytonPago

  • Hero Member
  • *****
  • Posts: 2284
  • It´s way too complex, dont let me try to explain !
Re: Limits of functionally designed models ?
« Reply #87 on: September 13, 2013, 12:10:03 pm »

...  and then you store it in a global variable.

So something like :
Code: [Select]
...

var mklt
mklt = geom.get_mesh_id('mesh_name');   // (doesnt it need the gemetry joint mentioned too ?)

...

and then in update_frame section:

if (something) {
geom.set_mesh_visible_id(mklt, true);
}
else {
geom.set_mesh_visible_id(mklt, false);
}
Logged
We are still undeveloped as long as we don´t realize, that all our science is still descriptive, and than beyond that description lies a whole new world we just haven´t even started to fully understand.

PytonPago

  • Hero Member
  • *****
  • Posts: 2284
  • It´s way too complex, dont let me try to explain !
Re: Limits of functionally designed models ?
« Reply #88 on: September 15, 2013, 04:06:42 am »

I found out why it didnt work ... too much "geomob´s ()" had to rearrange it so, that they dont interfere. Now trying to work out the wheel damage system somehow, anyway there is one little thing i would like to do too - as per my script :

Code: [Select]
    steering *= 0.4; // defines steering constant for wheels     
  this.steer(0, steering); // defines witch wheel is turning, and witch script it uses
  this.steer(1, steering);
 
    this.geom.rotate_joint_orig(this.IntFL, steering, {x:0,y:0,z:1}); //rotation restriction for the internal front wheel part
    this.geom.rotate_joint_orig(this.IntFR, steering, {x:0,y:0,z:1});

... i have a wheel composing of the wheel and its internal part (of two components too ... see pics down the reply) and scripted the z axis turning of the internal part as the wheel does. Now i would like to add to it its height according to the wheel.
- Is there a way to get the actual deviation from its original position for me to implement it to the internal part ?
 - Or some way to limit the movement of some axis (actually just the x axe rotation) of a part under the wheel hierarchy ?


Another interesting thing :

I was giving the hidding-script a test and i scripted it like this :

Code: [Select]
  case AOpen: {
   
    //this.log_inf("aOpenBool " + aOpenBool);
   
          // for hidding wheel emptyes of the wheel-change script
   
                        //FL
      if (v == 1 && aOpenBool == true) {
         this.geom.set_mesh_visible_id(this.fl_id, true);
        this.geom.set_mesh_visible_id(this.fle_id, false);
}
      if (v == 1 && aOpenBool == false) {
         aOpenTime = aOpenTime + (2 * 1);
this.log_inf("aOpenBool " + aOpenTime);
         this.geom.set_mesh_visible_id(this.fl_id, false);
        this.geom.set_mesh_visible_id(this.fle_id, true);
}

...


So the whole wheel should hide and the internal part appear, but even when there is just three parts :



 ... the middle part of the wheel yet still is there ? (Wheel_FrontR)



I know that i done the wheel by making the inner part and the wheel resin separately (both whyte an separate material), but joined them into one mesh (nothing stays behind in a separate mesh), so there is no reason to be left behind, yet, still it does ... so, is it possible, that the fact, that the inner part has an other material than the resin wheel makes it to ignore in script ? - leaving it behind (means rendering one of the materials anyway) ?
« Last Edit: September 15, 2013, 04:12:28 am by PytonPago »
Logged
We are still undeveloped as long as we don´t realize, that all our science is still descriptive, and than beyond that description lies a whole new world we just haven´t even started to fully understand.

PytonPago

  • Hero Member
  • *****
  • Posts: 2284
  • It´s way too complex, dont let me try to explain !
Re: Limits of functionally designed models ?
« Reply #89 on: September 15, 2013, 04:24:39 am »

Just done a test ... left wheel got one material and the other the second ... both dissipated completely, but the other ones, composing of two materials still leave one there ...




second test - have stripe-materialed the mesh of the wheel:



... seems it has a problem whyte hiding multiple-material meshes.
« Last Edit: September 15, 2013, 04:32:09 am by PytonPago »
Logged
We are still undeveloped as long as we don´t realize, that all our science is still descriptive, and than beyond that description lies a whole new world we just haven´t even started to fully understand.

Pages: 1 ... 4 5 [6] 7 8 ... 11