onlinecop / kq-fork Goto Github PK

The game should run in a window by default.

KQ crashes a few seconds after the intro, displaying the message

Could not parse script global.lob!

KQ has borrowed graphics from many other games, some of those are non-free.

It would be preferable that all graphics came from free sources, or were created specifically for this game (and given an open license so it could be distributed in major Linux communities and mods).

One suggestion was to use artwork from OpenGameArt.org. Some that look promising are:
http://opengameart.org/content/liberated-pixel-cup-0
http://opengameart.org/content/lpc-tile-atlas

Please contribute to this issue with other suggestions.

NOTE:
KQ currently uses 16x16-pixel tiles, and stretches them up to 32x32. If we want 32x32-pixel graphics, some changes to the engine need to be made.

Personally, I'm in favor of changing to 32x32-pixel graphics. Modern computers can handle the memory requirement, and graphics look a lot sharper. Unless we WANT a Minecraft-esque 16-bit look to the game ;-)

When I launch the game, I see "ERROR: Error with sound: MOD support not available" on the console output.

If I open the Config window from the main menu, "Sound System" is OFF and toggling it ON does nothing: I see "...Please wait..." briefly, but it does not change to ON.

1. I can start a new game, and do not crash throughout the opening dialogue or on the world map.
2. If I load a game, in Mix_Volume() the line prev_volume /= num_channels; has num_channels set to 0, causing a divide-by-zero error.

The "fullscreen" mode of the game currently just add black borders around the screen (at least on machine). This should be replaced by a true fullscreen mode.

KQ v1.0 won't be released until there's absolutely zero memory leaks from KQ itself.
Some libraries like Allegro and Lua may leak, but since theses aren't linked to KQ's source code, they won't be taken into account.

KQ should definitely switch to a clean CMake system that doesn't shit all over the place everytime you want to compile the game.

Just spotted this whilst doing something else, I think the '10' should be '1000' or maybe just drop the condition altogether?
https://github.com/grrk-bzzt/kq-fork/blob/master/src/draw.c#L641
https://github.com/grrk-bzzt/kq-fork/blob/master/src/draw.c#L665

I noticed that there is a branch where the code has been converted to C++ but this has fallen behind master recently. Is the intention to switch to C++ at some point? Personally I would support this because I find implementing lists, maps etc a bit of a pain in C; using the STL containers is easier/less error prone. I wouldn't be in favour of a wholescale 'convert everything to classes' rewrite though.

Sometimes, KQ freezes right at the start when the Staff appears for the first time. The debugger shows it is held in a very long Sleep function.

If possible, the current KQ map editor should be droped in favor or Tiled.

Tiled is a powerful and mature FOSS map editor which should allow much better and complex editing of KQ.

Perhaps this is only happening on my system with its specific implementation of C++, or maybe I'm not the only one who failed to actually try to start playing the game and instead was satisfied with a successful compilation. Either way, whenever I try to start a new game (through "continue" or "new game" on the main menu), the program has a segfault. Here's an example backtrace in gdb:

#0  0x00007ffff720d7cc in std::string::assign(char const*, unsigned long) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#1  0x000000000040de4c in load_s_map (sm=0x662f80 <g_map>, f=0x994b20) at /home/phin/kq-fork/src/disk.cpp:145
#2  0x000000000042f540 in load_map (map_name="starting") at /home/phin/kq-fork/src/kq.cpp:1323
#3  0x000000000042e756 in change_map (map_name="starting", msx=0, msy=0, mvx=0, mvy=0) at /home/phin/kq-fork/src/kq.cpp:754
#4  0x000000000042f86a in main (argc=1, argv=0x7fffffffe458) at /home/phin/kq-fork/src/kq.cpp:1392

Here's the relevant code in disk.cpp (in the load_s_map function):

buf = new char[16 + 1]; // was hard-coded to be 16                                                                                                                                                                                
memset(&buf[0], 0, 16 + 1); // Clear all garbage values to '0'                                                                                                                                                                    
pack_fread(buf, 16, f);                                                                                                                                                                                                           
if (strlen(buf) > 0)                                                                                                                                                                                                              
{                                                                                                                                                                                                                                 
    sm->song_file = buf;                                                                                                                                                                                                          
}                                                                                                                                                                                                                                 
delete[] buf;

I admit that I'm new to the whole concept of manual memory allocation, but I think I have it figured out. I think that when sm is originally created (somewhere in kq.cpp), it allocates enough memory for every element in the s_map struct. However, that object gets passed through a couple of functions, before ending up in load_s_map, where all the values are set. When it comes to setting sm->song_file (and sm->map_desc), it tries to re-allocate memory to fit a bigger string, but it's already lost authorization to change the surrounding memory, so it has a segmentation fault.

Maybe I'm wrong here, but after spending the past few hours trying to understand, this is what makes the most sense. Am I right here? Is it a problem with scope and memory allocation? It seems to me like the simplest fix would be to change those back to statically allocated char arrays. I can't figure out how to fix this and retain strings.

Related to #75, in the configuration screen to change the keyboard inputs, the default keys for Cancel and Accept are CTRL and ALT, respectively.

When you select one of the options to remap and hit Accept to begin to scan for the new keyboard input, there is no wait for the Accept button to be released before the new key is read in.

There needs to be a delay before the new key is read in, or else listen for the release event for whichever button is currently set for Accept. Only then, it should read in the new key for the selected option.

There's a lot of unnecesary files in the repo. Files for making Debian packages, old useless Makefiles.
This should all be clean and tidy!

Not a big deal, the only time I've noticed is when typing lua code into the console as many functions have underscores in their names. Just need to edit fonts.png I think, there is a gap between ^ and ` in the image.

The player's first battle appears to be extremely difficult and unbalanced, and the player's probability of success is highly dependent on random chance in picking a few weak enemies for the first battle. Because Noslom's hit points are so low that he cannot afford to take two rounds of enemy attacks and survive, he is basically forced to cast Cure1 every turn and hope for a miss (or misses, in the case of multiple enemies) allowing him to actually damage the enemies.

KQ currently need Allegro 4 to compile, it should use a modern library instead.

The http://kqlives.sourceforge.net wiki has been updated to kinda work, although many features (LikePages, BackLinks) are not functional. There is almost no login authentication, which means that it might be easily vandalized.

Bu-u-u-ut... should we link it to this project (or this project back to it)? It can be used as a reference for people wanting to contribute, or just to figure out what was happening in the (unfinished) storyline.

Holding down the CTRL key used to enable a run mode but this no longer functions on the road-to-1.0 branch

When I first enter the temple, I get this error and kq crashes.

PANIC: unprotected error in call to Lua API ([string "./scripts/temple1.lua"]:28: attempt to call global 'int' (a nil value))

I added a print statement into the file to find out what value the variable has at that moment but that didn't work. print("test") has no effect either.

You can see the crash at the end of http://youtu.be/W0Z-q12Gpj4

When I try to run the kq-fork executable outside of its folder (e.g. cd build && ../kq-fork), it throws this error: Could not load misc.pcx!.

I'm running Linux Mint 17.2.

When you first arrive in Randen, Casandra awaits, saying something about you having rescued her(?) and offering to join.

If you let her join and return to the city, she will still be there, offering to join.

Arrival: https://youtu.be/QW7-I1Ak6Gg?t=46m49s
Re-entry: https://www.youtube.com/watch?v=XMzbJwg2yYg

This seems to be related to scripts/town2.lua, the sidequest2 variable and en == 13, making Casandra be present.

The strange thing is that Ajathar doesn't re-appear near the tunnel/cave entrance but Casandra does.

KQ v1.0 won't be released until the story is finished.

For now, most of the game assets is packed into data/*.dat files.
They should be unpacked for easy modification.

It would be cool to get to a 1.0 release before the 20th anniversary of kqlives September 2022. Well at least going off the sourceforge changelog history.

I finished Ayla's quest, added Sarina's quest(its a bit lame, sorry) and added in some ending(s). I cut out the AirTank and replaced it with a magic trident but followed the outlined plot at least roughly.
I also replaced most of the enemy graphics with those from Dungeon Crawl 32x32 Tiles. I kept some (the dragons and giants) that seemed to be original, if you find that's not the case you can let me know.

You can check it out at
https://github.com/OnlineCop/kq-fork/tree/road_to_1.0

Stuff left to do: (Mirrored from https://github.com/OnlineCop/kq-fork/wiki/Road-to-1.0)

• Doom and all Death spells don't appear to work anymore (The idea was that opal armor when the staff is nearby gives you immunity to everything except Death spells but as they aren't working right now I didn't reduce magic damage)
• Set up zone 0 combat for cave6a, cave6b, cave9, pass2 and main map combats for zones 86-90 (I added 8 more sprites after the dreadpede that could be used. The rat looking guy was an idea for the boss at the end of cave6b where you get the trident). -- Mostly done
• Encounters especially the new ones I made could use a balance pass
• Change character graphics I was leaning towards https://opengameart.org/content/18x20-characters-walkattackcast-spritesheet but that requires modifying the engine to support slightly bigger sprites
• Add in a scene where if Ayla is in your party and Nostik has left the manor you can break into his room and find a mysterious letter from "M" (Malkaron)
• Check for bugs (the coliseum has some edge cases that might show up)
• Change tile graphics
• Change music not created by Josh's cousin as outlined in the sourceforge posts as outlined on the wiki page

Now that kq-fork uses TMX instead of own map format, the map* utities (mapdiff, mapdraw and mapdump) do not succesfully compile anymore, complaining about the lack of load_s_map and load_s_entity functions. This results in annoying clutter during make (aka make all). Should they be replaced by their TMX equivalents or removed altogether?

There is a game based on the same engine (and plot as far as I can tell):
http://sourceforge.net/projects/kqthebetrayer/ (KQTB)

I'm not sure whether it has a finished plot or not.

It could be considered whether KQTB should be included in a single kq game distribution and whether the KQTB plot could aid finishing KQ's plot.

TMX is a standardised file format used by the map editor Tiled.

Converting all our maps to TMX will allow us to get rid of the map editor and therefore have less code to maintain while using Tiled for maps creation and modification.

Commit hash 229f638, which is derived from the peterhull90/xml branch, allows a player to continue a saved game, which has been stored in XML format.

If a player saves to a new slot, then goes back to the Load/Save menu, the new save does not appear. The slot is only visible after restarting KQ.

After a player saves, reopening the Load/Save menu should show the changes to the save game slots properly.

Some errors here and elsewhere from ce01e00 I think.

kq-fork/src/tiledmap.cpp:682:58: error: expected
      '(' for function-style cast or type construction
                unsigned int index = std::clamp(unsigned int(i + zone.x ...
                                                ~~~~~~~~ ^
1 warning generated.
kq-fork/src/entity.cpp:546:47: error: expected '(' for
      function-style cast or type construction
        int dest_tile_x = std::clamp(unsigned int(source_tile + dx), 0U...
                                     ~~~~~~~~ ^
kq-fork/src/entity.cpp:547:47: error: expected '(' for
      function-style cast or type construction
        int dest_tile_y = std::clamp(unsigned int(source_tile + dy * g_m...
                                     ~~~~~~~~ ^
1 error generated.

While entering caves or buildings with a partner sometimes the partner goes out of bounds and causes the game to crash.
It crashes on line Entity.cpp:622 with an out of bound error. dest_x is a very large negative number e.g. -65282.
This happens often when the warp to position is near the bottom of the map.

I believe the Staff is a two-handed item, meaning that it forbids me from equipping a shield with it.

I bought all the available weapons and armor, except the Staff, in Ekla. When I use Optimize, it fills most of the slots, with exception of Other, with a weapon, shield, helmet, armor and gloves.

After I bought the Staff and use Optimize to equip it, it clears all other slots except for Hand1, where Staff is located.

While it's fine to unequip the Hand2 item (like a shield), it shouldn't affect the other inventory.

_Note: This idea is part of KQ v2.0, therefore it is at the very bottom of the priority list until KQ v1.0 get released._

I though about this while looking at Frogatto and the Anura engine.

It would be very interesting if we had the engine on one side, completely written in C (and C++ if that's necessay), and the game on the other side. Both in their independant repo.

The idea would be to have a single engine capable of running several games without modification of the C code.

For instance, the engine would have a games/ directory in which you place a directory containing the images, sounds, and scripts, like this:

games/
  - kqclassic/
      - scripts/
      - sounds/
      - musics/
      - images/
      - maps/

The game would be ran like this

kqengine --game kqclassic

Several dependencies are required to get KQ to build on Windows, and if we could list the required steps, from ground zero to finish, that it would take to compile, it would be very useful.

• MS Visual Studio Community edition is free, and widely supported.
• Allegro4 may be easy to set up, although many of the online documentation are for MSVC 5 or 6, and may need some updates
• Dumb, TinyXML2 and Lua, if I'm not mistaken, only require a few source files to be dropped into the project directly without the need to build a library for them first. If that's the case, give steps!

It might even be useful if a "shell" project could be created and zipped, which would contain most of the files, where the only remaining tasks would be to clone the kq-fork repo into it.

Thoughts? Or would be be better to just list the steps and let the developers download and run it all themselves?

As I was playing through I got to the point where you actually get the opal armor as items(not key items) and my inventory was full so it just said opal band not received.

What should we do?

• Simple 3x the Inventory space is currently 4 pages of inventory.
• Make it endlessly expanding up to say like 99 pages
• Just check to make sure you have room for the opal armor first. Downside of this approach is we might need to adjust chest logic as well to not count as opened if you don't receive it. There are some places I think in the scripts where items are added that it wouldn't catch but it should take care of most cases.

In parse_allegro_setup (setup.c:701) it uses kqres() to get a path to the config file kq.cfg. If this file does not exist it looks for setup.cfg. Unfortunately kqres only returns a pointer to a static buffer, so, if kq.cfg doesn't exist, by the time it's got to line 739, the string has been changed (by the call to parse_jb_setup.) Therefore kq.cfg is never created.

The origin of this convoluted code was that I wanted to switch from the original file format in setup.cfg to use Allegro's config functions. The code was supposed to use the new config file if it existed, but load the old format and then convert it if it didn't. To be honest it wasn't really worth the effort.

This is true of unix.c, it may not be on other platforms. (I didn't check). Also there are a few hard-coded max path lengths in unix.c. If you're re-writing it might be as well to improve this.

KQ v1.0 won't be released until there's absolutely zero compilation warnings.
The whole project have to be warning-free on both clang and gcc when compiled with -Wall -Wextra.

The proposed Tiled map format uses TMX, which uses an XML-formatted structure. It would be nice if a lot of our hard-coded values could be exported to an easier-to-read and easier-to-change format: XML or JSON. I guess we could also go a stronger LUA route, pushing as much as possible off into lua, although I prefer that data be kept in a more data-friendly format, and leave LUA to processing logic.

Two proposed JSON libraries were:

• https://github.com/udp/json-parser
• https://github.com/akheron/jansson

@peterhull90 indicated some familiarity with the former, stating that it was simply two files, json.c and json.h, that need be included. In a few local cases, I've tried to read in a JSON-formatted file using udp/json-parser with mixed results. From what I can gather, its strength is in reading JSON, but outputting JSON would require something else.

Online sources for C-based JSON libraries lead me to jansson although I have no experience with this. If it supports reading/writing and isn't too convoluted to get into place, it may be a good direction to go.

The other option is to look into storing data as XML. There is no shortage of C-based XML solutions out there, if we want to go that route instead.

Move everything in combat.cpp/combat.h into a KCombat class.

make fail to compile KQ because of an error in maps/mainwindow.c

maps/mainwindow.c:430:10: error: too few arguments to function ‘set_bounds’
          set_bounds (&temp_bound, x1, y1, x, y);

maps/mainwindow.c:441:13: error: too few arguments to function ‘set_bounds’
             set_bounds (&gmap.bounds.array[i], x1, y1, x, y);

Casandra is displayed in town2, even if you haven't "earned" her. She's also there when you have her in your party:

She also looks different in this shot: the NPC image is used to depict her when she's part of the "town entity" logic, but changes to different attire (brown cape vs. white dress) when she's in your party.

onlinecop branch: Create a KHero class.
Move all static functions defined in heroc.cpp into KHero, under private scope.
Move global functions into KHero, under public scope.

The source code for the map editor should be moved to it's own repo if possible.

Back then, the Lua code was probably compiled for performance reasons.
However, that kind of performance trick is irrelevant on today's computers.

Being able to run on uncompiled Lua scripts could allow faster modification of the game without having to recompile everything every time.

I have no precise idea on that subject, please let me know what you think.

Right now, music and sprites are in different directories.
Everything that isn't code and that is required for KQ to run should be moved into a single data/ folder.

That will also allow to remove the data from the repo and move it elsewhere.
I can host the game files on my personnal server before we find a permanent solution.

On Windows, compiled from VS2022, the game opens by default in windowed mode.

Steps

1. Open the Options from either the title screen or during gameplay.
2. Toggle Windowed Mode from YES to NO and confirm the choice, or
3. Toggle Stretch Display from YES to NO and confirm the choice.

Actual

1. A second window opens over the first.
   1. For Windowed Mode, the second window is the same size as the first; for Stretch Display, the second window is about 1/4 the original window's size.
   2. The first window continues to display the "Switch to full screen?" or "Switch to windowed mode?" prompt.
   3. Focusing the first window and moving the cursor (up/down arrows) redraws on the second window, but the first window does not update.
   4. Clicking the window's [x] in the top-right corner does not close the window or the main application.

Expected

1. There should not be a new window.
2. For Windowed Mode, the application should switch to fullscreen mode.

A user reported that no sound was playing on Mageia Cauldron x86_64.
We hope to solve this bug by porting the game from Allegro v4 to SDL v2.

In the meantime, this bug won't be fixed as it seems to be related to Allegro v4.

It is currently unknown why the game needs GTK to compile.
If possible, this dependency should go away.

I finally got Visual Studio set up where KQ compiles and runs. I've pushed these changes to dev/onlinecop/vs2022.

1. I believe I had a bug in one of my VS2019 plugins (unrelated to KQ), causing it to crash.
2. I downloaded Visual Studio Community 2022 using the Visual Studio Installer, and selected:
   • Desktop development with C++
   • Game development with Unity (probably not required for your setup)
   • Game development with C++ (may also not be required for your setup)
   • Linux and embedded development with C++ (probably not required for your setup)
3. Taking advice on #74, as well as the updates on the EngineRework wiki page, I made the following system and repo changes:
   1. I installed vcpkg to C:\Users\user\source\repos\vcpkg according to its Getting Started guide for Windows.
   2. I added @z9484's vcpkg.json file to the project:

      {
          "name": "kq",
          "version-string": "0.99",
          "dependencies": [
              "pkgconf",
              "sdl2",
              "sdl2-mixer",
              "lua",
              "libpng",
              "zlib",
              "tinyxml2"
          ]
      }

   3. I only had to modify one line in CMakeSettings.json:
      • From: "cmakeToolchain": "C:/Users/Peter/Source/Repos/vcpkg/scripts/buildsystems/vcpkg.cmake"
      • To: "cmakeToolchain": "C:/Users/user/Source/Repos/vcpkg/scripts/buildsystems/vcpkg.cmake"
   4. I removed one line in CMakeLists.txt:
      • Line 2: include(FindPkgConfig)
   5. I ran vcpkg.exe install from within the kq-fork/ root directory, which installed packages under vcpkg_installed/.
   6. Within VS2022, I opened the C:\Users\user\Source\Repos\kq-fork directory:
      1. I selected Build->Build All
      2. When the build completed, from the terminal in the kq-fork root, I ran: out/build/x64-Debug/kq-fork.exe
      3. The game runs!

I plan to modify this Issue as I create a fresh Windows user account and reinstall the various components, to ensure some undocumented steps didn't come into play here.

This issue was also created to facilitate discussions for anyone wishing to ask/answer questions specific to getting KQ to run on Windows + VS2022 (the wiki doesn't appear to have an easy way to discuss stuff).

As of the writing of this issue, current Lua version is 5.2.
Simply replacing Lua 5.1 by Lua 5.2 in the included headers isn't enough, some of the Lua functions used in KQ are different in Lua 5.2.