Naev Development Blarg (Page 14)
-
So, afterburners
BY BTAXIS, ON APRIL 2ND, 2012
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
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
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.
-
Lua API Docs Added to Naev.org
BY DEIZ, ON MARCH 29TH, 2012
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 (RIP Freenode) (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.
-
Naev 0.5.2 Release
BY DEIZ, ON MARCH 25TH, 2012
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.
Download: https://sourceforge.net/projects/naev/files/naev-0.5.1/
Blog: https://naev.org/
Forums: http://forum.naev.org/ (Forums are lost.)
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
-
Naev 0.5.1 Release
BY BOBBENS, ON MARCH 1ST, 2012
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.
Download: https://sourceforge.net/projects/naev/files/naev-0.5.1/
Blog: https://naev.org/
Forums: http://forum.naev.org/ (Forums are lost.)
List of changes since 0.5.0:
For Players:
- 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
For Developers:
- 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
-
XDG Part Deux
BY DEIZ, ON FEBRUARY 20TH, 2012
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.