Naev - Naev Development Blarg (Page 14)

Slots branch merged

BY BTAXIS, ON AUGUST 19TH, 2012

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!

Ship stats

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 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.

Mass limit

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.

Other changes

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 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.

Naev 0.5.3 Release

BY DEIZ, ON APRIL 15TH, 2012

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 %APPDATA%\naev\ to naev-data\ within the directory Naev is installed to.

Download: https://sourceforge.net/projects/naev/files/naev-0.5.3/

Blog: https://naev.org/

Forums: http://forum.naev.org/ (Forums are lost.)

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.

End of the 0.5 Release Cycle

BY BOBBENS, ON APRIL 7TH, 2012

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!

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.

An afterburner that's heating up

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.

A Lancelot in Active Cooldown mode. When the bar has completely emptied, the cycle is complete.

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 Development Blarg (Page 14)