AdsQL: Troubleshooting, FAQ, and Web Banner Customization
General Questions
Question: Will you support me if I modify the ads database, plugin source code, or web interface code and run into problems?
Answer: No. If there is a change you would like to see that makes sense, I am willing to consider it for a future release if you are willing to share it. I will of course give all credit where it is due.
Question: If I use a different web interface to create or edit my ads, or edit them directly in the database with phpMyAdmin or some other tool, and run into problems with things working properly, will you help me get things working?
Answer: No. I support what I provide.
If you aren't using what I provide, then make sure you understand the source code of the plugin, web interface, and related SQL well enough
on your own that you don't need to ask for help when you get into trouble.
Needing to ask for help should be a "big red flag" that you shouldn't be trying to do things your own way. In which case, the help I will offer is this advice: "Start over from scratch, using the tools and instructions *I* have provided".
Ads Display Problems
Question: Ads aren't displaying AT ALL! What should I do?
1. Go back and look at your server logs and server console output when you start(ed) the server.
2. Look for messages telling you whether AdsQL successfully connected to the database or not. If AdsQL can't connect to the database, refer to the original install instructions on page 1 and the Database issues section below.
3. At map start, you *should* see the plugin log a message either with a server ID that it will use when searching for ads, or that no server ID is defined. If there are server ID problems, refer to the original install instructions on page 1 and additional details below.
4. Assuming you have any ads in your database that this server should run, approximately 10 seconds after map start, or within 2 seconds of an ads "reload", you should see a list of ads the plugin found for this server listed to the server console. Any ad listed to the console will be displayed on this server in the order listed and according to the adsql_interval value
(the only exception to this always being true gets its own special Q&A below):
- If you don't get any listed, but you do have a connection to the database, then the plugin can't find any ads for this server.
- Verify the server ID this server is using (you can type "adsql_serverid" in the server console to see its current value), then with the web interface, look at your ads and make sure you the ads you think should be running on this server have the right game type(s) and server ID set.
- In the
Game Type listbox, make sure that
All Games is not selected together with any other specific game(s). You either use "All Games" by itself
OR you select one or more specific games.
- For Server ID, the text box must either say "All" (with nothing else in the box), or list the Server ID('s) the ad should run for, with commas separating multiple server ID values (and no spaces). If the ad has server ID's set, obviously, make sure the server ID this server is using is listed in the box. Refer to the install instuctions on page 1 of this post or the Troubleshoting Server ID Issues section below.
Troubleshooting Server ID Issues
Question: I'm not seeing all the right ads I should be seeing on this server! What's wrong?
The plugin on any particular server will *ONLY* load ads that meet one of the following conditions:
1) The Game Types field is set to All Games (in this case it doesn't matter what is in the ad's Server ID field)
2) The Game Types field has this server's game type set and the ad's Server ID field is set to All (with NOTHING ELSE in the Server ID field)
3) The Games Types field has this server's game type set, and this server's Server ID string is found in the ad's Server ID field.
If you're not seeing the ads you think you should be seeing, look at what the plugin says it is using for a server ID. As the instructions in the first post state, the plugin will log a message indicating the server ID it will use to search for ads if one is defined -- every time it gets ready to search for ads. You can also check the value of the adsql_serverid CVAR.
General Tips
1) Read the installation instructions and this FAQ post carefully. I really can't explain this stuff any better than I have already.
2) If you are an existing AdsQL user since before version 1.7.7, make sure you have done the Version 1.7.7 Web Interface USER TO-DO item about "editing"/saving each ad after updating your web interface - this is described in the 1.7.7 Changelog and the "How To Upgrade My Web Interface" section of the FAQ Post.
3) MAKE SURE you set good Server ID's that don't cause substring match problems. See the install instructions on Page 1, and the "WTF Is a Substring Match, Exactly?" section below.
4) MAKE SURE you have not set All Games together with one or more specific games in the ad's Game Types field. If you do, the ad will probably show in the specific games you set (depending on what you have in the Server ID field) - but it will NOT show in any other games (the All Games will be ignored).
5) MAKE SURE you do not have "All" set in the ad's Server ID field along with actual Server ID strings for one or more servers. If you do, the ad will probably show on the server(s) whose Server ID is set in the Server ID's field (depending on what the ad's Game Types is set to), but it will NOT show on any other servers because the Server ID field has to EQUAL "All" for the ad to show on all servers -- not just contain "All". Kapeesh?
6) Make sure you are defining the server ID for the plugin in only one place. If, for example, you define it in serverid.txt and ALSO have it defined via adsql_serverid CVAR in, say, the global server.cfg and they are two different values, well guess what.. the "last definition" wins. As stated in the Install instructions in the first post and elsehwere in this FAQ, I only support defining the Server ID in serverid.txt at this time.
The log messages the plugin emits (even without adsql_debug set on) can also be helpful.
Plugin Warnings About Undefined Server ID
There are two different log messages purposely set up in the plugin to warn you if the serverid is undefined:
1. If no serverid.txt file is found at plugin startup (because one hasn't been created, or it was created in the wrong place), you'll see a log message like this:
Code:
L 02/16/2011 - 06:51:26: [adsql.smx] [AdsQL] - configs/adsql/serverid.txt not read - file not found.
2. When the plugin is about to fetch ads from the database, it checks if the server id is undefined (because if it is, using it in a LIKE query causes problems...). If it is undefined, you will see a log message like this:
Code:
L 02/14/2011 - 14:31:32: [adsql.smx] [AdsQL]: adsql_serverid is undefined
Question:
Quote:
|
Could I use the server port as ID? Or would 27025 be seen as a substring of 27015?
|
Answer
That would be fine, it's actually the main server ID scheme I'm using on most servers I have run special ads. As long as you don't have more than one IP in use that runs gameservers on the same port number (and you want those servers to have separate special ads). If that is the case you will have to get a little more creative with the Server ID strings you choose to use.
As far as 27015 vs. 27025, neither are substring matches of the other.
Question: WTF is a substring match, exactly?
When you choose and set the Server ID's for your gameservers, you have to consider EVERY OTHER server ID in your set of servers when you are trying to figure out if the server ID you want to assign to any one of them would be a problem. Can the entire server ID string you want to use for this server be found as a PART of any other server's Server ID? if the answer is yes, then you need to come up with better server ID values.
A substring match means, given two strings to consider, that the entire string of one can be found as a PART of the other.
For example, let's say you have string1 as "27025", and string2 is "27015". And you want to know if either is a substring match of the other. So you look at both.
Since "27025" (the entire value of string1) cannot be found inside string2 ("27015"), it would not be a substring match. And vice-versa. Therefore if you only had 2 servers, and these were the server ID's you wanted to set on them, these would be fine to use as the server ID's.
On the other hand, if string2 was "2701527025", well, that WOULD yield a substring match, because string1 is 27025 in our example. Even though string2 isn't "equal" to 27025, we can find FIND 27025 as a substring in string2. So "27025" and "2701527025" would be a bad pair of server ID's to use.
This is why in the installation notes I said that css001 and css013 would be a better choice for two server ID's than css1 and css13. Get it? css1 is a substring match for css13. So when the server running with server ID "css1" went to search/load ads it should run, it would also load and display any ads you had defined to run on a server with server ID "css13". Imagine the fun if you were using server ID's css1, css10, css11, css12, and css13. The server running with ID css1 would display any server ID-defined ads for ANY of them.
Why? Because the SQL queries to search for ads use "LIKE" queries (substring searches) for server ID's. Making the plugin "work harder" to do more than that is inefficient and unnecessary if the plugin users will just think a little about the server ID's they assign to their servers.
Question: Do I *HAVE* to define the Server ID in (sourcemod base)/configs/adsql/serverid.txt? Why can't I just set the cvar in a .cfg file?
My official position is this: The known-to-always-work, supported method of defining your server ID is to set it in serverid.txt.
If you choose NOT to define your server ID in serverid.txt and try to only define it by cvar in a .cfg file instead, and you have problems getting the ads to load based on that server ID, your post may get ignored.
This is my answer: define it in serverid.txt.
Having said that, I have had SOME success defining the server ID only by setting adsql_serverid in a server's global server config file (server.cfg, or whatever it is (re)defined as with the
servercfgfile CVAR). Based on my testing or reports from others, the following games either DO or DO NOT register the adsql_serverid CVAR quickly enough on a fresh server start to load the ads based on that server ID, even on the first map:
GAMES DEFINING adsql_serverid IN THE GLOBAL SERVER CONFIG FILE
WORKS WITH
Team Fortress 2
Counterstrike Source
GAMES DEFINING adsql_serverid IN THE GLOBAL SERVER CONFIG FILE
DOES NOT WORK WITH
Left 4 Dead 1 & 2
In L4D1 and L4D2, if I moved the adsql_serverid cvar definition to cfg/sourcemod.cfg, it did pick it up even on the first map after a boot. So in theory, in the case of L4D series, it should also be possible to define it in an AutoExecConfig-specified plugin config file. But that STILL gets messy if you are trying to run more than one server instance out of a single dedicated server directory tree.
This is precisely why I coded the plugin to use a serverid.txt file that is located under the sourcemod base directory. People who are running multiple gameservers off a single tree are supposed to have separate sourcemod dirs (sourcemod1, sourcemod2, etc.) under (game)/addons/, and since sourcemod already knows where its base is if you have this set up and working correctly, it is the natural place to put a config file that should only apply to that instance of the game.
Question: Will you add support to AdsQL for server ID's that have spaces in them?
No. Using spaces in an ID string isn't necessary, and if I were to try to code for it, it could be a LOT of work when you consider that I might have to try to properly guess why someone typed a space into the Server ID's field during form submission. Were they only separating 2 server ID's with ", " or were they specifying a server ID with a space in it? How could I know for sure? Just one example.
I do this for free on my spare time... Please, just keep it simple and use alphanumeric characters in your server ID strings. That really isn't much of a limiting factor if you think about it.
Question: What does it mean when the ads being displayed in the game have (or ARE) a bunch of garbage characters in them like "???????"
Unless your ads database is corrupted (and it probably isn't if the plugin can find ads), it means the character set used in your advertisements text is not compatible with UTF8. This can occur with some special languages requiring multi-byte character set support, and possibly others. If you can provide details of the language in use and of your database configuration, it may be possible to add support for your language to the AdsQL system.
Question: Ads are found in the database by the plugin, and listed to the console after a map start or "reload", but they STILL never display in the game, even though the plugin shows a message "Firing Ad #/#" along with the ad text and a timestamp to the server console when adsql_debug is enabled. What is the problem?
This is an
"EEOC" error. EEOC errors are obscure, and tend to be very difficult or impossible to solve. Even finding out what EEOC means can take hours to research and the answer tends to be inconclusive. This is further complicated by the fact that not everyone in the field of support even uses the same terminology. But when an EEOC error exists, it is possible to spend many hours trying to find and fix all the problems it has caused and fix them. Unfortunately, more problems often arise later -- even after the original problems were thought to be solved -- because the underlying EEOC condition hasn't been addressed.
In this situation, the best hope to solve the EEOC condition is to just delete the ads database and start over, using *ONLY* the instructions, database setup, plugin, and web interface as they have been provided and intended to be used. And making sure to never use anything except the AdsQL web interface to create or edit ads.
Database Issues
Question: OMG! I'm getting database errors in the plugin! What do these error messages in my server console mean?
Code:
[AdsQL] - Unable to connect to database
L 03/06/2011 - 07:27:10: [SM] Native "SQL_TQuery" reported: Invalid database Handle 0 (error: 4)
L 03/06/2011 - 07:27:10: [SM] Displaying call stack trace for plugin "adsql.smx":
L 03/06/2011 - 07:27:10: [SM] [0] Line 444, adsql.sp::SetupAds()
It either means something in the database configuration section you added to (sourcemod base dir)/configs/databases.cfg for AdsQL is incorrect, or your database server cannot be found (wrong hostname, offline, etc.). Either way, AdsQL cannot connect to the MySQL database using the information you defined in databases.cfg.
Although my installation instructions are very clear, I will provide a couple of additional tips/comments:
1. If you named the section you added to databases.cfg for AdsQL anything else besides "admintools", AdsQL will fail. I would have liked to have the plugin look for a databases.cfg section named "adsql" instead, but I wanted to make it easy for people using the old broken mysql ads plugin to switch to AdsQL.
2. Make sure the database username you defined has permissions on the database, and that the password is correct.
3. Make sure this user is authorized to use the database
from the gameserver host. This is a common "gotcha" when the MySQL server is on a different host than the gameserver. Refer to your MySQL/phpMyAdmin docs for information on how to define which non-local hosts a user can access the DB from.
4. Make sure the right database is defined in the "admintools" section.
5. If you have specified a hostname with the "host" parameter rather than a numeric IP address, make sure that hostname is correct, and that it can actually be resolved on your gameserver host to the
correct IP address for your mysql server via DNS, hosts file entry, etc. on the gameserver host.
6. Make sure you have preserved the general syntax of the databases.cfg file, as far as double-quotes, proper open/close of all sections with curly braces, etc.
7. Read my databases.cfg instructions in Post 1 again.
Linux Server Sourcemod/AdsQL Errors: Can't connect to database (can't find /tmp/mysql.sock)
For folks that are getting errors on their Linux gameserver consoles or in the sourcemod log files about Sourcemod or a plugin like AdsQL not being able to connect to your MySQL database because it couldn't find
/tmp/mysql.sock, this is how you fix it.
In Linux, when you are adding/editing a section in your databases.cfg file to use a MySQL server, and you set localhost as the db server hostname and do not specify a port, Sourcemod is going to try to use the
socket your MySQL daemon creates to talk to the server rather than a TCP port. The performance is usually better on a local socket without the overhead of TCP segmentation, headers, checksums, etc. So it's really not a bad idea to use the local socket if the MySQL server is on localhost.
The MySQL daemon creates a socket named
mysql.sock and will locate it somewhere on your filesystem. Exactly where will depend on your Linux distribution or the configuration/compile-time settings of the MySQL daemon. Sourcemod expects
mysql.sock to be in
/tmp. When this is not where the MySQL daemon you are running on your system actually puts it, you will get error messages and the plugin won't be able to connect to your database.
Red Hat/Fedora distros and probably all ripoffs thereof use
/var/lib/mysql/mysql.sock instead. If your DB server *IS* the game server host and you want to use the socket rather than a port, you will need to find out where the MySQL daemon's mysql.sock file is. If all else fails, you should be able to type this command to find it:
Code:
$ find / -name mysql.sock
Once you know where your mysql.sock is, you can create a symbolic link to it and then Sourcemod will be able to find your database server when it tries to use /tmp/mysql.sock. A command like this (as root) -- using the Fedora/RH case as the example -- will create the symlink (you will substitute your correct full path to mysql.sock once you know where it is):
Code:
# ln -s /var/lib/mysql/mysql.sock /tmp/
Also note that many distros do periodically run a "cleanup" on the /tmp directory to remove stale files, and your symlink may get deleted as a result. I have the following cron job in my /etc/crontab to make sure the gameserver host never goes longer than 5 minutes without the /tmp/mysql.sock symlink:
Code:
*/5 * * * * root if [ ! -h /tmp/mysql.sock ] ; then ln -s /var/lib/mysql/mysql.sock /tmp/ >/dev/null 2>&1 ; fi
Also, if the MySQL server is NOT the same machine as the gameserver, you need to specify a port in the port section of the databases.cfg entry you are editing instead. The default port for MySQL is 3306.
Web Interface Topics
Question: How do I know which version of the Web Interface I am currently running?
Answer: Look at the "about" page - the version at the very top of the "history" section under the AdsQL Advertisements Manager heading (or whatever else you might see under the banner logo) is the version of the web interface.
How Do I Upgrade My AdsQL Web Interface To The Latest Version If I'm Already Running AdsQL?
EVERY Web Interface upgrade procedure needs to start HERE
Initial Upgrade Instructions
1. Make a backup of the existing adsql folder structure on your web host!!!
2. Download the latest release distribution .zip from Post 1, and unpack it somewhere locally.
Now let's start with the
Special Version Upgrade Situation cases. Skip any that don't apply to the version you are upgrading FROM. For example, if you are on version 1.7.0 of the web interface, you will need to 1.7.7's special instructions *AND* 1.7.5's. If you are on 1.7.5 currently, you need to do 1.7.7's special instructions.
Upgrading From Any Release Before 1.7.7
1. adsql/include/config.php has been changed in release 1.7.7. To update the AdSQL Web Interface on your web host to 1.7.7 you will either need to:
- Edit the updated config.php.default from the .zip archive to have the same database/community/email settings as the live config.php in your web host's adsql/include/ directory, and then save it in the same unpacked
web/adsql/include folder as
config.php so it gets uploaded to the web host along with the rest of the updated web interface
- OR -
- Edit the existing "live"
adsql/include/config.php file on your web host (after you backed in up in Step 1 above....?) as follows:
Edit A: Find at the top of the file:
Insert the following 2 lines directly below the line shown above:
Code:
/* new line below starting in AdsQL 1.7.7: */
if (!defined("HAVE_ADSQL_CONFIG")) {
So that the first few lines of the file read like: (excepting your config info for DB_SERVER host):
Code:
<?php
/* new line below starting in AdsQL 1.7.7: */
if (!defined("HAVE_ADSQL_CONFIG")) {
define("DB_SERVER", "localhost");
Edit B: Find at the bottom of the file the line that defines the value of "ADMIN" such as:
Code:
define("ADMIN", "Admins");
Insert the following 2 lines directly below the line shown above:
Code:
/* new line below starting in AdsQL 1.7.7 */
define("HAVE_ADSQL_CONFIG", true); }
So that the last few lines of the file read like: (excepting you may have set a different value than "Admins", that's fine..)
Code:
// What are your Admins called?
define("ADMIN", "Admins");
/* new line below starting in AdsQL 1.7.7 */
define("HAVE_ADSQL_CONFIG", true); }
?>
then save and close the file.
2. If you were running a web interface prior to version 1.7.5, follow the "
Upgrading From Any Release Before 1.7.5" section below as well, then do step 3 AFTER doing the 1.7.5 instructions.
3. (After doing 1.7.5 steps) USER TO-DO:
Due to the possibility that extra whitespace at the end of the Server ID field (and maybe even the Game Types field) in ad database records could cause problems selecting ads based on the server ID values (and possibly even game types), it is strongly recommended that *ALL* existing users of AdsQL use the updated (1.7.7) web interface to edit EACH EXISTING AD. You do not have to actually change anything in the ads -- simply click the Edit (pencil) icon for the ad, then click the Change Advertisement submit button in the bottom right of the ad editor page. This will cause the PHP trim() function fixes in the 1.7.7 WebUI to strip off the extra whitespace from the game types and server ID fields, thus "fixing" these fields to only contain needed data without whitespace, etc. that could affect plugin SELECT's finding the desired ads.
Upgrading From Any Release Before 1.7.5
1. Critical HTML compliance changes were made to
adsql/style.css in the 1.7.5 release. If you are using your own custom top banner logos and changed the background "fill" color for logo03.jpg (as described in the Top Logo Customization section below), you will need to your backup of your existing style.css file to review the "hex RGB" value you set to match your banner image, but otherwise you will need to replace the "live" adsql/style.css file with the updated one, and then go back and edit the updated one to get your customized background "fill" color set in the new one. If you did NOT set up custom logos yet, do only steps 1B and 1D below instead (you still have to replace the style.css on your web host). Make sense? Good.
Step 1A: open your backup copy of your existing style.css file and find the
background-color:#xxxxxx; line inside the
td.imgbg style definition (the 6 x's be 6 various "hex" digits in yours). Write down these 6 digits or whatever else you want to do so you can see/use the same value in step 1C below.
Step 1B: In the unpacked distribution .zip of the latest release, browse to the web/adsql/ folder and open up the file
style.css.default with a text editor.
Step 1C: Find the background-color statement you customized in the td.imgbg style definition, and change the 6 0's to whatever your 6-digit "hex RGB" value is that you found in Step A.
Step 1D: Save the style.css.default file in the same unpacked web/adsql/ folder as filename
style.css.
2. Proceed with the rest of the "General Web Interface Upgrade" steps below.
General Web Interface Upgrade Instructions
Pick up HERE *AFTER* following Initial steps above and any special Version Upgrade situations that also apply to the version you are upgrading from ABOVE
You should have already backed up the "live" adsql/ folder on your web host and unpacked the latest distribution .zip file somewhere locally in previous steps. Whether you needed to do any of the "special steps" for 1.7.7 or 1.7.5 releases or not before you got here, we are now ready to upload the updated web interface files to your web host.
1. Upload the
entire contents of the unpacked adsql folder structure from the latest distribution .zip file onto your web host, right on top of the existing adsql directory. You have a backup (right...?) so don't worry.
2. Don't worry about your custom logos - starting with release 1.7.7 the distribution .zip file has the sample ones outside of the actual adsql/ folder structure, so your custom ones already on the web host will not be touched.
3. Don't worry about your live include/config.php file - your existing one on the web host will be preserved because as of v1.7.5 the distribution .zip no longer comes with an include/config.php file that could overwrite your existing one -- it's named config.php.default instead now. Unless you had to your config.php for a special version upgrade situation above, but in that case it's already addressed by those special instructions).
4. Don't worry about your style.css file - as of v1.7.7 the one in the .zip is named style.css.default so unpacking and uploading the adsql/ folder from the latest zip will not overwrite your existing one. If there is a special situation (such as 1.7.5 release) requiring an updated style.css you should have already dealt with this with the special version situation instructions before you got here.
5. Your web interface should now be updated on the web host and ready for use. Give it a whirl, and remember, you made backups before you started messing with any of this (didn't you...?) So don't panic.
if you didn't make backups... well, my advice would be start over from the beginning. One Page 1 of this forum topic.
Question: The Web Interface Doesn't Work At All! What should I do?
1. First, make sure you have uploaded the entire adsql folder structure from wherever you unpacked the distribution .zip file and that everything in the directory structure is where it belongs. There are many files and folders under the adsql folder, and they all have to be uploaded to the web host while preserving the relative locations of the folders. In other words, the admin, include, images, etc. folders under adsql have to be located under adsql on the web host too, and all the files in each of those folders need to be where they were located originally in the .zip file. Any decent FTP client will be able to "recursively" upload the entire adsql folder to your web host and preserve the relative location of everything in it. Check the help/docs for your FTP client.
2. Make sure you have a config.php file under adsql/include/, and that the correct DB name, hostname, DB username/password, etc. is set in the file. If you did not save/copy the config.php.default file you edited as config.php, go back and read the Web Interface Installation instructions for New AdsQL users on page 1 again.
3. Make sure you are typing the correct URL for where you uploaded the adsql folder on your website/webhost.
4. Make sure the webserver supports PHP 5.x with MySQL.
5. Make sure the permissions are correct on the adsql files and directories on your web host to allow the web server to read the files. The server only needs to be able to READ the files, there is no code anywhere in the web interface that causes it to write anything in the adsql folder, so in all but the most peculiar of circumstances, the webserver daemon should not need to have write permissions on anything in the adsql folder. So assuming your account on the web host is the owner of the files, it should work fine if the permissions on files in adsql/ are "644" (rw-r--r--), and the permissions on adsql itself and the other subdirectories underneath it are "755" (drwxr-xr-x).
Question: The Web Interface Doesn't Work on My Hosting Provider's Webservers! I'm getting 5xx-series internal server errors or other problems! What should I do?
Check the question and suggestions above first. If they don't help, contact your hosting provider or refer to their documentation on how to run web content that uses PHP and MySQL. They are the only people who can be expected to know how their webservers and hosting control panel work, and what (if any) special things you will need to do to use PHP-enabled web content. Every hosting provider's setup and "easy to use" cutesy hosting control panel can be different from the next.
Some hosting providers have "customized" their servers to the point that it is impossible to run PHP content without putting it in special directories on the web host, or without enabling special options in the hosting control panel for that site, or uploading an .htaccess file, or without calling them. If you pay them for hosting service, they should be able to help you. If they can't help you, maybe it is time to find a different provider.
Top Logo Customization
ads.php loads an 800x100 logo named
logo03.jpg rather than
logo02.jpg that the rest of the web pages in the interface use. This is because the ads display page uses a "background fill" to the left of the logo image and it looked better to use a different logo image that right-aligns the text rather than centers it. Samples of both files are included in the .zip file with our community logo.
If you want to use your own logos, you will need to make 2 800x100 "banner" images and drop them into the adsql/images/ directory on the web host as filenames logo02.jpg and logo03.jpg, unless you want to do something different on your own.
Top Logo "Left Fill" Background Color For ads.php
Also note that if you are going to put your own logo on your web interface, you will probably also want to edit the
background-color:#000000; line in the
td.imgbg style definition in the
style.css file, to set an RGB hex color code that "works well" with the background color of your logo. #000000 is black.
Cheers,
PharaohsPaw
Linear Mode
