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.
Hello everyone, and a belated happy 2012. It’s been rather quiet here on the blog, but I assure you that’s only because nobody has been posting on it. Elsewhere we’re all still tinkering away on the project, and we’re hoping to build toward a new release in the near future. Before we can do that though, we need to put the finishing touches on the active outfit system. You see, we plan to add outfits you can install on your ship and activate once in space for all sorts of effects… Oh, but I can see you’re not very interested in that. So, let’s move on to something else that’s been happening:
Asset and jump discovery
Discovering assets (that’s planets and stations) and jump points used to be easy. Jump into a system, glance at the system map, voila, they’re all there. But that is changing. Just as ships become undetectable if they’re far away from you, so can assets and jump points be invisible to you, using much the same mechanics. For an easy example, look at the following screencaps:
Jumping into Eneguoz... Hey, where is everything?
Oh, there you are! The planets didn't appear until I actually flew closer to them.
As you can see, it’s now possible for assets to not be shown on the map until the player discovers them. Now, I should point out that most planets tend to be fairly hard to miss in a star system, so when you jump into a new system you will usually discover all of them immediately, just like it’s always been. The example above isn’t representative in that respect – I simply modified the hide values for the purpose of showing how it works. However, if the system has high sensor interference (inside the nebula, for example), it may be more difficult to find the planets within.
Space stations tend to be a fair bit smaller than celestial bodies however (yes yes, except THAT one). You may have to scout around a system a bit before they appear on the map, and if the station actually makes an effort of being inconspicuous (think hidden military or pirate bases), you won’t easily find them.
Jump points, too, are more difficult to detect than your average planet. You usually won’t spot any jump points other than the one you entered from when jumping in, which means you can’t plot a course to the next unknown system before first finding the way there. So how will you know where the jump points are then? Well, you could fly around and look for them yourself, but there are a number of things you can do to find them more reliably:
- Follow other pilots. Especially traders often travel to other systems, and they know all the major routes. If you see a trader fly away from a planet, try following it. Chances are it will lead you to a jump point.
- Talk to NPCs in the spaceport bars. Not only do NPCs offer you missions sometimes, they will also give you helpful information. Some may even offer to update your map with locations of assets or jump points if you don’t know them already.
- Buy maps. As of the next version of Naev, the Star Map outfit has been replaced by a collection of pre-defined maps. Each map reveals one or more star systems, and may or may not reveal jumps and assets belonging to them. Buying a map for the Empire Core, for example, will immediately update your map with systems in Empire space, as well as the jumps leading from one to the other.
There are also rumors of new, exotic types of jump points, such as hidden jump points that can’t be detected without special equipment, known only to a selected few. There also seems to be a kind of jump point that can’t be detected at all, and that only be used from the other side…
The player in a Mule being plundered by an evil Pirate Admonisher.
So, this was done a while back; finally getting around to posting about it. Briefly, we’ve changed how disabling works: Instead of auto-disabling when a ship reaches 30% base armour, you can now take disabling damage. As for how this works, weapons can now deal two types of damage: normal and disabling. Disabling damage is only applied when your armour is hit, and this increases your disable damage. If the amount of disabling damage taken exceeds your current armour, your ship is disabled. This applies to all ships and will make it so now you have to outfit to safely disable ships. However, specialized new missiles come to the rescue and provide disabling damage so that you don’t have to sacrifice shield piercing abilities for your cannons/turrets.
As a side note, this now means the player’s ship can be disabled. If your ship is disabled, you can be boarded, so prepare to see pirates boarding your poor, sad ship and looting your hard-earned funds. As a side mechanic, disabled ships do automatically recover after a while, so this means clumps of disabled ships won’t accumulate around dangerous jump points. There are limits to what they can steal, so don’t worry about losing all your credits to a lone pirate. We believe that this will make the game more interesting, especially as we introduce more complex mechanics that will interact with this.
It has been some time since you’ve heard from us, so I’m taking it upon myself to give you all an idea of what’s going on with Naev.
The first thing I should mention is that is is summer for Naev, and summer usually means a lull in activity. It has to do with lots of other things happening in summer, many of them outdoor ones. I think you get the idea.
That said, things have been happening since the 0.5.0 release. The original plan for the next version, 0.5.1, was, and I quote:
14:16 bobbens we can do safe lanes
14:16 bobbens for starters
14:16 bobbens although I’m not sure on the safe lane stuff how to procede
14:16 bobbens we can either go safe lane “simple implementation” first
14:16 bobbens for quick release
14:16 bobbens or go quadtrees and asteroids first
14:16 bobbens for a slower crazy release
Once this discussion was over, we promptly started working on completely different things. One of those things is the revised faction standing mechanic, described in a previous blarg post. But there is more.
For instance, work is ongoing on a revised disabling system. Up until 0.5.0, ships would become disabled once they sustained enough damage (to be precise, once armour fell below 20%), and that was the end of it. However, one of our team members (it was me) felt that this was undesirable, and designed something different. Rather than always being disabled through damage directly, ships now accrue “stress” damage, which builds up as weapons do damage, and falls naturally over time. Once stress damage equals the amount of armour the ship still has left, the ship becomes disabled. Assuming the ship is not destroyed afterward, it will come back online after a certain amount of time.
The important part in the above is that stress damage needs to reach the amount of armour health left on the ship. The direct implication of this is that ships with low health are more easily disabled than ships with high health, without tying the concepts of “low” and “high” to the ship’s maximum amount of health. This means that a small ship can be reliably disabled without running the risk of destroying it, for example.
The introduction of stress damage in itself also gives us the opportunity to differentiate weapons further. In practice, this means that most weapons will do minimal amounts of disable damage, much less than their actual physical damage, so that it’s almost impossible to disable a ship before killing it. On the other hand, certain other weapons will deal a lot of stress damage and limited amounts of physical damage, so that stress damage easily builds up toward the critical level.
One of our current efforts is to make missiles more meaningful while at the same time not placing too much emphasis on them. In 0.5.0, most missiles are mostly useless, for various reasons. For instance, damage was low and the likelihood of missiles hitting fast targets or targets with jammers was rather low. One of our team members (it was me again) came up with an alternative missile system that would allow missiles to be more useful while hopefully not be too dominating.
In the new system, a missile weapon must acquire a lock on the target before it can fire. To acquire this lock, the target must be kept within the missile lockon area, which is an arc in front of the ship for normal launchers and everywhere for turreted launchers. The time the launcher takes to lock on depends on the lockon time defined for that launcher, and on the level of stealth of the target. As a general rule, small targets are more stealthy than bigger ones. So while an interceptor missile might lock on to a capital ship very quickly, a heavy torpedo would take a very long time to lock on to a fighter. Stealth is further affected by electronic warfare outfits such as passive scramblers and, to be implemented, jammers that must be activated and provide a short-term boost.
Once fired, missiles are quite good at finding their targets. Unlike most of the old missiles, all missiles now predict where their target is going to be, so unless the target can actually outmaneuver the missile, the missile will usually hit. The new missiles also do considerably more damage, so being hit by one can be quite painful. The aim is that most missiles are optimally suited to a certain class of ship, however, dealing too little damage to seriously hurt targets bigger than that and being too slow and sluggish to catch faster ones.
A somewhat minor change, but perhaps worth mentioning here is the overhaul of ship health. Where ship armour and shields more or less linearly increased as the ships got bigger and heavier, one of our team members (it was me, sorry) felt a different philosophy should be followed.
Small ships now rely mainly on their maneuverability and their shields, as before. Their hulls are made out of bread, relatively speaking, so only a few hits will be enough to destroy them. Avoiding fire in an engagement is key to survival.
Big ships have received substantial cuts to their shielding. While they still have more shielding in absolute terms than smaller ships, the increase becomes less and less as ships get bigger. On the other hand, armour has been drastically increased. The idea here is that big ships, as big and lumbering as they are, will run out of shields in most serious encounters, but survive on armour for a considerable time after that. When combat is over shields will come back up but armour will not. In this manner, capital ships will get worn down between engagements, and will eventually have to return to a friendly planet or station to make repairs. Of course, this assumes combat will be sporadic and intense, as opposed to constant and niggling (as is currently the case!). All in good time.
I should also mention that shield regeneration has been boosted across the board, hopefully enough to make the regeneration actually matter in the middle of combat. I’m sure we’ll be tweaking that more in the future.
Following contributions of some great ship models by Viruk, a new faction has been added to the Naev galaxy. The Soromid already existed as a lore writeup previously, but now they also own ships, stations and planets. In the future, they will also receive their own weapon specialization, and of course their own missions.
You can see a map of their territory to the right. It is located in the north of the galaxy, where previously there were only empty systems. Not anymore!
Our team leader bobbens is working on a personal project as well. You can see the result here.
That’s all for now!
They don't take kindly to outsiders at Dvaered High Command.
To provide a brief overview: In 0.5.1, the landing and faction standing mechanics will be changing in a big way. They’re both no longer hard-coded in C, having been moved to flexible Lua scripts that can operate differently for each faction.
Important military outposts and such will now be restricted to factional allies, seldom (if ever) accepting bribes, and attaining standing with a faction will require campaign missions rather than just killing the faction’s enemies.
Landing has long been a rather simple mechanic in Naev. Plainly, being neutral or friendly with a faction means you can land on any of their assets — up to, and including, their primary military and political headquarters. Likewise, if you’re hostile with a faction, you can simply bribe your way into the spaceport.
Yet somehow, it seems that high-ranking bureaucrats and military officers might frown on enemies of the state traipsing around their headquarters after throwing a few credits at the landing control officer. As such, it’s become a priority to do away with the overly-simplistic permission system.
Our new mechanic for this is rather more nuanced. As we’ve done with many things, landing is now handled through Lua — the behaviour is no longer hard-coded in C. The simplistic landable-if-not-hostile model has been replaced with a ternary system that can operate differently per-faction: while civilian worlds will let neutral strangers land, important factional outposts will typically be restricted to allies. Correspondingly, a backwater civilian settlement that you’re hostile with is likely to turn a blind eye if you pay them off, while officers at a military outpost will tend to be far less lenient.
The restricted assets are also divided into tiers. While an outsider will be able to land at most of a faction’s military assets after doing a number of missions for them, key assets such as faction home worlds will remain off-limits to all but close allies.
A second, closely-related mechanic is faction standing. Like landing, it’s also far from optimal in 0.5.0 and earlier — you can become a faction’s trusted ally simply by going on a brief rampage and killing off a number of their enemies’ ships.
This may even happen inadvertently through normal gameplay. It’s a given that players are attacked by pirates in many areas of the galaxy, and since pirates are a common enemy among many of the lawful factions, simply fighting off pirates ingratiates players with all of these factions.
For 0.5.1, it’s undergoing a substantial revamp. Like landing, the previously hard-coded behaviour has been replaced with a flexible Lua solution. Generally, killing alone won’t take you terribly far. To become an ally of a faction, it will be necessary to do missions for them.
Grunt-work such as cargo ferrying and patrol missions won’t go all the way, either. Each faction has two ceilings on standing. The first is the point at which killing stops increasing your standing, and the other is the limit on how far normal missions can raise it.
To become a faction’s ally, you’ll need to do campaign missions for them. The reputation limit that regular missions can reach will be increased by the campaign missions, essentially representing an increased willingness for the faction to trust you.
The way reputation is gained through killing is also changing. The 0.5.0 reputation system is essentially omniscient. If you kill a pirate out in the middle of nowhere with no witnesses, your standing will still go up with all pirate enemies.
The new system operates on two levels. Killing a faction’s enemies in systems that the faction inhabits will trigger a normal standing increase, because you’re directly defending them and their populace. The other case is where you’re fighting a faction’s enemies outside of the faction’s space. In this instance, killing a faction’s enemies only increases your standing if the faction has a ship that’s within sensor range.
Plainly put, a faction should only take notice if your actions affect them in a direct manner. The Empire shouldn’t care if you kill a pirate deep within Sirius space, nor vice versa.
We hope that these mechanics will make general faction relationships more compelling, and ideally they will serve to distinguish factions from each other, rather than faction standing polarizing into lawful versus lawless, with one group of factions at 100% and the other at -100%.
Screenshot of Naev 0.5.0.
The Naev devteam is proud to announce the release of Naev 0.5.0! This release is the result of over a year of hard work done by nearly 30 committers. This release is just a step in the path for ultimate greatness and a major step forward in the maturity of Naev. It has many major gameplay changes and signifies the coming of age of Naev, which has now exceeded the tag of Escape Velocity clone.
Due to the size of the 0.5.0 ndata, downloads shall from now on be hosted at Sourceforge instead of Google Code due to the latter’s arbitrary size limits.The rest of the project infrastructure will remain unchanged.
In the future, a shorter release cycle will be used, with focus on the remaining features left before content can be the main focus which include asteroids, dynamic economy and fleet AI, among others.
Some statistics of the release to give an idea of the magnitude:
961 files changed, 91734 insertions(+), 25431 deletions(-)
List of changes since 0.4.2:
- Larger universe
- Expanded Dvaered, Frontier, Empire and Pirate territories
- All-new Sirius and Soromid territory
- Big systems
- More planets per system
- Much larger planets, many new planet and station graphics
- Players must fly to jump points before jumping to another system
- Overlay map for in-system navigation
- Mouse interactivity
- Planet, ship and jump point targeting
- Contextual click actions (board, hail, land, etc.)
- Optional mouse-controlled flying
- Electronic warfare
- Ships have cloaking and detection abilities
- Sensor range depends on cloak vs detection
- Turrets no longer track all ships equally
- Time model changes
- In-game time progresses in real-time
- Dynamic time compression speeds up long journeys
- On-map security rating abandoned in favour of faction presence indicators
- System backgrounds (nebulae, stars and more!)
- Fancier new GUI
- Brand-new tutorial that is independent from the main game
- Outfit slots now have sizes
- Weapon sets allow easy configuration of different weapon combinations for each ship
- Ship and weapon heat system
- Weapons start with perfect accuracy, and become inaccurate as they overheat
- Severe overheating causes rate of fire to drop
- Damage absorption and penetration system
- More diverse planetary inventories (see the tech system below)
- Random bar NPCs
- Sound system improvements
- Smarter autonav behaviour
- … and plenty more (new missions, ships, outfits, portraits, etc.)
For Developers (Missions and likewise)
- Faction presence
- Replaces security and simple fleet spawning
- Fleet spawning is now controlled through Lua on a per-faction basis
- Universe and system editor
- Allows easy and quick modification of the universe
- Can create and manipulate planets, systems and jumps
- New tech system
- Techs are groups containing outfits, ships or other techs.
- Assets (formerly planets) sell whatever is in their assigned techs.
- Hook improvements
- Pilot hooks pass arguments by default
- You can now pass custom arguments to hooks
- Many new hooks
- Replaced old timer system with new hook-based timer system
- Improvements to the in-game Lua console
- Missions can now use more than a single mission marker
- ndata-locating code is much-improved
- Lua/Luajit and CSparse system libraries can be used instead of internal ones
- SDL_image is no longer a dependency
- Events can now be saved
- GUIs can be written in Lua
- Camera API allows much greater camera flexibility
- Vast amounts of other Lua API additions and enhancements