We have added an entry on Steam Greenlight for Naev, in hopes of reaching a larger audience for the game. Whether the game accrues enough upvotes to be published on Steam is of secondary importance – every extra pair of eyes that sees our entry is good for us.
Hello readers, it’s been a long time since our last post. I hope you’re both doing well.
Development has been pretty slow in the last months. It hasn’t entirely ceased though, and today I can tell you that a pretty major change to the game has been finalized and is now in the master git branch. The way ships work has been changed, and that’s what most of this post is going to be about. There have also been some other changes I’ll briefly mention at the end. Hang tight, it’s going to be a long one.
The basis of the new system is a refinement of the ship slots. Up until now, ships had three types of slots: utility, structure and weapons. This is true even now, but it is now also possible for slots to be specialized. We can demand an outfit be installed in a certain specialized slot, and we can enforce that specialized slots can only take certain outfits. This allows us to gear certain ships to certain roles, and that will be important later when we deal with fleets.
For example, imagine a Carrier class ship. This ship might have a number of specialized slots that will only take fighter bays. We can also create special fighter bay outfits to go in these slots that are better (lighter, higher capacity, less CPU, etc) than the fighter bays you can install in any slot. This means that a Carrier has much greater potential for carrying fighters than a Cruiser of equivalent size.
One size will no longer fit all, in the future.
Ship core equipment
Currently our most important (in fact only) use of the new slot system is found in every ship in the game.
Up until now, you’ve known your ships by their abilities. Some ships were faster, some slower, some had more energy in the tank, some had more CPU to spend. With this new mechanic, that has changed completely. With a few exceptions, ships have been stripped of all their numbers. Instead, these numbers are granted by certain special equipment installed on the ship. This special equipment we call “core outfits”, or more briefly, cores.
Each ship has three “core slots”: one for its engines, one for its core systems, and one for its hull mod. Every ship can only equip one single outfit of each kind, and each ship MUST have one of each kind installed, or the ship will not fly! The interpretation of each core outfit type is as follows:
A ship with its core slots installed. The orange text in the tool tip indicates the slot specialization.
- Engine core slots are just that, the ship’s engines. Engines determine how fast a ship can accelerate, the ship’s maximum speed, the base fuel capacity, and the mass limit (more on this one below).
- System core slots can be thought of as the heart of the ship. Systems determine energy generation and capacity, shield generation and capacity, as well as CPU capacity.
- Hull core slots represent the structural configuration of the entire ship. Most importantly hull cores affect armour, damage absorption and cargo space, but some hulls can do other things as well, such as make a ship more stealthy or increase energy regeneration. Hull mods also greatly contribute to a ship’s mass.
Of course, there is a healthy variety of all core types available. When you buy a ship it will come with very low end cores, so you’ll have to invest to increase your ship’s performance!
Hang on, I hear you saying. If all ships now take their performance values from cores, doesn’t that mean all ships are the same if you install the same cores in them? Why yes, that would be the case if we just kept it at this. But no, there’s more.
Where every ship was the sum of its values before, it now is (mostly) the sum of its ship stats. Ship stats are modifiers specific to that ship. For example, a ship might have a 15% bonus to energy generation. This means that whatever energy regeneration is granted by its outfits will be multiplied by 1.15. This makes it attractive to install a good system core, and maybe extra energy generators as well. On the other hand, a ship might have a penalty to its maximum speed. This means that engines you mount on the ship will have reduced performance. So, even if you use the same core outfits, two different ships might well behave very differently.
Ship stats are usually scalars like that, but they can do other things as well. For example, there is a ship stat that enables a ship to jump through a jump point without having to brake and charge up its hyperdrive first! A ship with
This is clearly not a good cargo ship, but it has a bonus to shields.
this ship stat will make hyperjumps a lot easier.
Now, perhaps confusingly, it is possible for outfits to grant ship stats to a ship. This seems illogical (they are called SHIP stats, after all), but it is very useful because it allows us to make outfits that grant ships special abilities, while ALSO allowing ships to come with those special abilities out of the box. For example, there is a “Reverse Thrusters” ship stat that allows ships to thrust backwards – when you press the reverse key, the ship will slow down instead of turning around, and eventually fly backwards. This ability might be standard on a certain class of fighters, but it’s also possible for pilots to mount an outfit on their ship that gives them the same thing, if they’re willing to spend a slot on it.
I’ve written up the basics of the new slots system now, but this is one thing I want to explain in more detail.
First, let’s examine this “mass limit” that I mentioned earlier in this post. It’s a new concept that didn’t exist in the game before. Every engine has a mass limit value, for example 100. This value determines the maximum mass the engine can support at maximum efficiency. If the ship becomes heavier than this limit, the engine isn’t capable of pulling all that weight anymore and the ship will become slower and more sluggish. The mass acts as a divisor for the engine’s efficiency, such that when the ship is twice as heavy as the mass limit, the engine will only function half as well.
Now, you might feel that this mass limit thing is an arbitrary limitation, and it is. Let me explain why it exists. You see, it leads back to the issue of ships behaving the same if the same outfits are installed. It is entirely possible for capital ships to install fighter engines, because the slot system allows you to install outfits into any slot that is at least big enough. Obviously, we don’t want capital ships to race around like fighters though! So we need to make sure that capital ships benefit most from capital ship engines. The way to do it is, of course, by adding mass to the equation. At the same time, we want to make sure that the BIG engines are capable of pushing the big ships around, which raises the question of how to balance that. You can just give big engines a lot of output to compensate for the ship’s mass, but that would mean the engine is always a lot worse than it says on the tin, and that’s not fun for the player. So instead, I chose to arbitrarily define a maximum mass at which the engine is guaranteed to perform optimally. This is easier to work with on the balancing side of things.
The following is a list of changes made that don’t directly relate to the slots system. I probably forgot a few things, though.
- Fuel consumption has been changed so small ships use 100 fuel per jump, medium ships use 200, and large ships use 400. This is done to counteract the fact that larger ships have more slots, and can therefore equip more fuel tanks. This gave large ships a much greater operational range than small ones. The flipside of this is that buying fuel off NPC ships is going to be more tedious, but we have some ideas about easing that.
- The Auxiliary Processing Unit outfits no longer exist. Sorry! The only way to increase your CPU capacity is by upgrading your core system.
The tabbed interface for outfits.
- The galaxy now contains secret shortcut jumps. You can’t find these jumps unless you have a special scanner, and even then you probably need some hints to find them. Note that the scanner isn’t sold anywhere yet, and there are also no hints to be had yet. But this is a work-in-progress.
- Some work has gone into the equipment screen. The outfit list is now tabbed, each tab corresponding to a class of outfits. The tab letters, as seen on the right, stand for Weapons, Utility, Structure, Core and Xeverything. Hopefully, this can be further improved and applied to the outfitter screen as well.
- For developers: All game data is now found under the dat/ subdirectory. This was done to make the relationship between the game data and the ndata file more apparent.
- For developers: Lua scripts from the dat/scripts/ subdirectory can now be included into other scripts by only their name. The game will look in this directory for includes.
The Naev development team is proud to announce the release of Naev 0.5.3. This release fixes several bugs and introduces a few minor features. We aim for this to be the final release in the 0.5.x series, with 0.6.0 following in the not-so-distant future and bringing significant changes to ship equipping.
Perhaps most importantly, we’ve introduced a non-gameplay feature, portable mode. On launch, Naev will now look for a file named
datapath.lua in the same directory as the Naev binary. The Windows installer provides this as an option, making it easy to install and run Naev from removable media.
Note that if you want to use portable mode with your existing saves, you’ll need to migrate your files manually. For Windows users, this means moving
naev-data\ within the directory Naev is installed to.
Changes since 0.5.2:
- Portable mode, allowing for Naev’s user data files (saves, screenshots, etc.) to be placed in arbitrary locations.
- Afterburners now gradually overheat and have no fixed duration.
- Active cooldown allows for rapid ship cooling.
- Many typo fixes in missions and lore.
- Fixed several rare crashes.
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.