Currently, CU shows the time per page for creation, but doesn't show the total time. It should be presented in the final page of creation.

ship.php should have a better error message for handling when you navigate to it directly (instead of from main, when a ship has been detected)

From https://stackoverflow.com/questions/5081025/php-session-fixation-hijacking#5081453 :

"Include the user agent from $_SERVER['HTTP_USER_AGENT'] in the session. Basically, when the session starts, store it in something like $_SESSION['user_agent']. Then, on each subsequent request check that it matches."

Non-trivial, but useful. Lets try to get this added.

• KB-0005: Trade routes, create a new port<->port trade route does not work.

I propose we format the contents of /docs to use markdown. This would allow the documents to be structured better and would have the added benefit of github and various other services formatting them automatically.

Also, changing the file extensions to .md wont break plaintext readers so there's no real negative impact with this change.

I'm happy to change these for you too!

Each should be tracked in our main tracking system.

I'm looking to contribute some change to the repo but in order to avoid stepping on each other I think it might be worth using git flow, or some other documented methodology.

In short, the following changes would have to be made

• Add a new develop branch, this will act as the main branch and the one shown when the project is loaded on github.
• All new work would be done on feature/{feature-name} branches, branched from develop.
• All new work would be merged into develop (or via a pull request for contributors).
• New releases (major build milestones, official public releases) are merged into master and tagged appropriately using semver.

This kind of methodology is used a lot in the wild, and personally it has improved my workflow hugely when working on large scale projects and open source projects where reliability is desired.

I'd be happy to explain it in further detail, and help you set it up if required. I use it daily at work and it's been very helpful to our team; I think you'll like it.

composer/composer#5440

These two files can and should be combined.

To improve security, implement PRG pattern for the post calls in the game.

Fetching the results as PDO::FETCH_BOTH (the default) takes twice as much memory, since PHP provides access to different column values both through an associative array and a normal array.

http://php.net/manual/en/pdostatement.fetch.php

• KB-0002: The new player signup needs to have an activation step before you can play.

• KB-0006: Admin, user editor, forces a password change even if you do not enter one, and the changed password isn't accessible (encrypted).

Any variables being passed to SQL via PDO must use named parameter binding.

Add Facebook login as an option

Add logging to 100% of SQL calls.

Scheduler is a bit of a mess. Rewrite it to be a subdirectory (like admin) with activated scheduler events. Cleanup functions as well.

Rewrite so that it is class driven, and matches our current coding standards.

Convert all SQL calls in the game to be able to run on PGSQL.

Convert all SQL calls from adodb to PDO:

• Convert them to use proper PDO techniques
• Review the SQL itself to ensure it is reasonable, and uses named bind parameters
• Make sure all commits pass phpcs/phpmd/sensio/scrutinizer, and test to ensure they still work where possible

Upon opening setup_info.php for the first time. The cookie test fails. And the link in the failure message (https://kabal-invasion.com/forums/) is no longer valid. After a page refresh the test passes. Perhaps the failure message should be updated to suggest refreshing, and change the forums link to github?

Notice: Undefined index: TestCookie in /var/www/html/tki/setup_info.php on line 101

Cookie Test Failed! - Cookies cannot be set. Please report this issue to The TKI Forums

Only traderoute.php does not have strict typing tested & enforced yet.

There are still a few remaining places where the equivalent of global variables are being inserted. Eliminate them with maximum prejudice. :)

While we are switching to SSL being required throughout the game, we need to add encryption on submission of password to all secure locations in the game.

Simplify the template system to focus on Smarty.

Add new variable for admin to set that provides https independent source for images/css/js/etc. Basically supporting a CDN. Variable can be handled much like template is.

die() being used is triggering errors (of level "Major") on SensioLabs, and I agree. We should work to recode files that use die() to avoid its use.

There are roughly 112 instances of die(), across 33 files.

Move all English text out of the scheduler and into the language file.

Files with die() remaining in classes:

Game.php, Ibank.php, PlanetCombat.php, Player.php, Ship.php, TraderouteBuild.php, TraderouteDie.php

This variable needs to be replaced throughout the game with CSS entries instead.

So to start the config setup and the language setup have bothered me forever. Just throwing this out there. These are two things that have bothered me since I first started working on this code base back in 2007 (well not this one, but a version of the BNT code base) and I think they are two issues that should be considered being addressed early on, since they do require touching every file, template, etc. and since we are going to be doing this anyways with the code updates, why not do it now as we go :)

First configuration files.

Currently there are a bunch of configuration files. We have a config (secure and classic, or from the previous version classic and advanced), a DB file, language file, settings file, global defines file, smarty and I'm sure there is stuff in a few more areas.

We then have some of these values loaded into the DB (specifically game settings) which I'm really not sure why because from what I recall most of these values are not manageable from the admin pages (I could be wrong) and I'm guessing some performance hit depending on if the 160+ records are cached.

My suggestion is we switch to the tried and true multi-dimensional array design. It's easy to work with, can be cached with most caching systems, easy to read / edit and is pretty common place. We combine all the settings, configurations, etc. into this file, drop the database config table (gameconfig) and have one common area for managing game/site settings.

You can read more about it here or google for more ideas.

Here is an example

<?php
return array(
    'phpSettings' => array(
        'display_startup_errors' => 1,
        'display_errors'         => 1,
        'error_reporting'        => (E_ALL | E_STRICT)
    ),
    'resources'   => array(
        'frontController' => array(
            'baseUrl'         => '/some/dev/path',
            'throwExceptions' => true
        ),
        'db' => array(
            'params'  => array(
                'host'     => 'localhost',
                'username' => 'foo',
                'password' => 'bar',
                'dbname'   => 'baz'
            )
        )
    )
);

I'm not saying this is the best solution, so if there is better lets do that! For example there is the concept of using a Settings class, but this is really only beneficial to development (IDE autocomplete) and overall worse then the above option.

Second off, languages.

Currently the language support is English, Spanish and French. They were outdated in 2007, and as we move forward they will become more outdated. These days browsers have built in support for language translations, or there are browser plugins/addons, etc. So why bother?

With the current setup we have 1,608 records of words / phrases stored in the database, so that means we have the 3 files to mange as well. It also means any new text we add requires the localization research, adding to the language files, adding to the DB insert file, adding to the DB, and even then chances are we might not even be right with the different languages. It also makes any type of development where text is returned/displayed a pain since each word needs to be looked up.

My suggestion is that we move away from it. Drop multi-language support, get rid of the database, the language files and go 100% English. If we want to support additional languages we do it at the TEMPLATE level which will be much easier to maintain and support. It will also increase performance, development time and get ride of a large outdated maintenance nightmare. Google has great translation support already, and I'm very comfortable with saying we will not do it better then Google.

I know this is going to be a ton of work, and wont happen over night, but is this a direction we would want to go?

Beacons currently can be deployed, but are not attackable, are not clickable, and offer no real in-game value to players other than leaving a note for others (that cannot be edited by others).

Suggest that beacons be able to be clicked, attacked, and should track players that transit through a sector. This will also likely require a substantial increase in their price, and a change in their usage.

There remain some code paths that do not expect that Sol is in Sector 1. Find, and fix.

Scrutinizer has two classes of filtered issues for the code base right now that could be resolved with a filtering class for server and session calls:

??? uses the super-global variable $_SERVER which is generally not recommended.
??? uses the super-global variable $_SESSION which is generally not recommended.

Server currently uses script_name, http_host, remote_addr, http_accept_encoding .

Session currently uses username, password, logged_in, in_combat, planet_selected, ship_selected, port_shopping .

• KB-0003: Creating a new team fails.

Scheduler should have a check to ensure that each player does not have more presets (total/count) than max_presets

Currently, attempting to login via http (not https) results in the login not working, but with no specific feedback to the user that it is due to accessing via http and not https.

While working on the original scheduler, I stumbled across a potential better solution.

I will be adding a new scheduler ("newscheduler.php"), that will be able to be run via command-line, ala:

php newscheduler.php

Which can also replace the scheduler in cron, simplifying the cronjob substantially (no more lynx/wget/etc path issues).

It will have its permissions set to prevent access from the web, and will prevent running from a web page.

Hey,

I can't find where to test this out. I'm potentially interested in contributing but I'd rather have a play before I get stuck into any code.

Thanks in advance 😄

Warning: session_write_close(): Session callback expects true/false return value in Unknown on line 0

Warning: session_write_close(): Failed to write session data using user defined save handler. (session.save_path: /var/lib/php/sessions) in Unknown on line 0

This in current dev environment:

$ php -v
PHP 7.1.3-3+deb.sury.org~xenial+1 (cli) (built: Mar 25 2017 14:00:03) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.1.0, Copyright (c) 1998-2017 Zend Technologies
    with Zend OPcache v7.1.3-3+deb.sury.org~xenial+1, Copyright (c) 1999-2017, by Zend Technologies

$ cat /etc/lsb-release 
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=16.04
DISTRIB_CODENAME=xenial
DISTRIB_DESCRIPTION="Ubuntu 16.04.2 LTS"

Cause unknown, obviously related to sessions.

• KB-0001: When resetting a password successfully, it sends a second email (it shouldn't) with a broken [link] replacement.

• KB-0002: The new player signup needs to have an activation step before you can play.

More indexes, reduce unstructured data, normalize, etc.

Extend PDO to properly include a prefix property. Right now, we apply the property despite it not being included in PDO. Extending the PDO class with a class like:

https://gist.github.com/gfabrizi/7282782
or
http://stackoverflow.com/questions/5175357/extending-pdo-class

Would eliminate a class of bugs identified by Scrutinizer that are currently filtered.

I am working on the register / login pages and re-writing the code for registration and authentication of players. I checked a few of the updated classes and didn't see PDO constants in use. I have normally used them in the past and wanted to find out if we (I) should or shouldn't use them? If not then no big deal, I just want to keep my code consistent with the code base as it is being updated.

More details

Here is an example

$sql = "SELECT email, character_name, ship_name FROM ::prefix::ships WHERE (`email` = :email) OR (`character_name` = :characterName) OR (`ship_name` = :shipName)";

        $stmt = $pdo_db->prepare($sql);
        $stmt->bindParam(':email', $email, PDO::PARAM_STR);
        $stmt->bindParam(':characterName', $characterName, PDO::PARAM_STR);
        $stmt->bindParam(':shipName', $shipName, PDO::PARAM_STR);

        $stmt->execute();
        $count = $stmt->rowCount();

So instead of

        $stmt->bindParam(':email', $email);

it would be

        $stmt->bindParam(':email', $email, PDO::PARAM_STR);`

Smarty path Test Failed! - Smarty is not installed in the correct location - please install it at vendor/smarty/smarty/

The path searched for is "vendor/smarty/smarty/distribution/libs/Smarty.class.php"
The correct path is "vendor/smarty/smarty/libs/Smarty.class.php"

Hey there. Sorry if this isn't the best way to get in touch with people involved in the project. I've used git/svn for years but always stayed away from Github.

So I worked on the BNT code base years ago, and spent several months working with it. I picked up the project again after years of being idle and saw that you have started all the much needed updates to the code base.

I wanted to find out what your plans are with this project so I can know if its best to just fork it, or commit directly to the project.

Are you planning on just updating the code base to modern standards and continue having the game be as is (matching the mechanics of TW2002) or are you looking to enhance the game and adding new functionality and features?

My plans were to continue on the overhaul of the codebase, adding a new theme (bootstrap based) and then either beginning new features and game play, or maybe doing a migration to a PHP based framework, specifically I was thinking CodeIgniter.

If our long term interests don't mash up then I can always fork, but if there is fun stuff to work together on I'd prefer to not deal with forking/pulling until it was needed.

I wanted to find out if there is any consideration for any specific JavaScript libraries or frameworks? Currently there is very little JS used within the project (news ticker and round ticker) which isn't a bad thing but it does limit which options are available especially later on if/when the project moves to a modern PHP framework like Symfony2 as has been discussed.

For example I am currently working on the registration page(s) (new.php, new2.php). I would like to use an AJAX form submission and validation as well as DOM manipulation for errors (password to short, name in use, etc.) and move away from the multi-page validation, error display system currently in use. Now I can do it with straight JS but requires very page specific code, less functionality and overall re-creating the wheel, while using JQuery or other library will give us overall tried and true functionality that can be re-used though the rest of the site. This is something that also couldn't be template specific either since we would still need to all templates to confirm to specific functionality (cannot use AJAX, use multi-page submissions, etc.).

This is something that we could only be included in specific pages but with something like a JavaScript library it would seem best to include it though the entire site instead of just a few pages, or worse, using multiple libraries though the site which seems like a bad idea.

I'm also not suggesting the only option is JQuery. Personally I would be happy with pretty much anything as long as we can get some modern capabilities you know? I'm just suggesting JQuery since its popular, common, easy to use and pretty much everyone will have libraries already cached in their browsers so performance shouldn't be an issue.

PHP allows us to check if the needed extensions are loaded:

http://php.net/manual/en/function.extension-loaded.php

Checking for pdo, mbstring, and a DB extension would be ideal, with well-formatted errors to let the admin know.

I've set up the repository locally (cloning the latest commit 288014b). Following the setup instructions found in docs/install I'm stuck on step 4.

I've added the the database config in /config/SecureConfig.php and have managed to get the program to connect to the DB. Beyond this step the program is trying to require_once /config/db_config.php in /setup_info.php:21 which doesn't exist.

Am I supposed to manually create db_config.php or is this a bug? It would seem that the db config is all in /config/SecureConfig.php already?!

Thanks in advance.