I didn't say that adding new people to a project never makes sense.
Adding new people to a project slows the project down at first, because the new people need to be educated. How long this takes, depends on the complexity of the project and the matter. If the pressure and the deadlines for development are ok with that, it's fine to hire new people.
So what do we know about LFS? Not so much, only Scawen knows ... but from just playing the game one can already say that the complexity of the matter (i.e. the phyics of racing and the development of a stable program for multiplayer access) to me seems quite great.
This would be an argument not to hire a new developer.
We also know that there is no pressure or deadline at all. This would be an argument to think about hiring a new developer.
Any further arguments can only be judged by Scawen. And when he says he wants to work like before, I can well understand, because it would change his daily life significantly. From independent developer to supervisor. Being forced to lead hours of discussions with the new people about why this and that has been implement this or that way and so on ... Progress on LFS would most likely stop for months!
But of course Scawen has proven that he asks other people for advice regarding the physics of racing and he also does his own research (on track). So he's not all alone ...
Have you any idea how much effort it would be to get new people to a point where they are able to understand all the LFS coding implemented so far good enough to be helpful at all?
I'm a professional software developer in a big company and I know what I'm talking about. LFS surely is such a big project that educating new people in order to be helpful to the project would cost Scawen more time altogether than just doing it by himself. Also the code quality would clearly suffer from that.
I don't like the speed of progress of LFS either, but complaining won't help. So I play nothing or something else until the next update comes. And maybe I don't even have any interest anymore in LFS when the next update comes, but that's fine for me and fine for Scawen I think. No one really cares. Life is more than just LFS.
I already used the ob_start etc. stuff in order to prevent the messages and this works (except for the pages were I forgot to use it).
But I think it's not the optimal solution. It's like a doctor giving you pills against the pain without checking the reason for it.
The main issue here is, that I never have had these problems with my two installations. So something must be different for the users which have this problem. I though a lot about it but I have no idea ...
Anyway, the file_get_contents is just in the demo page. One can also use include instead I think.
Maybe I will need your help, Dygear, since some users get the error message (header already sent ...) when I try to set COOKIEs. The strange thing is, that I cannot reproduce it. I have two different trackers on two different servers and I never had that problem.
You might have some server setup issues. When trying to load the tracker test page, I get some warnings:
Other than that I think it's the connection to the MySQL DB that takes so long. The only page that loads faster is the Tracker Test page (which does NOT check the user currently, thus has no access to the DB unless you explicitely request the tracker list).
Basically, you only need to adjust the config.php (it is well-documented, also in the PDF-document).
Make sure you use PHP 5.x as there are still some issues with PHP 4.x.
Make sure, the data directory allows writing access (chmod 777).
I'm not exactly sure what you mean with the other questions. When the single racer update sais "no data" this might be due to "no data" being found on LFS World (e.g. the racer does not exist or he has no HLs on LFSW for example).
Other than that don't forget that there is a tar-pitting for LFS World Access. That means, if you do not have PREMIUM-Access, you will only be allowed to read data from LFS World only every 5 seconds.
That changing the page is so slow might be due to a slow server or a misconfigured config.php. What are your settings?
Bone from Bavarian Racing discovered a bug related to character encoding.
When creating a new racer with a name containing UTF-8 2-Byte characters (like "ü" for example), the name on the DB was written in non-UTF-8 format (i.e. "ü" as 2-Characters, not one 2-Byte character).
The same problem occured when creating ingame tags or names containing such special characters (like ä, ö, ü, or Alt-0149: •).
The reason was a missing explicit MySQL statement that all data transfer between PHP and MySQL should be done in UTF-8.
This is now fixed, new version uploaded, see first post.
Problem seems to be solved now. It seems the tracker still does not work properly with PHP4, switching to PHP5 solved the issue.
Looking at your installation there are still some broken links to images.
This is due to an incorrect setup of config.php. There is a parameter where you have to enter the base-URL for your tracker installation. In your case that is something like http://www.lfscr.com/hottracker (maybe you have to add a '/' at the end also, take a look in the documentation please).
Without any PHP knowledge, the old Tracker is hard to customize.
I will give no support for the old Tracker anymore (unless someone pays me fort it ), so I'm sorry, but I cannot help you.
The new tracker is quite a big package, but very easy to install (if you have MySQL on your server). You can then include as many server status as you want, wherever you want. And chinese characters are also supported.
Ok, the notices are hopefully gone now (but I believe there are still some more hidden in the code ... just waiting for Okrom to reveal them ).
Concerning the password reset, Okram, you're absolutely right. I also wasn't satisfied with the current solution, but regarded it as not important enough to change it.
Now, any user can reset his password by himself. Since there is no identification check, the user has to provide the email address in order to reset the password. If he doesn't know his email anymore, he can't do anything. When resetting the password, an email will be sent.
I still allow the super user to reset the password for a user (automatic email generation still to implement at this point).
In order for the email to be a valid identifier (just as the username) it has now to be unique in the tracker user database!
Other than that:
A slight change of the control center layout (two columns of menu items now)
Super user now can leave a note in the control center (either visible to all visitors, to registered users only or to no one at all).
I still have to update the documentation as well ...
Also added a new feature for the ingame racer list maintenance: Delete all racers of a given team (it can be annoying when one has to delete mutliple racers one-by-one ... maybe this helps, maybe I will add some checkboxes in the future).
I uploaded a new ZIP (link is the same as before, see the first post).
All PHP-Notices should now be gone. Getting rid of the notices really helped me to discover plenty of bugs ... (shame on me :schwitz
I optimized the MySQL table, they will now be created with appropriate indexes. Thus, you should now manually drop existing tables in order to have them created automatically again (with the index). Sorry for the inconvinience ... I could have written an update/altering script, but I was too lazy.
Fixed a bug in the trackerupdate.php. If any parameter is specified in the call that is not known, no update will be performed.
If I have overseen any "Notices", please post this here. (Thanks at Okram for his help again, you are know mentioned in the acknowledgements).
I also would like to know if the tracker now runs under PHP4. If not, this will be the next topic I'll take care of.
I must admit I'm not a real PHP guru ... I learn quite a lot about PHP these days.
First of all, I sort of hate PHP since it allows for using variables that have not been defined before. In fact, it depends on the individual setup of the PHP environment if someone even notices that he does something which is in principle "not clean".
On the other hand, PHP doesn't support explicit programming such as declaring class variables as private, which obviously is allowed only since PHP5.
Well, now I have to deal with that unfortunately.
I never got these notices (because the two servers that I used for testing didn't show me the messages or I was just to dumb to find them).
I will try to make sure that every variable I use in the scripts is defined when it is used first. But this will take some time (at least until the weekend) and some testing.
I would appreciate your help then, Okram.
I will upload an updated ZIP for the PHP_SELF issue later on.
EDIT: Ok, I have set error_reporting to E_ALL for my private installation, which should allow me to find all notices and fix them.