naikari / naikari Goto Github PK

Naikari version

285536c (most recent main)

Describe the bug

In most games there is no downside to skipping the tutorial (e.g. if you have played the game before), but in naikari there is content that is directly or indirectly gated behind completing the tutorial:

• empire/emp_cargo00.lua
• empire/es_cargo.lua
• empire/es_longdistancecargo.lua
• empire/hakoi_pirates/emp_hp01.lua
• neutral/trader_escort.lua
• soromid/comingout/srm_comingout3.lua
• soromid/comingout/srm_comingout4.lua
• soromid/comingout/srm_comingout5.lua
• soromid/comingout/srm_comingout6.lua
• tutorial/reynir.lua
• baron/baron_baron.lua
• baron/baron_prince.lua
• tutorial/teenager.lua
• shadow/shadowrun.lua
• shadow/shadowvigil.lua
• shadow/darkshadow.lua

Expected behavior

It should be possible to access all the content without completing the tutorial.

Additional context (optional)

If you have ideas how to fix it, I can code them.

Rationale

The starmap currently shows what systems you need to go to for a mission objective, but doesn't provide an easy way to review which missions are in which system visually. To find out what missions are in which system, you need to look over the OSD or the Missions tab in the ship computer manually. In some situations (e.g. if you've accepted a rush cargo mission and a regular cargo mission), this information could be significant because you would want to complete certain missions first.

Proposal

It should be fairly easy to add a display somewhere on the starmap indicating the current objective of the mission(s) in the selected system. There isn't enough room on the margins, but given the nature of such a display, something like a semi-transparent box over the map on one of the corners should suffice.

Alternative solutions

The person who suggested something like this actually suggested simply highlighting entries on the OSD. This would work at higher resolutions, but not at 720p as the starmap takes up the full game window in that case. Given that, I think it's best to put the display in the starmap window itself.

Additional context

This came from a suggestion by a player via email. Posting this here so that we don't forget.

Describe the issue

Hi 👋

Context: Yesterday, I learned about Naikari while browsing similar games at the Flathub store. Being a long-time Naev fan, I had to give Naikari a try. Things got interesting when the good old "Naev music theme" kicked in when I launched the game. So I got to the FAQ section, followed the rabbit down the hole, and learned about the discussion thread referenced there. I'm telling this because the comparison I'm about to make next is in good faith, with zero intentions of spawning a meaningless conversation. Life's too short to waste on stuff not close to our hearts.

The issue: I can see in top that Naikari consumes as much as double CPU cycles than Naev, sometimes thrice (even when at the menus or with the game running in the background):

System specs desktop:

OS: Fedora Linux 39 (Kinoite) x86_64
Kernel: 6.7.9-200.fc39.x86_64
DE: KDE Plasma 5.27.11
WM: KWin (Wayland)
CPU: Intel(R) Core(TM) i9-9900K (16) @ 5.00 GHz
GPU: NVIDIA GeForce RTX 2080 Ti Rev. A

System specs laptop:

OS: Fedora Linux 39 (Kinoite) x86_64
Kernel: 6.7.9-200.fc39.x86_64
DE: KDE Plasma 5.27.11
WM: KWin (Wayland)
CPU: 11th Gen Intel(R) Core(TM) i7-11370H (8) @ 4.80 GHz
GPU: Intel Iris Xe Graphics

Are these values expected?

Additional context (optional)

Running Naikari version 0.12.0.
Both Naikari and Naev are installed as flatpaks.

Thanks,
-Martín

Naikari version

0.2.0

Describe the bug

The Game doesnt Start, it only shows the Console for a few moments and then everything closes.

To Reproduce

Start the game.

Expected behavior

The game should start

Screenshots (optional)

https://imgur.com/a/gAoMDKT

Naikari version

0.5.0

Describe the bug

Sometimes, when Naikari loses focus for awhile (say I leave the game running and go to look at my Discord messages for a bit), the window seems to freeze up for a period of time, sometimes several minutes. It always eventually starts working again, but the freeze sometimes causes the entire system to freeze up, making even the mouse cursor unresponsive. Only witnessed on my Linux setup so far.

To Reproduce

Steps to reproduce the behavior:

1. Start a game, wait on the land window.
2. Change focus to something else. Do something for awhile.
3. Re-focus Naikari.

Expected behavior

Nothing should happen in this situation; the game should continue as normal.

Additional context (optional)

I've so far witnessed this on Debian 11 "Bullseye", using GNOME with Wayland, and running the game through GDB with the naikari.sh script in a developer setup. Other than simply not responding (prompting GNOME to ask if I want to force-quit the game), no errors are outputted. I've also checked RAM usage and found it to be normal, so there's seemingly no problem there.

I do not know if this bug affects actual release builds; for testing purposes, I pretty much always run a test environment, just in case I run into a rare bug and need to diagnose it. I also do not know if this affects systems other than my own. As it is, for all I know, this bug could just be a GNOME bug, or a GDB bug, or any number of other things. Unfortunately, it isn't consistent enough to know for sure.

If this bug occurs for anyone else, please let us know (and let us know what system it occurred under for you). We would also be appreciative if anyone has any idea of what might cause this.

Rationale

The Brushed GUI looks nice, but is sub-optimal as a functional GUI due to its layout. Many people in the Naev community have noted how wasteful it is of vertical real estate. However, the Slim GUI (which is generally laid out better) looks a lot worse. We need a nicer GUI that combines the advantages of both.

Proposal

We are working on a GUI called "Neo" to serve as the new default GUI. This GUI will be designed to be simple in its design, nice-looking, and most importantly, out of the way (by taking up plentiful horizontal space rather than limited vertical space).

We have drawn a mockup of how we intend to make Neo look, and how we intend to lay it out:

The black background of the sidebar will be semi-transparent; it is opaque in this mockup so that the Slim GUI below it doesn't obscure its layout. The planet overview panel will also have the same look and semi-transparent black background, while the bottom bar will either be opaque black or semi-transparent black with text. All bars will be given opaque black backgrounds to ensure maximum visibility for them.

The bars shown are:

• The shield bar. Text will be contained showing the shield amount in GJ.
• The armor bar. Text contained will show the armor amount in GJ.
• The battery bar. Text contained will show the battery amount in GJ.
• The speed bar (showing how fast you are currently moving). Text contained will show the speed in mAU/s.
• The heat bar (showing the ship's current temperature). Text contained will show the heat in K.
• An example of a weapon bar.

Weapon bars will be used for both true weapons and activated outfits. The weapon bars will be laid out as follows:

• The box on the left (which is empty in this mockup) will be filled with the store image for the respective weapon/outfit, similar to how Slimv2 does it.
• The sword icon will indicate that a weapon is primary, a shuriken icon will indicate that it is secondary, and a number will be placed there for activated outfits and weapons which are only on an instant weapon set. The circle behind it will fill to indicate fire delay time (similar to the tiny bar in the Slim GUI). In the case of launcher weapons with a lock time, it will instead be an indicator for lockon.
• The circle under the flame icon will indicate the heat of the weapon/outfit.
• The main bar itself will be used for weapon ammunition, if any, in which case the number will show the number of shots (despite the percent sign in the mockup, only an absolute value will likely be used). For weapons that don't have ammunition, it should ideally be used for some other purpose. This part isn't entirely decided, but for activated outfits and beams, it can serve as an "indicator light" showing that the outfit is on. The text could possibly show "On" or "Off", or alternatively may be unused. In cases where we can't find a use for the main bar, it may just be left blank or possibly redundantly copy one of the two sub-bars.

Alternative solutions

It would be possible to update the Slim GUI with a couple extra features and use it as the default, but Slim doesn't look very good and has a horrendously messy codebase. I think an entirely new GUI is the best solution.

Naikari version

Naikari v0.9.0 (linux-x86_64)

Describe the bug

As the title say, the game do not launch and give me this Error:
ERROR ../src/opengl.c:297 [gl_createWindow]: Unable to create OpenGl context! Could not create GL context
Aborted (core dumped)

To Reproduce

Steps to reproduce the behavior:

1. Try to launch naikari
2. Faild

Expected behavior

well you know, Launch the game or something like this.

Additional context (optional)

It's a old laptop, but it's should be running Opengl 3.2
Arch Linux btw. ;)

Rationale

Naikari currently has a problem where multiple copies of the same sound file can play at once, amplifying each other. Depending on the global sound volume setting and the level of amplification, this can have one of two effects:

1. If the sound volume and level of amplification is low enough, the amplification simply leads to a sudden volume increase, which while not always unpleasant can be annoying particularly if the player is wearing headphones and wasn't expecting the volume increase, or if the game volume set by the player was particularly low and they had their speaker volume turned up particularly high as a result.
2. If the sound volume is very high (particularly if it is at maximum), audio from the amplified sounds can become horribly distorted as the mixer is forced to clip the volume down to a lower level.

Proposal

A simple and effective way to eliminate unwanted sound effect amplification like this is to cause newly playing sounds to interrupt previously playing identical sounds, or in some cases, previously playing sounds that serve the same purpose.

In Naikari's case, the simplest implementation would be to do so on a per sound file basis, with a simple check to make sure that very quiet sounds in the distance don't override very loud nearby sounds. Some sounds would likely be exempt from interruption by identical sounds, or would have modified behavior, on a case-by-case basis. For example, since beam sounds are meant to stop prematurely along with the associated beam, it may make sense to exempt those sounds (allow them to play without limit), or to give them some form of special handling to minimize weirdness (e.g. exempting distant distant beams but causing nearby beam sound effects to keep playing until all nearby beams using the sound have stopped).

Alternative solutions

A fancier potential approach to this problem would be to dynamically adjust the game's volume based on how many sound effects are being played. Such a system would be interesting and has been used in games to simulate particularly loud noises like gunshots in a more realistic fashion than usual, but would likely be far too complicated to be worth the minor audio benefits it would offer a game like Naikari.

Additional context

Both problems this feature would fix can be seen in this short video clip (the second problem is shown first):

Naikari version

v0.6.0

Describe the bug

Some planets (e.g. Alleyway) have a black market despite not selling ships or outfits. Is this intended? What is the point?

Expected behavior

Remove the black market or add ships or outfits

Describe the issue

Naikari's MacOS support, inherited from Naev, is a bit outdated, with only unsigned x86 builds available. It seems that Naev has updated their own MacOS support, but I don't feel up to the task of also updating the support for Naikari, particularly because I don't know much about MacOS and Naikari's codebase and build system has diverged enough from Naev's codebase and build system that I can't just simply cherry-pick those improvements anymore. If anyone more familiar would be up to the task, assisting with this would be a great help, even if it's just porting over the improvements the Naev project has made.

Naikari version

v0.10.0 (from flathub)

Describe the bug

Ian from Ian's Courage can not jump if the player's maximum speed is too low.

To Reproduce

1. Switch your ship to Soromid Vox (I did not test with other ships)
2. Start the Ian's Courage mission
3. Follow Ian to the jump
4. When Ian reaches the jump, he just spins there instead of jumping; the mission soft-locks

Expected behavior

Ian jumps to the next system

Screenshots (optional)

Additional context (optional)

1. From my lua debugging this appears to be caused by ai.minbrakedist() returning a negative number which prevents the __hyp_approach task from completing
2. Unsetting the speed limit on Ian's ship fixes this issue
3. From gdb: In the below code vel is 0.0001 because cur_pilot->speed is 0.0001 (may be related to pilot_updateMass), but time is calculated based on VMOD(cur_pilot->solid->vel) which is, for example, 5.345411405711415. This causes dist to be negative
   

   naikari/src/ai.c

   Lines 1492 to 1504 in 1cab4ac

   	else {
   	/* Get current time to reach target. */
   	time = VMOD(cur_pilot->solid->vel) /
   	(cur_pilot->thrust / cur_pilot->solid->mass);
   	/* Get velocity. */
   	vel = MIN(cur_pilot->speed,VMOD(cur_pilot->solid->vel));
   	}
   	/* Get distance to brake. */
   	dist = vel*(time+1.1*M_PI/cur_pilot->turn) -
   	0.5*(cur_pilot->thrust/cur_pilot->solid->mass)*time*time;
   	lua_pushnumber(L, dist); /* return */

4. I think replacing the line 1498 with vel = VMOD(cur_pilot->solid->vel) might fix this (did not check).