Naev Development Blarg (Page 19)

• 0.5.0 Status Update

  BY BOBBENS, ON DECEMBER 21ST, 2010

  We haven’t posted in a while, so I decided to update even though we don’t have anything spectacular done (depending on your definition of spectacular). So what is going on? As you may know the current development and broken branch is the balance branch (This branch is now long dead, unsure of the commit sha). This branch is active and will mangle your saves if you load it. Why? It’s caused by the implementation of the weapon rant, which makes it so all the weapon are changed. Some retain their name, but most get lost in the transition. This is unavoidable and will happen to everyone once it’s merged back, but it shouldn’t happen again then.

  Other things, ewarfare has more or less been balanced. We’ve introduced another parameter for heat. So the more your ship heats up, the more visible it is. The equations are also tweaked in such a way they make more sense and are cooler overall. Also turrets finally use it, so you can’t track a fighter with a long range anti-capship turret. This all may still need fine tuning but it is working quite well.

  Another major change which has broken a lot of missions is the fact we’ve changed the time model. Previously time only changed when you landed or jumped. Now time will change while flying too. That means that slower ships will waste more time in system while jump times will be very similar. This sort of makes everything more interesting and realistic which is quite cool. However it means we have to revamp all our cargo missions which we want to rethink anyway when we do economics. For now we’ll probably keep them similar to how they’ve always been, but in the future we’ll change it.

  Finally mentioning some changes we want to do. With google being more and more evil, we’ve been thinking of completely foregoing both google code and google groups. We’re working on having our own wiki which shouldn’t take too long to be available. If someone is really interested in helping out we can sort of speed it up and spread the half-finishedness. It still needs lots of love. Secondly we’re considering the possibility of also hosting our own mailing list, but we’ll see about that. That hasn’t even been started.

  Closing words on the release. The original intention was to release end of 2010, however we believe it is much more important to have a good solid release than a half-finished rushed release that will need a dozen bugfixes to be playable. We would like to still release at the end of 2010, but chances are we’ll just do a beta at the start of 2011. There’s still much to do, need to finish some stuff and then fix everything we broke. To speed up the release we are trying to delay changes that aren’t fundamental, however we also want this release to sort of establish the maturity of Naev, but chances are 0.6.0 will be the true maturity once we get there.

  tl;dr We’ll release when it’s ready :)

  NOTE This screenshot has been lost to time :(

  ---

• Correct Physics

  BY BOBBENS, ON NOVEMBER 23RD, 2010

  WARNING: TECHNICAL POST

  After much insistence on Deiz that something was wrong since we needed a hack to get ships to properly display 100% speed, we’ve finally found the culprit. Some old code of mine that what it did was:

  c void limit_speed( Vector2d* vel, const double speed, const double dt ) { double vmod; vmod = VMOD(*vel); if (vmod > speed) /* shouldn't go faster */ vect_pset( vel, (vmod-speed)*(1. - dt*3.) + speed, VANGLE(*vel) ); }

  What does this mean? It may seem like a good idea to limit the speed by modulating the velocity directly. There is also a dt in there to try to make it not frame dependent. However let’s analyze the consequences.

  The important question is: what is the maximum velocity? The way stuff is done we’re cascading the limit_speed with the physics model. We can simplify it to an euler integration (it’s actually runge-kutta but I’ll talk about that a bit latter):

  v_1 = v_0 + a dt

  Everyone should be familiar with that. I won’t go into details from where that comes from. Basically it means that the current velocity is the last velocity plus the acceleration times the time that passed from the last instant. This is then chained to the limit_speed which does:

  v = (v_1 - v_{max})(1 - 3dt)

  So we can write the composite form as:

  v = (v_0 + a dt - v_{max})(1 - 3dt) = v_0 + a dt - v_{max} - 3 dt v_0 - 3 a dt^2 + 3 dt v_{max}

  Now we can see the problem. What should be linearly dependent on the dt to cancel out the dependency on the frame rate is now quadratically dependent (notice 3 a dt^2). This means that the velocity now does indeed depend on the frame rate. That’s bad. The physics model shouldn’t depend on the frame rate. How can we fix that?

  The most logical and simple solution would be instead of hardcoding a limit_speed function outside of the physics engine to integrate it. What does the physics engine work with? Forces. What should we do? Create a virtual force dependent on velocity.

  A bit on our physics engine. The physics in NAEV is modelled as differential equations and is solved generally with Runge-Kutta. It all sounds really complicated but it isn’t too much. If you want to go into detail take a look at src/physics.c.

  First the philosophical meaning of this force. What does it represent? Why do ships have speed limits? This limit represents the ship’s stabilization systems. To allow the ships to have artificial gravity (the ones that do) and fly around so well with turning, they need complex stabilization systems. So what we’re modelling is some sort of drag force.

  Now onto the force itself. After much discussion ranting and throwing of equations we finally managed to model it. The current model is:

  f_{stabilization} = k (v - v_{max})

  It’s much more simple, behaves really well and allows really simple max speed calculations. Your max speed is when the forces acting on your ship are 0. When does this happen? Easy, v_{realmax} = speed + \frac{thrust}{k}. We’ve found that a good value is k = 3 .

  Other notes, while doing this revamp I improved the current engine. Thrust is relative to the ship, that means that rotations are smoothed out really nicely by the Runge-Kutta algorithm. Same happens with the new stabilization force. This means the physics are smoother than ever. The system was also improved to handle fast ships and jump ins without instability. What we saw originally was that when your ship was moving really fast, the stabilization force caused instability in the physics engine. This meant your ship would end up at infinity about a second after jumping in. However the new improved engine can handle any speed by chopping up the simulation more finely when the ship is going fast.

  Other notes we also have a hybrid physics engine now, in the sense it can do both Runge-Kutta and Euler for different objects at the same time. I’m quite proud of it. The player may be asking what to make of all this? Well you probably won’t feel a thing, but let me assure you it’s much more awesome.

  EDIT: It’s been pointed out that if you go back to the equation originally you could have looked at how the units did mismatch. We all learn from our mistakes, how stupid they may be :) .

  ---

• Fancy new menu

  BY BOBBENS, ON NOVEMBER 16TH, 2010

  After lots of nagging and harassing of developers we finally have it! The great epic new fancy main menu background, and what could be fancier than naev itself? Yes the background is a system (specifically it’s the start system for now). It’ll be a bit fancier in the future but you can now enjoy the awesomeness. No more boring backgrounds! Check it out!

  NOTE The screenshot has been lost to time :(

  ---

• NAEV 0.4.2 is now available in openSUSE

  BY DEIZ, ON NOVEMBER 12TH, 2010

  While development continues towards 0.5.0, increased availability of the current stable release is always a good thing. NAEV can now be found in the openSUSE Games repository.

  See here (this link is dead :() for downloadable packages for openSUSE 11.3. There are also packages built for a number of other RPM-based distributions, including Mandriva and Fedora listed by the build servicehere (this link is dead :(), downloadable from here (this link is dead :(). It appears that you’ll need the naev and naev-data packages; after installing both, NAEV should be ready to play.

  ---

• Big Big Systems

  BY BOBBENS, ON NOVEMBER 10TH, 2010

  So what happens when you take big systems and inject them with pure essence of big? You get Big Big Systems. How big are we talking? If an old system maybe had an effective radius of 3.75 kpx or so, now we have radius of 25 kpx. That’s a pretty big increase. How long does it take to fly across it? It’s likely faster than before thanks to dynamic time compression.

  A brief overview of how this is handled; There are currently two ways to trigger dynamic time compression:

  1. Activate autonav
  2. Right click on the overlay map

  What it does, essentially, is increase the time compression until your ship reaches an “effective” speed of 2500 m/s. That means all ships behave nearly identically, be it capital ship or light fighter. This means that capital ships are much more playable now.

  Can’t leave you without a pretty screenshot, so this is what a big big system looks like. As you can see there’s a YOU and GOTO on the map and dynamic time compression is at 27.1x. My Empire Hawking is flying from YOU to the GOTO. On the map overlay you can also see friendlies flying nearby.

  So what’s next? Balance. Balance? Balance! It’s going to still take a while, but it’ll be damn well worth it. For those following Git, big big systems are still in the balance branch and haven’t been merged into bigsys yet.

  NOTE The screenshot has been lost to time :(

  ---