Linux Air Combat

[bbosen]

I've spent almost 3 years developing "Linux Air Combat" (also known as "LAC"), a free, open-source, real-time, "out-the-cockpit view", 3d, networked, multi-player, flight sim for LINUX featuring more than 50 historic aircraft from World War II. The sofware is written in c++, based on opengl 1.2 and many of the graphic routines from the classic old "gl-117" flight game by Tom Drexl. LAC also includes a very robust (but optional) interface to the free, well-known "Mumble" VOIP application, and our little LAC community uses Mumble to organize multi-player missions. The source code is clean and unusually well organized, so it is VERY easy to compile on all of the major LINUX desktop distros. It usually compiles in less than a minute, and with absolutely no source-code changes necessary. (It does, however, require several well-known, free, industry-standard libraries in support of the opengl graphics and sound.)

Here's a screenshot:



The main web site for LAC includes download instructions, full source code, and YouTube videos showing EXACTLY how we compiled it on Linux Mint, and "Ubuntu" Linux. It's here:

http://askmisterwizard.com/FlightSimMov ... llPage.htm

And here's a YouTube video playlist with a comprehensive review:

https://www.youtube.com/playlist?list=P ... wKwgjddHqm

The 3d graphic aircraft models are in the well-known, classic ".3ds" format, and I use "Blender" to create or edit them. I'm not very good with Blender, though, so I am hoping to get some help to make them better.

I'm also looking for feedback from people willing to test and compile LAC using the tools described on the web site referenced above.

[Lyberta]

Alright, there are a few things I need to note.

The website is very hard to navigate. Usage of fixed frames makes a lot of screen space wasted and when I open a link in new tab, it opens only the frame so all navigation is gone. Also, the buttons are images but they are just rectangles with text. You can do better with just CSS. Since buttons are raster and seems to use fixed size in pixels, they are very small on HiDPI screens.

I've spent several minutes looking for a repository link or any way to download the source code. Apparently, you've decided to put the source code and binaries in the same archive. Well, yes, it's nice for us GPL lovers but me and most devs would really like just the source code. Next, tar.tar.gz? What? Why did you do that? That makes no sense. No need for double tar'ing. So I finally unpack this whole thing and I see a bunch of source code and "bin" and "obj" dirs. It looks like you've just took your dev setup and archived it. That's not usually how it's done. Also, apparently all assets are in the "bin" directory. Why? Bin is usually where the output files go in a dev setup and it is cleaned between rebuilds.

Now, you claim that building is so easy. Well, in 21st century, the easy way to build C++ code is usually:

{l Code}: {l Select All Code}

mkdir -p Build
cd Build
cmake ..
make

But you demand to install a very old and bloated Code::Blocks just to build the code. It's just not practical. I myself use CodeLite but I make sure the users of my code will never need to install any IDE just to build it. It's an explicit decision to remove the "works on my machine" problem.

Let's dive deep in the code.

{l Code}: {l Select All Code}

char name [255]; // unique name

In 2018? Really? Again, maybe that is because you *really* care about performance but it's 2018...

{l Code}: {l Select All Code}

void CModel::setName (char *name)
    {
    strcpy (this->name, name);
    }

Since name is char[20] that is a buffer overflow vulnerability and will lead you in a world of hurt. It's 2018 and we have std::string since 1998.

{l Code}: {l Select All Code}

#include <stdlib.h>

The only excuse to do that is if you inherited a very old C codebase which doesn't seem the case.

It looks like pretty much all big variables are global and every tiny detail is totally hardcoded. The only way to mod the game is to recompile the whole thing each time.

It looks like the codebase was written by someone who is very new to C++ and only using features from the 1990s. That's not how to write code in 2018. Thankfully, it's not that hard to rewrite it according to C++ core guidelines.

I know my post may sound harsh but I really just want to make the game and site better.

[bbosen]

Lyberta,

Well, I didn't interpret your reply as harsh. Thanks for your help. I'm an old "C" hack and although I can muddle through with C++, all of my experience was with "C" down at the lowest levels, many years ago. I've been trying to "dust off" my skills and I appreciate any help I get as I try to make this stuff robust.

Putting together a simple, conventional "make" file is on my short-term bucket list so that those that don't like CodeBlocks will have an easier time.....

"Time...." that's the issue for me and everybody else....

Saludos,

[asdv]

It looks really nice bbosen!
It compiles just fine on Ubuntu 16.04 if you have all the dev libs that are listed on your website installed.
I did run into some problems:
1. Changing resolution above 800x600 and setting fullscreen causes the game to crash for me. The resolution 1024x800 is not listed in the config file but can be set from the game. Going in manually in the config file and setting 1024x768 works though. Could be my computer.
2. There’s some bug that’s happened were there’s no missiles available in a mission even if it says missile pack selected on the start screen. Not sure how it happened but if you start one mission, press escape and then try to select another one the graphics for both the airplane and the missiles are gone. Not sure if related?
3. Changing the throttle doesn’t appear to work with just a keyboard and mouse, so you need a joystick? I couldn’t find anything in the keyconfig file either. It would be nice if there was a way to play without a joystick.
Otherwise it plays really well though. I like that there’s tutorials with voice over to get you started.
Are you the only dev working on it or are any of the gl-117 people still around?

[bbosen]

asdv,

I'm thrilled at your report. I just wrote you a detailed response, but it got lost in the Internet netherworld somewhere and I've run out of time just now, so I will get back to you on most of your points. However, I did discover that the secret to throttle up/down when you don't have a joystick is to use the "[" and "]" keys, respectively. I hard-coded those for friends that fly with just a mouse, and (as you observed) I had forgotten to include that in the menus or documentation. I will need to fix that (along with several other things to be described when I can get back to this board).

Thanks!

[bbosen]

asdv,

I've found a few minutes to get back to you. I want to respond to your first point right now (more to come later). You wrote:

"Changing resolution above 800x600 and setting fullscreen causes the game to crash for me. The resolution 1024x800 is not listed in the config file but can be set from the game. Going in manually in the config file and setting 1024x768 works though. Could be my computer."

I have ten different PCs in my lab that I use for development and testing, and one of them behaves a lot like yours. The resolutions listed (both in the game and in the LacConfig.txt file) are just suggestions, based on what your hardware detects and on experience from others. You can actually set any resolution you want to try from within the LacConfig.txt file. If you also designate "Full Screen" mode, then your display driver and hardware will try to stretch the resolution that you designate across your entire screen, using "best efforts" logic from deep within the bowels of opengl. Sometimes this works well, but not always. I've found that many of the settings do work, but yield funny aspect ratios and/or suboptimal frame rate. Nevertheless, with experimentation, I have always been able to find a full-screen setup that works on each specific computer. Your mileage may vary. In many cases, the best answer is just to turn off "Full Screen" mode and designate the specific resolution that you want by directly editing the two associated fields in the LacConfig.txt file. That way, you can fill as much or as little of your display area as you want. It's trivial to fill all of the useful space this way, and in my experience, you always get the correct aspect ratio this way.

I hope this helps. I'll get back to you on your other points as time permits. Thanks for your input. It's fun to get such useful feedback as I am getting from this forum.

[Lyberta]

I'm an old "C" hack and although I can muddle through with C++, all of my experience was with "C" down at the lowest levels, many years ago.

Well, the thing is, C++ has evolved and if current C++ folks would look at your code, they would probably repeat what I've said. That is, it is hard to even start to observe higher issues because the code style is way to ancient and all simple issues are just glaring. I would suggest getting a good modern C++ book such as The C++ Programming Language, Fourth edition by Bjarne Stroustroup, Yes, only the latest edition, previous ones are ancient now. Then you'll probably want to add a few sites to bookmarks:

https://isocpp.org/ - Basically the official site of C++. Has tons of news content and great FAQ to get you started.
http://en.cppreference.com/w/cpp - By far the best C++ reference in the world.

I suggest skipping classic Make straight to CMake, it's a bit hard at first so I'm gonna give you a template that can easily get you started. But it's pretty much required to watch this video: https://www.youtube.com/watch?v=eC9-iRN2b04 as it will teach you proper modern CMake.

{l Code}: {l Select All Code}

cmake_minimum_required(VERSION 3.8) # 3.8 Added official C++17 support so I strongly suggest not requiring anything older.

# Name of the project.
project(Test)

# Setting output directory. This way your executable will go into "Bin".
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_SOURCE_DIR}/Bin)

# Finding dependencies. You will need to find SDL and other thing here typically. You will need to look into documentation or search the web for exact package names.
find_package(Foo REQUIRED)

# Specifying source files of the executable.
set(SOURCE_FILES
   Src/Main.cpp)

# Adding executable.
add_executable(Test ${SOURCE_FILES})

# Specifying compile features that are required to build the executable.
target_compile_features(Test PRIVATE cxx_std_17) # You can change this to cxx_std_14 if you want your code to compile on current Debian stable but I suggest going with C++17.
target_compile_options(Test PRIVATE "-fconcepts") # Only if you want Concepts TS. You can put arbitrary defines here but try not to.
set_target_properties(Test PROPERTIES POSITION_INDEPENDENT_CODE ON) # Useful.

# Specifying libraries to link executable to.
target_link_libraries(Test PRIVATE Foo::Foo) # Use the package names and not library filenames if you can. Targets from packages use ::.
target_link_libraries(Test PRIVATE boost_locale) # Names without :: mean CMake will simply look for an .a or .so file with this name.

[bbosen]

Thanks Lyberta. I appreciate those pointers. Obviously I will need some time to catch up with the fundamentals inherent in the necessary modernization. I've pretty much finished adding "features" to the sim now, and I've set aside this year (2018) to get it robust, ready for prime-time distribution, and into repos, etc. I'll be educating myself to the best of my aging abilities along the lines you suggested (unless some really patient soul decides to join in and help me modernize the code).

[bbosen]

asdv,

You also observed that "There’s some bug that’s happened were there’s no missiles available". Yes, that's a bug and I haven't found the cause yet. You never see this bug the first time you fly a mission, but it's always present after completing at least one mission in the same session. (As it turns out, missile availability in the actual missions is unaffected, but you can't see associated little images visually in the setup menus. Actually, the entire menu system, inherited from the legacy roots of the project, is kind of a mystery to me.) As you suspected, this bug and the similar one that obscures menu display of aircraft are related. In both cases, the menus fail to display the artwork (for missiles and for aircraft) after the real-time 3d flight engine has been used to fly a mission. However, the associated menu text IS displayed, and the associated menu choices actually do affect mission setup as you would expect. It seems that the real-time, 3d rendering of aircraft and missiles during the missions is somehow confusing the subsequent, static menu image display logic. I know this makes it cosmetically disappointing to navigate the menus after completing a mission. The best workaround is just to exit and re-start the sim after each mission.

You also asked "Are you the only dev working on it....?" Yes, it's just me. I tried to contact Tom Drexl (primary author of gl-117) but I never heard back from him. I hope he's OK and blessing some other project with his prodigious talents.

[asdv]

bbosen: I think the problem with the resolution was with my computer. I forgot that my native res is 1366x768 so setting something like 1024x800 where the vertical res is greate than the native one was likely the problem.
Being the only dev could be tough since it’s a large code base, 48000 lines or so. You might be able to get some help with blender on blendswap.com where there’s a request page. If you just want some basic models or touch ups. Blender is a pretty awful program to use so I can sympatise. Though the models look good enough as it is.
Unfortunately I’m short on time myself so I can’t contribute.

[bbosen]

asdv: Thanks. It sounds like you've found a display resolution setting with which your hardware is happy. I'm glad about that.

Thanks for the kind opinion on the aircraft 3d models. "good enough" is what I was targeting.

I've been playing around with Blender quite a bit during the past couple of weeks and I've begun a new little library of replacement .3ds models that I will publish as an "optional" upgrade package so people can replace the basic, quick-rendering .3ds aircraft models with prettier ones if they have hardware of sufficient power. I haven't published any of these yet, but I will soon be prepared with vastly improved versions of Mitsubishi's A6M2 and A6M5 "Zero", of the Supermarine Spitfire Mk5 and Spitfire Mk9, of the Vought F4u Corsair, and of the HQ airfield facilities. When I'm ready to publish those improvement, I'll alert everybody through this thread. (Several generous souls provided .3ds models for this effort, and I will definitely credit them as the results get published.) Additional help is solicited

I'm also working to modernize the code and to make it less subject to abuse. There are a lot of very old code snippets that need replacing. I do not expect these changes to introduce any significant new features, though.... just cosmetics.

[GunChleoc]

The easiest way to attract other people to help is to set up a public version control system - there are free hosting sites like GitHub of GitLab etc. to help you with that.

[bbosen]

Linux Air Combat version 5.91 is now available, and it includes the various "fixes" discussed in my prior posts (above). Find it here:

http://askmisterwizard.com/FlightSimMov ... llPage.htm

or here:

https://sourceforge.net/projects/linuxaircombat/

I am still working to get this ready for conventional distribution through "repositories". Not there yet....

[Lyberta]

I am still working to get this ready for conventional distribution through "repositories". Not there yet....

FYI, stuff like "Debian repository" is much more complex than "source code repository".

[Julius]

Honestly... don't bother with Linux distribution repositories until your game is more or less feature complete and in maintenance mode. Release early and often just doesn't go very well with that model. In addition you will just get a lot of bug reports from severely outdated versions in some LTS release distribution repository.

You can make a PPA for Ubuntu (derived distributions), but this is being phased out in favor of Snaps/Flatpacks.

For now I would just release binary .tar.gz and if you feel like collecting some donations you can can also put it up on itch.io

[leilei]

There's also the factor in downstream adjusting the game to fit their available libraries or deprecating the dependencies they don't like or don't have ported, or being more of a stickler for what compiler is required. In my case the OA QVMs (which rely on EVIL NON FREE COMPILER LCC) are deleted out of pak0.pk3 (creating a checksum issue from the get-go) and native .so binaries are enforced on Debian and they separate the mature pak to another package, forcing me having to plan things differently for them in the future. Who knows if they'll like the libxmp support or libsdl1.2 usage in the future and convert mods to ogg streams/replace with terrible libmikmod or disastrously port it to SDL2 to meet a placebo of quality standards.... or even ignore my updated engine fork and rely on an unsupported upstream that wouldn't be as feature complete as I require.

There's also the issue of downstream explicitly name-dropping trademarks, so if your game were to be a clone of something deliberately avoiding trademarks to keep it safe, downstream wouldn't be as courteous about it. *cough*ksirk*cough*

[bbosen]

Wow. So much to learn and so many issues. Although I've been programming for a long, LONG time, I'm totally "old school" and all of this information is very helpful to me. Thanks for trying to teach this "old dog" the various issues. For now, my 'Linux Air Combat" is not yet completely "feature complete", so I am approaching this distribution thing very gradually....

--Thanks!

[Lyberta]

Wow. So much to learn and so many issues. Although I've been programming for a long, LONG time, I'm totally "old school" and all of this information is very helpful to me. Thanks for trying to teach this "old dog" the various issues. For now, my 'Linux Air Combat" is not yet completely "feature complete", so I am approaching this distribution thing very gradually....

--Thanks!

Just focus on putting your code in git repo first.

[bbosen]

Update 02Jan2021:

Linux Air Combat ("LAC") development has continued, and the current version is now V8.41. The code is a lot cleaner and more stable now, but the low-level "speed at any price" code style is retained. (It runs nicely even on Raspberry Pi hardware on the Raspbian version of Linux.)

Here is a page with links to YouTube playlists showing exactly how we compile it on Debian Linux, Linux Mint, Ubuntu Linux, Raspbian Linux, PcLinuxOs, etc.:

http://askmisterwizard.com/2019/LinuxAirCombat/LAC%20Software%20Technology.htm

Some of those clips are rather old now. The newer clips rely on the simplest new Makefile.

Hardware compatibility is increased. For example, in addition to flight controls based on joysticks intended for flight sims, it is now fairly easy to control flight with just a mouse and keyboard or with a USB-connected, console-style "Game Controller".





Comprehensive documentation is available online here:

http://askmisterwizard.com/2019/LinuxAirCombat/LacOnlineDocs.htm

Version 8.41 stores the executable at /usr/bin/lac, with all additional shared resources at /usr/share/lac. User-specific configuration and log files are created as needed at run-time in the user's ~home directory, in a new, hidden folder named ".LAC". The source code is available for download here:

https://sourceforge.net/projects/linuxaircombat/files/

[bbosen]

Update 21Feb2021

It seems that Joystick manufacturers all stopped making economical joysticks during the Pandemic of 2020. As a consequence, if you can even find a joystick for sale, it's going to be terribly expensive. Linux Air Combat likes joysticks, though, so I enhanced the code for better support of readily available, low-cost USB "Console Game Controllers". Here's a picture showing how I can map them for use with LAC:



All of this is explained here:

https://sourceforge.net/p/linuxaircomba ... 0d2cb6e51/