Since 0.5.2’s release two weeks ago, a number of bugs have been caught and fixed, and several minor features have been implemented. We’ve decided to do another release in the short-term (0.5.3) which will hopefully be the last of the 0.5 series.
Following 0.5.3, our major focus will be implementing and polishing the slots proposal (essentially, making a ship’s core systems separately upgradable). This and a number of smaller features will be incorporated into 0.6.0.
Therefore, in order to make sure the last of the 0.5 releases is as bug-free as possible, we urge everyone to report any and all issues. Testing with a Git master build is preferred, as several issues have been fixed since 0.5.2, but bug reports from 0.5.2 are welcome. Check the issue tracker to make sure it’s not a duplicate. Safe flying!
As some of you may have noticed, the last few releases have introduced changes to the afterburner outfit. Where you could run it continuously so long as your ship had energy before, now it can only be on for a certain about of time, after which it needs to recharge. Also, in 0.5.2, activating the afterburner will abort the autonav.
The reasoning behind this is that the afterburner is a combat-oriented outfit, whereas most people were using it to speed up their ship during travel, particularly during rush missions. Effectively, an afterburner would speed up a ship – a lot – for no appreciable cost. This we wanted to discourage. Speed at long ranges should come from speccing for speed by going light on weapons and using passive outfits, not from abusing the afterburner.
However, some people raised some legitimate complaints about the changes we made. For instance, making the afterburner recharge over the same time period irrespective of how long it was on is unpleasant and counter to what you might expect. Aborting the autonav was just an added irritation, not an incentive not to use the afterburner. After all, afterburning in 1x time would still get you to your destination in less in-game time than not using it in time compression would. Finally, limiting the afterburner’s time wasn’t really making the afterburner ineffective at speeding up the ship over long distances, it was only making it a bit LESS effective.
Reason for us to tackle the problem from a different angle. The afterburner should not be made annoying to use. Instead, it should simply be made unfit for the purposes it wasn’t intended for. To do this, we picked up an idea we discussed early in the afterburner overhaul: making afterburners generate heat.
Heat based afterburners
An afterburner that's heating up
In their latest incarnation, afterburners generate heat when active, in the same way weapons generate heat when being fired. And, like weapons, afterburners get less effective when they heat up. When the afterburner starts to overheat, the speed and thrust bonuses it provides decrease, until afterburning is no faster than regular thrusting.
Because heat drains into the ship much slower than it builds up when afterburning, the afterburner can’t be on all the time even if energy permits. In fact, for the player it’s best to use the afterburner only occasionally and in short bursts. This naturally makes it more suitable for use in combat than for speed boosts across large distances.
The heat based afterburners behave just like the original ones otherwise. They don’t have an enforced recharge cycle and can be used at any time, with the sole exception that it will shut off automatically when completely overheated, and can only be turned on if it’s cooler than 70% of its maximum heat.
Getting rid of heat
A Lancelot in Active Cooldown mode. When the bar has completely emptied, the cycle is complete.
Afterburners using heat is nice, but it adds another source of heat to a ship that is already having to deal with heat from other sources. When a ship’s hull heats up, the outfits installed in it won’t cool as fast, or not at all. Especially in combat, this can be a big problem – both for the player and the AI. In fact, a fight can degenerate in what I call “heat deadlock”, where all parties have heated up so much that their weapons aren’t shooting much anymore, so shield regeneration outpaces damage done across the board.
To combat this, we have introduced a new mechanic to the game, called Active Cooldown. When in Active Cooldown, a ship very rapidly loses its heat until both hull and outfits hit the baseline temperature. The process depends largely on the ship, with small ships taking less than 10 seconds to cool and big ships taking around 30. When you consider that under normal circumstances, it can literally take hours and hours (real time!) to lose heat, Active Cooldown is a very, very fast way to lose heat.
So, you wonder aloud to nonexistent auditory organs, what’s the catch? There are two catches, as it turns out. The first catch is that to enter Active Cooldown, a ship must be stationary, and while it is cooling, it can’t take any other action. So in a combat situation, Active Cooldown makes you very vulnerable. The second catch is that heat is lost at an exponential rate – the longer you wait, the faster heat is lost. This means that it is highly desirable to wait until the end of the Active Cooldown cycle, as opposed to waiting only a portion of the time and then getting back into action. Active Cooldown can’t effectively be “pulsed” to quickly lose some heat in the middle of a fight.
Hopefully, these two changes to gameplay will go a long way in making afterburners the tools they’re meant to be without being disruptive to gameplay, as well as making heat much less of a problem to prolonged trips through the galaxy.
Naev’s Lua API documentation has finally been integrated as a part of naev.org, under its very own subdomain: api.naev.org.
Some may note that the documentation has been around for some time, and that’s true. In fact, the effort dates to 2008, and has been kept in sync with the code ever since. It’s historically been hosted on a small VPS by bobbens, with a handful of links to it peppered throughout the Wiki, as well as a mention in the IRC channel’s topic (though I suspect 95% of IRC users never read channel topics).
With any luck, making the API documentation more easily accessible will spur on some mission developers. I’d be remiss if I didn’t reiterate a bit of the API documentation’s preamble: Naev includes an in-game Lua console, accessible via F2, by default. It provides access to the majority of the Lua API (excepting a few things that are tied to missions and events, such as the hook module) and is a useful tool for cheating testing code snippets for use in missions.
So, venture forth to Alteris and try something like:
for k,v in ipairs(pilot.get( faction.get("Pirate") )) do v:setHealth(0, 0) end
… because as everybody knows, you’re not having fun until you’re surrounded by spontaneously-exploding pirates.
The Naev development team is proud to announce the release of Naev 0.5.2. This is mainly a bugfix release, though it also introduces a small amount of content in the form of missions and outfits.
The new asset discovery mechanics have bothered quite a few people, so we’ve introduced a jump scanner outfit that greatly increases jump detection range, as well as local maps which behave similarly to the traditional star maps found in 0.5.0 and earlier releases.
Now, as per usual it’s time for some statistics, from 0.5.1 to 0.5.2:
83 files changed, 2408 insertions(+), 574 deletions(-)
More than half of the added lines come from the dat/ directory tree, thanks in large part to a new event and a repeatable mission for the Sirius faction.
Changes since 0.5.1:
- New events and missions
- New outfits
- House Soromid now has a logo
- More ways of mapping the universe
- Disabling damage leaks through shields
- conf.lua-tweakable font sizes for accessibility
- Bug fixes
The Naev development team is proud to announce the release of Naev 0.5.1. It’s been nearly nine months since the release of 0.5.0, but we hope the release is worth the wait. With contributions by some twenty people, it’s one of our larger releases.
0.5.1 was originally intended to be a small feature release, released soon after 0.5.0. Needless to say, that didn’t happen. However, in the time since, 0.5.1 has ballooned into a sizeable release unto itself. We’ve implemented a number of proposals that bring us a few steps closer to our goal for the far-off version 1.0, developed a fair bit of new content, and polished up innumerable things.
As per usual, we encourage players to start new pilots in 0.5.1 for an optimal experience. Of course, older saves can still be loaded, but there are some caveats. Specifically, due to asset and jump discovery, a 0.5.0 (or earlier) save will have its map appear as a series of unlinked systems, as the jumps must be discovered. A number of older missions have also been heavily tweaked, so in-progress missions in older saves may need to be manually aborted.
And now, for some slightly-misleading statistics, from 0.5.0 up to a few days ago:
804 files changed, 48017 insertions(+), 35760 deletions(-)
As well as some less-misleading ones, from the src/ directory:
346 files changed, 14799 insertions(+), 8806 deletions(-)
Since 0.5.0, Naev’s core code has grown by almost 6,000 lines, and we’ve gained more than 12,000 lines, in total.
List of changes since 0.5.0:
- Many new missions, and improvements for older ones.
- Soromid faction added.
- Full array of ships for the faction.
- Populated northern area of the galaxy.
- New disable mechanic
- Disabling damage is separate from regular damage.
- Player ships can now be disabled, boarded and looted!
- Disabled ships will recover automatically over time.
- Jump points, planets and stations must now be discovered through exploration.
- Maps now reveal fixed routes, mostly between major factions’ space.
- Fancier map search shows details about found items.
- New planet and station graphics.
- Large AI ships now have greater weapons diversity.
- General usability improvements for low resolutions.
- Missiles lock on gradually, depending on electronic warfare values.
- The tutorial has been substantially expanded and reworked.
- Active outfits allow for powerful, temporary abilities to be toggled.
- New key bindings make the it possible to use the keyboard most of the time.
- Autonav is now more flexible and can travel to planets in addition to systems.
- Navigate the spaceport with keytips.
- Improved faction reputation logic.
- Factions now have ceilings for reputation gained through killing.
- Missions are necessary to elevate your standing beyond this.
- Completing major missions can increase the reputation ceilings.
- Landing permissions enhanced beyond the simple boolean (hostile or friendly) model.
- Landing at military and other special assets typically requires high reputation with a faction.
- When you don’t meet the required standing but aren’t hostile, assets are marked ‘restricted’.
- Overhaul of spaceport bar NPCs. NPCs will now often say meaningful things and can even help the player out by hinting at missions or updating his galaxy map.
- Complete ship health rebalancing.
- Store user data in XDG-compliant locations (*nix-only)
- Misc. bug fixes
- Faction standing and land permission code moved to Lua.
- Reputation is now handled with per-faction scripts.
- Special assets can have unique landing code (e.g. requiring a particular mission to be done)
- Large amount of Lua API additions and changes.
- Greatly enhanced the in-game universe editor.
- XML data (ships, planets, etc.) has been split into individual files to allow greater modularity.
- Various faction specific scripts have been reorganized to be in a more logical location, and these script have been tied closer to the master faction definition.
- Generally less crash-prone when loading corrupt data.
- Misc. bug fixes
As with the previous post, this pertains solely to *nix (primarily Linux and Mac OS X) users. Windows users are warned to avert their eyes to avoid irreversible Unixification.
I’m not a fan of pushing maintenance duty onto end-users, so I’ve done some work to automate the XDG configuration update process bobbens mentioned.
When first running the next release, if old configuration files exist (in ye olde ~/.naev) a prompt will show up, offering to automatically invoke the update script. This will hopefully reduce the process down to simply clicking “Yes” for most users.
Of course, you’re welcome to click “No”, as well. To hopefully handle all distribution cases (whether Naev is run from loose files in a Git checkout, installed via a package manager or grabbed directly from SourceForge) the script is both included in the single-file ndata and available as a standalone file.
With any luck, the configuration update will be smooth and painless. It should also make the coming release less painful for bobbens, because I think if we’d gone the full-manual route and asked package maintainers to correctly run the script for each user, they’d be demanding his head on a pike.
This change only affects UNIX platforms (that includes linux and mac os x). Now in git master we have recently merged changes that should bring Naev up to the XDG Base Directory specification. What does this mean? First off it means that no longer will Naev’s per user stuff sit in “~/.naev” but instead it will be split up so that:
- config is in $XDG_CONFIG_HOME or “~/.config/naev”
- saves and screenshots are in $XDG_DATA_HOME or “~/.local/share/naev”
- nebula and misc cache stuff are in $XDG_CACHE_HOME or “~/.cache/naev”
The bad news, this means that you will have to run our script to move stuff over or it won’t recognize your old config or saves. We should be detecting that and displaying a warning. To update to the new paths all you have to do is run:
However, we do believe this will be better in the long run. Package maintainers should look into incorporating that script for users in post-install hooks or the likes to avoid trouble. Sorry for any inconveniences this may cause.
Running a jammer while the afterburner cools down.
Okay, so, on those activated outfits, they’re now up and running in the Git version. For those of you who are curious about how it works, I’ll explain it briefly.
An activated outfit is a piece of equipment that does something when manually activated in space. While it’s off it does nothing, but it also doesn’t use any energy. On the other hand, once an activated outfit is turned on the benefit it gives is usually quite noticeable, and can make a big difference if used right.
This means that the abilities activated outfits give you are highly situational and give you more things to worry about than just fly, point and shoot. In some ways, we are moving a little closer to the common skill bar you find in many action RPGs. Like those skills, our activated outfits can have a cooldown period too, which means you need to wait a certain time before you can use that same outfit again.
At the moment, we only have two activated outfits, those being the Missile Jammer (which slows down missiles close to you) and the Afterburner. But we have plans for quite a few other outfits. For example, how about an outfit that instantaneously transports your ship to another part of the system, or an outfit that lets you quickly recharge your shield at the cost of a big chunk of energy? The possibilities are many.
Activated outfits will be in the next release.
I suppose I should qualify that with an almost. Thanks to the efforts of #naev IRC regular oldtopman, we’re all set up and awaiting final approval. Once we go live, Naev will be is available via Desura on all of our usual supported platforms (32 and 64-bit Linux, Windows and Mac OS X). The Desura client is presently exclusive to Windows and Linux, but Naev will still be downloadable on OS X through Desura’s site.
For those unaware of Desura, it’s a digital distribution platform. I’ll let Desura’s own about page do the rest of the talking.
Without further ado, here’s a link to Naev’s Desura page:
Update: As of now, Naev is live on Desura!
The gaming blog Gaming on Linux has published an interview with Naev’s core development team. You can read it here.