Outerra forum

Please login or register.

Login with username, password and session length
Advanced search  

News:

Outerra Tech Demo download. Help with graphics driver issues

Pages: 1 ... 9 10 [11]

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

cameni

  • Brano Kemen
  • Outerra Administrator
  • Hero Member
  • *****
  • Posts: 6663
  • Pegs is clever, but tae hain’t a touch sentimental
    • outerra.com
Re: Limits of functionally designed models ?
« Reply #150 on: May 27, 2014, 10:30:14 am »

Simply do not call the .changed(dt) method on it when paused.
Logged

ZeosPantera

  • ||>>-Z-<<||
  • Global Moderator
  • Hero Member
  • *****
  • Posts: 2518
  • #1 Outerra Fan Boy
    • My Youtube
Re: Limits of functionally designed models ?
« Reply #151 on: May 27, 2014, 11:55:43 am »

The instant 0 positioning when the tires leaves the ground is why vehicles LOOK odd when driving in outerra. They always seem to be on the cusp of taking off and the wheels move un-naturally. Next we have to get some MASS on the wheels to help with momentum and balance.
Logged
"Fear accompanies the possibility of death, Calm shepherds its certainty" - General Ka Dargo

PytonPago

  • Hero Member
  • *****
  • Posts: 2262
  • It´s way too complex, dont let me try to explain !
Re: Limits of functionally designed models ?
« Reply #152 on: May 27, 2014, 12:20:45 pm »

Simply do not call the .changed(dt) method on it when paused.

 ... you mean, doing some On/Off variable where at off the .changed(dt) wont be applied and reapplied, like this one little function has ? http://whatanswered.com/websites-javascript/javascript-simple-start-stop-timer.php

The instant 0 positioning when the tires leaves the ground is why vehicles LOOK odd when driving in outerra. They always seem to be on the cusp of taking off and the wheels move un-naturally. Next we have to get some MASS on the wheels to help with momentum and balance.

Yes, sometimes it behaves odd. Some flow movement from the last contact height to the zero position (not the model one, but the suspension one) would be needed. Also, "power" at climbing is not real. Sometimes should wheels slip when the climb is too steep to move forward. But i wouldnt take it as a so "primary" flaw yet in development. Also, maybe it will be unnecessary when some wet terrain-deformation hits OT. :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.

cameni

  • Brano Kemen
  • Outerra Administrator
  • Hero Member
  • *****
  • Posts: 6663
  • Pegs is clever, but tae hain’t a touch sentimental
    • outerra.com
Re: Limits of functionally designed models ?
« Reply #153 on: May 27, 2014, 01:39:19 pm »

... you mean, doing some On/Off variable where at off the .changed(dt) wont be applied and reapplied, like this one little function has ? http://whatanswered.com/websites-javascript/javascript-simple-start-stop-timer.php
Not sure what you want the pausing for, but the integrator is technically a variable that accumulates value depending on elapsed time and the desired action. If you do not call the "changed" method, the internal value doesn't change.

What is cabcount in your script? Because it's used as a global variable, therefore all instances of vehicles use the same variable. Should be this.cabcount if you want it to pertain to a single vehicle instance.
On the other hand, some things are global and you are creating them for each instance - for example vehicle joints.
Logged

PytonPago

  • Hero Member
  • *****
  • Posts: 2262
  • It´s way too complex, dont let me try to explain !
Re: Limits of functionally designed models ?
« Reply #154 on: May 27, 2014, 02:06:25 pm »

The cabcount was used for a hit-counter - for selecting a specific thing to open. If yore looking at my script - see the integrator opening stuff at the :

Code: [Select]
//invoked each frame to handle the inputs and animate the model
function update_frame(dt, engine, brake, steering) {
 
    // Object rotations

    // Door windows 

  var ax = {z:-1};

  if(this.d1.changed(dt) && cabcount == 4){
    this.geom.move_joint_orig(this.dlw, {x:0,y:0,z:-this.d1.value});
  }


...

    // Front pannel cases and hood

   var ax = {x:-1};

  if(this.d5.changed(dt) && cabcount == 1){
    this.geom.rotate_joint_orig(this.cc, -this.d5.value, ax);



May be a rough way to do, but works for me ...
The pause would be used when the engine is off - when its on the counting would go on. On this variable,  would specify a fuel-consumption script dependent at EngineRPM and actual gear setting. Also another one, for when the vehicle moves (vehicle speed bigger than 0) to make a traveled distance meter (depending on actual speed and time driven) for the front-panel rotameter.
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: 6663
  • Pegs is clever, but tae hain’t a touch sentimental
    • outerra.com
Re: Limits of functionally designed models ?
« Reply #155 on: May 27, 2014, 03:40:51 pm »

But you don't need the axis_integrator for that. Just initialize another variable in init_vehicle, like this.engine_on=false, and then in function engine(start) { this.engine_on=start; ... }
Then in update() you'll do the counting:
Code: [Select]
if(this.engine_on)
    this.fuel -= Lper_second*dt;
... provided this.fuel was initialized to some starting value.

Same with the traveled distance, except there you can just unconditionally do
Code: [Select]
this.distance += this.speed()*dt;
.. to get the distance in meters.
Logged

PytonPago

  • Hero Member
  • *****
  • Posts: 2262
  • It´s way too complex, dont let me try to explain !
Re: Limits of functionally designed models ?
« Reply #156 on: May 27, 2014, 03:53:11 pm »

But you don't need the axis_integrator for that. Just initialize another variable in init_vehicle, like this.engine_on=false, and then in function engine(start) { this.engine_on=start; ... }
Then in update() you'll do the counting:
Code: [Select]
if(this.engine_on)
    this.fuel -= Lper_second*dt;
... provided this.fuel was initialized to some starting value.

Same with the traveled distance, except there you can just unconditionally do
Code: [Select]
this.distance += this.speed()*dt;
.. to get the distance in meters.

 ... just "*dt" the value ? ... i still dont grasp fully how that differential works (per frame or 1/1000 of a sec). Might as well done something else wrong in that older attempt ... have to investigate that. (cant quite turn my head around when i dont see the time development in things)
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: 6663
  • Pegs is clever, but tae hain’t a touch sentimental
    • outerra.com
Re: Limits of functionally designed models ?
« Reply #157 on: May 27, 2014, 04:08:01 pm »

dt is the elapsed time since the last call. With any rate-type value like velocity [m/s] or fuel consumption [liters/s] you can get the distance or fuel consumed since the last call by multiplying it with dt.
Logged

PytonPago

  • Hero Member
  • *****
  • Posts: 2262
  • It´s way too complex, dont let me try to explain !
Re: Limits of functionally designed models ?
« Reply #158 on: May 28, 2014, 02:01:06 am »

dt is the elapsed time since the last call. With any rate-type value like velocity [m/s] or fuel consumption [liters/s] you can get the distance or fuel consumed since the last call by multiplying it with dt.

 ... damned, works like charm - i should throw away some time-dimension concepts when playing white scripts. But still - if im right, the last call is dependent on the CPU computing speed and the stuff it has to do whyle going trough the script-stuff ? (yes, its probably not so much a difference) ... dont want to see the corrections for that for real-life super precise applications (they must go crazy at the CERN, both mathematicians and programmers).

Also a new idea - for turning-blinkers, you need to know if youre turning. I could use a script depending on the "seering" variable (and probably will do that, till i think of some separate blinker key-use, but still would need go trough them all as i plan to adjust even revers-mirrors and a lot of other stuff too later on), but when a script would need to know, if ya holding the turning-left/right, front, back key on the keyboard, how do they look like ? Is there too an action code for them ? (http://xtrac.outerraworld.com/trac.fcgi/wiki/action_code)
« Last Edit: May 28, 2014, 02:26:01 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.

cameni

  • Brano Kemen
  • Outerra Administrator
  • Hero Member
  • *****
  • Posts: 6663
  • Pegs is clever, but tae hain’t a touch sentimental
    • outerra.com
Re: Limits of functionally designed models ?
« Reply #159 on: May 28, 2014, 02:26:36 am »

No, this is currently handled outside of the script (together with steering wheel return to zero upon release). But for an advanced steering control we probably should add them.
Logged
Pages: 1 ... 9 10 [11]