You can grab nightly releases on the nightly release page, which is automatically rebuilt at roughly UTC 09:00 every day. Note that this build is likely to contain some bugs and save files may break in between nightlies.
Some Windows sound drivers don't provide OpenAL. If you have no sound, download and install OpenAL from here.
This almost always means that your hardware doesn't support a recent enough version of OpenGL. Naikari requires OpenGL 3.1 or later to work; for reference, the oldest Intel integrated graphics controllers which support OpenGL 3.1 or later are Intel HD 2000 and Intel HD 3000 (of the Sandy Bridge micro-architecture, first released in 2011). On Linux, you can confirm what OpenGL version your system supports by using glxinfo, e.g.:
glxinfo | grep OpenGL | grep versionIf you have a graphics controller or graphics card which doesn't support at least OpenGL 3.1, you unfortunately will not be able to run Naikari. Depending on your machine, you may be able to get around this by getting a graphics card which supports OpenGL 3.1 or later. Even fairly old graphics cards should suffice.
Other than that, if anyone would be willing to contribute a compatibility option so that Naikari can run on OpenGL 2.1, please get in contact with us.
While not ideal, on Linux, you can run Naikari in software mode if absolutely necessary by setting the LIBGL_ALWAYS_SOFTWARE environment variable to true:
LIBGL_ALWAYS_SOFTWARE=true ./naikari-0.10.0.AppImageIt's plausible that this method could also resolve hardware compatibility issues, but we can't guarantee this.
SDL doesn't use its Wayland video driver by default, but Naikari may require the Wayland video driver when run in a Wayland environment, depending on your distro and/or setup (we don't know exactly what factors cause the problem). The reason for the X11 driver being the default is a bit complicated, but explained in the commit that reverted the change that would have made the Wayland video driver the default (libsdl-org/SDL@254fcc9). SDL 2.0.22 has a mechanism in place to define Wayland as preferred, which should theoretically solve the issue, but older SDL versions will continue to be in use for some time, so that solution is not feasible for official builds in the short-term. In the long-term, we suspect this issue will go away on its own as things mature on the Wayland front.
For now, if Naikari will not start up for you because you are using Wayland, you can fix the problem by setting the SDL_VIDEODRIVER environment variable to wayland, e.g.:
SDL_VIDEODRIVER=wayland ./naikari-0.1.0.AppImageThis should work, thô colors may be distorted depending on your system; you can correct this by adjusting gamma in the Options menu if it occurs.
"Naikari" was picked as a portmantô of the Japanese words ない ("Nai" – is not) and 光 ("Hikari" – light).
In short, the reason for the fork is irreconcilable disagreements with Naev's lead developer over the direction the project should go and what kind of game it should be. It took us longer than we'd like to admit to fully realize what it was we originally saw as potential in Naev, but we want to realize that potential in a way that we don't think Naev can.
As of Naikari 0.12.0, the differences are not likely to be all that impressive. They include such things as interface overhauls, quality-of-life touches, and story changes. For the upcoming 0.13.0 release, we're more-or-less completely restarting work on the game from the ground up and putting an emphasis on player creativity, freedom, and exploration. For more information, see Giving Naikari a massive makeover.
No.
When we (Diligent Circle, Naikari's lead developer) started this project, we initially attempted to continue collaborating with the Naev project. This naturally gradually decreased over time as the projects diverged and the two projects became less and less compatible, but we entirely ceased submitting pull requests when in Naev PR #1801, Naev's lead developer, bobbens, accused us of taking a "narrow and egotistical view of open-source development", not acting in good faith, and "knowingly" risking "introducing bugs to Naev". All of these accusations were in response to a sentence we included in the PR which stated that the bugfix the PR was for may have not covered cases that weren't shared between the two projects.
After this, we continued to participate in some discussions on Naev's issue tracker and Discord server, but were banned both from Naev's GitHub page and from Naev's Discord server for our posts under Naev Issue #2062 expressing disagreement over sound design. The reason we were banned wasn't for any actual violation of Naev's Code of Conduct; rather, bobbens claimed that our "insistence" was "toxic" and ordered us to "refrain from non-productive discussion". When we responded to that by complaining that bobbens was actually in violation of his own Code of Conduct on the grounds that he had launched a series of personal attacks at us, and complaining that he was abusing his power as a community leader, he blocked us from Naev's GitHub page, indicating said response as the reason. A few moments later, he also banned us from the Naev Discord server.
Given our experience with Naev's lead developer, bobbens, which is succinctly summarized by our final interaction with him in Issue #2062, even if we're unbanned from Naev's GitHub page and Discord server, we have no further intention of collaborating with him.
In short, no. Naikari is designed in such a way that the rate of passage of time is routinely adjusted as a part of its normal gameplay. This makes any sort of multiplayer impractical without completely redesigning the game. Endless Sky, whose design is somewhat similar to Naikari's, is likely more suited to being turned into a multiplayer game than Naikari ever will be.
That said, if someone wants to implement it, we are not opposed to accepting a contribution adding either a sort of cooperative gameplay with additional players piloting escort ships, or a sort of deathmatch gameplay mode. These sorts of minor multiplayer additions would be feasible.
That's actually a diaeresis, not an umlaut, and it has a different meaning. An umlaut (as used in languages like German) modifies the pronunciation of a single vowel. By contrast, a diaeresis doesn't modify pronunciation; rather, it indicates that two consecutive vowels (like the "a" and "i" in "naïve") are pronounced separately, rather than as a unit.
Naikari uses this convention, which most people consider antiquated or "obsolete", as a matter of style. To be more specific, we use it for any vowel hiatus which is made up of one of the following pairs of letters:
- "ai" (as in "naïve")
- "ee" (as in "reëxamine")
- "oa" (as in "koäla")
- "oo" (as in "coöperate")
Naikari also makes use of the grave accent within the context of the Siriusites: they have a special class called the "touchèd". The grave accent here indicates that the letter is pronounced where it normally wouldn't be, as in the real English words "learnèd" and "blessèd".
While American English spelling is generally used, Naikari intentionally uses some spellings that are generally regarded as "incorrect". Here is a list:
- "Halapenyo": An anglicized spelling of "jalapeño" we made up.
- "Miniscule": A common alternate spelling of "minuscule" which is usually regarded as an error.
- "Persue": A common "misspelling" of "pursue".
- "Rondévu": A different spelling for "rendezvous" we made up.
- "Thô": An alternate spelling of "though". The circumflex is a call-back to a period of time when "-ough" was occasionally respelled "-ô" to save on paper.
- "Thru": A popular alternative spelling of "through".
We intentionally chose these spellings just because we like them better. This is especially the case for "thru" and "thô", as these alternative spellings avoid both of these words looking so similar to each other and to "thorough".
These are all known launch options for Naikari when run from the commandline:
| Launch Option | Description of Usage |
|---|---|
| -f, --fullscreen | activate fullscreen |
| -F n, --fps n | limit frames per second to n |
| -V, --vsync | enable vsync |
| -W n | set width to n |
| -H n | set height to n |
| -j n, --joystick n | use joystick n |
| -J s, --Joystick s | use joystick whose name contains s |
| -M, --mute | disables sound |
| -S, --sound | forces sound |
| -m f, --mvol f | sets the music volume to f |
| -s f, --svol f | sets the sound volume to f |
| -G, --generate | regenerates the nebula (slow) |
| -d, --datapath | specifies a custom path for all user data (saves, screenshots, etc.) |
| -X, --scale | defines the scale factor |
| -h, --help | display this message and exit |
| -v, --version | print the version and exit |
| OS | Path |
|---|---|
| Windows | %APPDATA%\naikari\ |
| macOS | ~/Library/Application Support/naikari/ |
| Linux | ~/.local/share/naikari/ |
Saves and screenshots can be found in the saves and screenshots directories, respectively.
| OS | Path |
|---|---|
| Windows | %APPDATA%\naikari\conf.lua |
| macOS | ~/Library/Preferences/naikari/conf.lua |
| Linux | ~/.config/naikari/conf.lua |
Not as such. However, the Lua console (accessible with F2) allows you to modify many things, including adding credits, refuelling, and adding outfits.
Some simple examples:
player.pay(1000000) -- This will give you 1,000,000 credits.
player.refuel() -- This will fully refuel your ship.
player.teleport("Gamma Polaris") -- Teleports you to Gamma Polaris.
player.outfitAdd("Turbolaser", 6) -- Adds 6 Turbolasers to your owned outfits.And a slightly more complex set:
player.pilot():setInvincible() -- Makes you invulnerable until you next reload.
player.pilot():setInvincible(false) -- Makes you vulnerable again.
player.pilot():setHealth(100, 100, 0) -- Restores all shield and armor, and undisables you.
player.pilot():setEnergy(100) -- Fully recharges your battery.
player.pilot():fillAmmo() -- Refills all of your ammo to max.
faction.get("Empire"):setPlayerStanding(100) -- Makes your Empire standing 100%.For (much) more, see the full Lua API documentation.
Naikari uses gettext for translation. The translation files are found in the po subdirectory.