Thread: Official LOTRoster Release and Support Thread.

Thanks guys, I didn't even notice that when setting up, it had said something about taking a while and I wanted to get it up and running asap, my bad, just did a force on it. I'll check in a few hours when i wake up for school.

Does anybody have a few tips at how to incorporate this into php-nuke? i'm thinking it's best to put it into the modules and just including all of the standard menus and such, just not sure where to start, I'll work on it more as I can.

Looks like there is a "Wrapper" module for phpNuke:
http://users.tpg.com.au/staer/NukeWrapper.html

I stopped using phpNuke years ago, so I am out-of-the-loop as far as recent updates.

IMHO, something like that would be your best bet. It should "wrap" your phpNuke web site around the designated file.

Ok I have it somewhat working, had to install LOTRoster into my webroot and then also wrap the lotroster.php file into a module index.php, it looks kinda weird and doesn't function properly but I'm trying to get it to act right. It won't let me use the index.php included to wrap, as it calls for another file. All in all I'm working on it and seeing what I can do, at least I have this roster viewable, and it works much better than my old hand entered roster setup.

I need to make all of the links and includes relative to being in http://www.watchersome.com/modules.php?name=lotroster
aka
http://www.watchersome.com/modules/lotroster

and i'll be able to remove all of the includes and such from the base directory of my site, but for now that's what has to be in order for it to function, as with modules the files being called believe they are on the root, not in some nested directory.

This will be a fun project and I hope it will turn out well, good thing I have the next two days off of work haha

I'm no expert in phpNuke, but I caution against installing it directly into the modules directory (or a subdirectory in there), as that is a phpNuke directory.

IMHO, best practice would be to install it in a subdirectory of your domain (like www.watchersofme.com/lotroster/), and then work on wrapping your site around the installation, rather than trying to put the installation into your site (if that analogy makes sense?).

New version Released 1.2.0 available for download.

Changes in 1.2.0:

A few changes in behaviour with template fields. If you still wish
to display the class and level in a single column, replace "class" with
"classlevel" in your display template.


NEW: Profession and level icons.
NEW: Fields with icons can now be shown as: Text Only, Icons + text (like before) and Icons Only.
NEW: You can now replace the default LOTRO rank names with custom ones.
NEW: New template fields: "rankname" (combined rank icon + character name), "level" and "classlevel" (combining class+level, like "class" used to do). "class" now only displays the class without the level.
NEW: Authentication support for Invision Power Board 2.3.x, SMF 2.0 and Drupal 6.
IMPROVED: Optional row highlighting - edit css/lotroster.css and see the note there on how to enable it.
IMPROVED: The menu entries for the three extra stat pages can now be renamed
IMPROVED: All columns and header text are now left-aligned for consistency.
IMPROVED: popup tooltips when hovering over icons
IMPROVED: Verbose logging now logs when starting and ending an offline update
IMPROVED: Will now refer to your guild as either a Kinship or a Tribe where appropriate.
IMPROVED: More robust template handling.
IMPROVED: Reports and logs if data.lotro.com is down for maintenance rather than just report a failure to update.
FIXED: Swapped decimal and thousands separators in the charts percentages
FIXED: Added missing "level" sort option on the dropdown menu.
FIXED: Vocation and race icons couldn't be disabled in the configuration.
FIXED: PHP notice if pvmprank icons were disabled.
FIXED: Corrupted log entry if data.lotro.com is down.

Is there a way to keep track of the maximum radiance seen for each character? Or is there a way to *sigh* manually keep track of it? A simple interface to keep track of a manual stat or two would be an excellent addition.

Thanks!

Our install has been working nicely for a while, but I started having an issue recently out of the blue.

I have a cron job to pull the update once each night at 3 AM. Again, it's been working fine for a while. Now, it has started putting everything to "zero" or "none" every other night.

So, last night I think it did that. Tonight I think the cron will run, and things will reflect correctly for 24 hours.

Any ideas? I have already flushed it just thinking something was currupt somewhere...

You can see our website here.

RE: "Our install has been working nicely for a while, but I started having an issue recently out of the blue.

I have a cron job to pull the update once each night at 3 AM. Again, it's been working fine for a while. Now, it has started putting everything to "zero" or "none" every other night.

So, last night I think it did that. Tonight I think the cron will run, and things will reflect correctly for 24 hours.

Any ideas? I have already flushed it just thinking something was currupt somewhere..."



Ask him to check (while logged as an admin) what error message he has in LOTROster's log, and to repost it.

My first guess is access to data.lotro.com while polling individual character stats fails either due to a timeout or load issues on data.lotro.com's site. Tell him to change his cron job from 3am to a more random hour (like 2:27am), to ensure that he's not running it at the same time as his server does nightly maintenance, and see if it helps.

Originally Posted by Gyrm

RE: "Our install has been working nicely for a while, but I started having an issue recently out of the blue.

I have a cron job to pull the update once each night at 3 AM. Again, it's been working fine for a while. Now, it has started putting everything to "zero" or "none" every other night.

So, last night I think it did that. Tonight I think the cron will run, and things will reflect correctly for 24 hours.

Any ideas? I have already flushed it just thinking something was currupt somewhere..."


Ask him to check (while logged as an admin) what error message he has in LOTROster's log, and to repost it.

My first guess is access to data.lotro.com while polling individual character stats fails either due to a timeout or load issues on data.lotro.com's site. Tell him to change his cron job from 3am to a more random hour (like 2:27am), to ensure that he's not running it at the same time as his server does nightly maintenance, and see if it helps.

Since the data.lotro.com outage, I've been having the same problem (apparently random records alternating between pulling down real data and pulling in blanks) when my cron job was running at 5:00 AM ET. I followed Gyrm's recommendation and switched the time to an odd time in the afternoon ET and it's run twice now with no errors. Sounds like the server has been busy with off-hours tasks that are interfering with the data pulls.

I have my task running at 3:10am (web server time), and it completes in about 9 minutes. No weird happening or errors.

Looks like I'm a little behind the times, but I wanted to pop in to say that 1.2.0 is very nice!

I also have a very minor feature request - so minor, that it's really no matter whether you implement it or not, since I've found the single character in the source that needs to be changed to implement it. The default sort order for sorting a new column is ascending, but almost every column is most useful in descending order. Ideally, I suppose you'd determine this default on a column-by-column basis, but a simple toggle to sort A or D by default would probably do the trick.

Originally Posted by atteSmythe

The default sort order for sorting a new column is ascending, but almost every column is most useful in descending order. Ideally, I suppose you'd determine this default on a column-by-column basis, but a simple toggle to sort A or D by default would probably do the trick.

I'll have to disagree with you on this point. The sorts I use most often are character name, user name, and class. I like character name and user name sorted A to Z and the sort order for class doesn't really matter. So, for me, the current A to Z works fine. I like your suggestion of having a different default sort order for each field, but I have a feeling that would be more difficult to implement than it sounds.

Originally Posted by TechnoBlue

I'll have to disagree with you on this point. The sorts I use most often are character name, user name, and class. I like character name and user name sorted A to Z and the sort order for class doesn't really matter. So, for me, the current A to Z works fine. I like your suggestion of having a different default sort order for each field, but I have a feeling that would be more difficult to implement than it sounds.

That's why I was asking for a setting. I use it most often to check on stats, which are utterly useless sorted ascending.

I will pass along a suggestion, but let me know what, exactly, you'd like (i.e. sort option per column, etc).

If not, feel free to edit the code yourself. Just make note of it somewhere safe, so you can re-edit when there are updates to that file.

I've got LOTRoster installed and working, but I'm having trouble with the character claiming. I've got a standard, new, Drupal 6 install at site.com/core with LOTRoster in the same database in a sub directory called site.com/core/lotroster. I've enabled all of the character claiming fields: avatar, username and type. I set the config.php path in the LOTRoster settings to ../sites/default/settings.php.

When I log into the Drupal site, then navigate to the LOTRoster folder, I don't see any character claiming links. The roster is working fine otherwise and the error log shows no errors in debug mode.

Suggestions?

Thanks!

Originally Posted by turdburgler

I've got LOTRoster installed and working, but I'm having trouble with the character claiming. I've got a standard, new, Drupal 6 install at site.com/core with LOTRoster in the same database in a sub directory called site.com/core/lotroster. I've enabled all of the character claiming fields: avatar, username and type. I set the config.php path in the LOTRoster settings to ../sites/default/settings.php.

When I log into the Drupal site, then navigate to the LOTRoster folder, I don't see any character claiming links. The roster is working fine otherwise and the error log shows no errors in debug mode.

Suggestions?

Thanks!

Looks like Drupal 6 support was added in 1.2.0. Can you confirm that you have the latest version of LOTRoster?

Also, when you installed Drupal, did you set your database table prefix to something other than the default?

Also, in the documentation, it mentions that the config setting should be "../sites/all/settings.php". Can you change it to that and try again?

Originally Posted by ElennaHart

Looks like Drupal 6 support was added in 1.2.0. Can you confirm that you have the latest version of LOTRoster?

Also, when you installed Drupal, did you set your database table prefix to something other than the default?

Also, in the documentation, it mentions that the config setting should be "../sites/all/settings.php". Can you change it to that and try again?

I did a fresh install of LOTRoster 1.2.0, no prefix on the DB tables and there is no settings.php file in sites/all/ in a default Drupal install unless you put it there for some some reason. The default location for settings.php in Drupal is /sites/default/settings.php.

Originally Posted by turdburgler

I did a fresh install of LOTRoster 1.2.0, no prefix on the DB tables and there is no settings.php file in sites/all/ in a default Drupal install unless you put it there for some some reason. The default location for settings.php in Drupal is /sites/default/settings.php.

I know nothing about Drupal, but I just wanted to check one thing. In the Drupal 6 download, that file is actually named default.settings.php. I guess they encourage you to rename it to settings.php?

That settings.php file, it is in site.com/core/sites/default/ or site.com/sites/default/ ?


If you log in as Admin, and view the logfile, does it mention anything about authentication errors, or anything like that, that might help?

I'm not sure if you can get there manually, but the link to the Claims page is:
.../lotroster/index.php?rm=rm_claim_char

Originally Posted by ElennaHart

I know nothing about Drupal, but I just wanted to check one thing. In the Drupal 6 download, that file is actually named default.settings.php. I guess they encourage you to rename it to settings.php?

That settings.php file, it is in site.com/core/sites/default/ or site.com/sites/default/ ?


If you log in as Admin, and view the logfile, does it mention anything about authentication errors, or anything like that, that might help?

I'm not sure if you can get there manually, but the link to the Claims page is:
.../lotroster/index.php?rm=rm_claim_char

The install process will rename that file for you provided you have file permissions set properly. My install correctly created a new settings.php file with all of the correct info at the correct location which is /sites/default/settings.php.

No errors in the error log, everything is nice and clean and users accounts are able to login fine. Navigating to the character claiming link you gave above, results in the following message:

"You must be a user and logged in to use this function."

So, it's not getting the cookie info is my guess, but I can't find anything in the log files to help me figure out what's wrong exactly. The roster and the Drupal site continue to work perfectly otherwise.

Have you had any luck with Drupal 6?

If not, you might consider emailing the developer, or I can email on your behalf.

Originally Posted by turdburgler

The install process will rename that file for you provided you have file permissions set properly. My install correctly created a new settings.php file with all of the correct info at the correct location which is /sites/default/settings.php.

No errors in the error log, everything is nice and clean and users accounts are able to login fine. Navigating to the character claiming link you gave above, results in the following message:

"You must be a user and logged in to use this function."

So, it's not getting the cookie info is my guess, but I can't find anything in the log files to help me figure out what's wrong exactly. The roster and the Drupal site continue to work perfectly otherwise.

In the LOTRoster/auth/drupal.php file, find:
include_once($forum_config);

Replace with:
require($forum_config);


See if it gives an error message about a 'file not found'. Hopefully it will point us in the right direction. I think you might need to be logged in as Admin to see the error messages - also, check to make sure you have the verbose errors showing.

Originally Posted by ElennaHart

In the LOTRoster/auth/drupal.php file, find:
include_once($forum_config);

Replace with:
require($forum_config);


See if it gives an error message about a 'file not found'. Hopefully it will point us in the right direction. I think you might need to be logged in as Admin to see the error messages - also, check to make sure you have the verbose errors showing.

OK, finally found some time to try this. Changed the file per your instructions. I am now able to get to the character claiming page by going to "index.php?rm=rm_claim_char" if I am logged in as admin in lotroster. This does not work logged in as any other user, I get the "You must be a user and logged in to use this function." message. Verbose logging is turned on, still no error messages.

A few questions from the developer:


The cookie handling code is almost directly taken from Drupal's own source code. I also re-tested it on my own Drupal site and it works correctly. The last few things I can think of, beside the obvious (incorrect database prefix and such):

- Is he referring to the correct settings.php file? If he has multiple copies of it (for example if he has multiple sites), his site might be using a different settings.php located elsewhere.

- Is he using https? Drupal uses different cookies whether you're logged using http or https. You need to access LOTRoster using the same protocol to ensure you access the right cookie.

- Have him make sure $base_url is properly set in Drupal's settings.php. It should be "http://site.com/core", with no trailing slash. LOTRoster relies on that parameter to build the correct cookie name.

- Does he have anything set in $cookiedomain in settings.php? I have only tested with this parameter being left commented out (so $cookiedomain is built dynamically by Drupal and LOTRoster)

Beside that, he'll have to check himself what's the name of the cookie his Drupal site sets when he's logged in (Firefox's cookie manager can easily let him do that, no idea about Internet Explorer or other browsers), and ensure it matches $cookiename auth/drupal.php is trying to look up on line 62. He can insert a:

echo $cookiename;

just before that line if he wishes to compare it with what cookie his browser has set.

Originally Posted by ElennaHart

A few questions from the developer:


The cookie handling code is almost directly taken from Drupal's own source code. I also re-tested it on my own Drupal site and it works correctly. The last few things I can think of, beside the obvious (incorrect database prefix and such):

- Is he referring to the correct settings.php file? If he has multiple copies of it (for example if he has multiple sites), his site might be using a different settings.php located elsewhere.

- Is he using https? Drupal uses different cookies whether you're logged using http or https. You need to access LOTRoster using the same protocol to ensure you access the right cookie.

- Have him make sure $base_url is properly set in Drupal's settings.php. It should be "http://site.com/core", with no trailing slash. LOTRoster relies on that parameter to build the correct cookie name.

- Does he have anything set in $cookiedomain in settings.php? I have only tested with this parameter being left commented out (so $cookiedomain is built dynamically by Drupal and LOTRoster)

Beside that, he'll have to check himself what's the name of the cookie his Drupal site sets when he's logged in (Firefox's cookie manager can easily let him do that, no idea about Internet Explorer or other browsers), and ensure it matches $cookiename auth/drupal.php is trying to look up on line 62. He can insert a:

echo $cookiename;

just before that line if he wishes to compare it with what cookie his browser has set.

Figured out why I wasn't seeing error messages, I was setting the wrong tick box. There is only one site installed and there is only one settings.php file.

I get three errors now:

Notice: Undefined variable: cookie_domain in /home/pofnnet/public_html/core/lotroster/auth/drupal.php on line 51

Notice: Undefined variable: base_url in /home/pofnnet/public_html/core/lotroster/auth/drupal.php on line 55

Notice: Undefined offset: 1 in /home/pofnnet/public_html/core/lotroster/auth/drupal.php on line 55

I set the base URL and cookie domain and the errors go away, but..still not able to claim characters. Not sure why the default settings for cookie domain are working for you and not me, but then I don't know how this is built dynamically by Drupal and Lotroster. Leaving it commented results in the first error.

Not sure if I'm understanding the last suggestion correctly, but adding echo $cookiename; to drupal.php results in the following:

Notice: Undefined variable: cookiename in /home/pofnnet/public_html/core/lotroster/auth/drupal.php on line 50

Edit your settings.php and set both $base_url and $cookiedomain.

Log off of Drupal and back on (to reset the cookie) and then go to LOTROster.

Originally Posted by ElennaHart

Edit your settings.php and set both $base_url and $cookiedomain.

Log off of Drupal and back on (to reset the cookie) and then go to LOTROster.

I did do that, I also logged in as a couple of other users on three different browsers to see if there was any difference. No errors, but also no character claiming.

I am running the following cron job and nothing seems to be happening:

/usr/local/bin/php /home/users/web/b169/sl.battlelo/public_html/lotroster/update.php

Lotroster only seems to update when I use the forceupdate link, not when my cron job runs, even when I force it to. I get no errors either.

You may need to check with your hosting company, as the Cron Job command line will be different.

Mine looks like this:


/ramdisk/bin/php5 -q /home5/(my site here)/lotroster/update.php

I've been having connection issues with LOTRoster since the SoM update. I think this is relatively normal and to be expected.

Originally Posted by ElennaHart

I've been having connection issues with LOTRoster since the SoM update. I think this is relatively normal and to be expected.

Me to, I wonder if this is because of the characters not showing up for 24-48 hours but I heard about.

It appears to be something with the 'extra' data. Turn off that option, and it will update peoples' levels, etc, just fine. It is currently not updating professions, morale, etc.

Originally Posted by ElennaHart

It appears to be something with the 'extra' data. Turn off that option, and it will update peoples' levels, etc, just fine. It is currently not updating professions, morale, etc.

Thanks for the update!

As a warning, though, it appears that all characters who are 'present' but not 'appearing' on my.lotro.com will be removed from the roster. We had a lot of long-inactive characters pruned when I forced the update.

Same result here. Turned off the "extra" data and the update ran fine, though I lost all of the extra data that had been previously downloaded. The recently added toons now show up. Two toons that appeared on the in-game roster but never before appeared on my.lotro.com or LOTRoster suddenly appeared. (Yea!) But I also saw the removal of still-on-roster-but-long-inactive toons just like atteSmythe did. Hopefully the extra data will become available again soon and the missing inactive toons will be returned.

Anyway there is an update in the works for my.lotro 3.0?

I really miss the extra features

I don't think there is a problem with LOTRoster working with my.lotro 3.0. I haven't seen any dev postings about changes in the XML data file that LOTRoster grabs from data.lotro.com. It looks like the problem lies in the transfer of data from the game servers to data.lotro.com.

The basic data comes from a single query to data.lotro.com resulting in the retrieval of the basic data for everyone in the kinship. The extra fields are pulled from separate queries for each character. So if you have 100 characters in your kinship, then the server must be queried 100 times to get the extra data.

Perhaps Turbine is holding back that extra data to reduce the load until the data servers finish repopulating the basic data from the game servers. Or maybe there is a problem with the data feed that is keeping the extra data for carrying over. Either way, I don't think the probelm is with LOTRoster. We just have to wait for Turbine to sort it out.

data.lotro.com should be up-to-date now. Part of MyLOTRO 3.0 was a massive restructuring of how we store data for the web sites. Data.lotro.com uses the new data source so over the course of updating all the information, data was sparse or stale for much of this week. This should be almost entirely resolved at this point.

One thing to note about any character data - if their information is not up-to-date at this point, logging that character in and out should see an update for that character to all sites within an hour or so.

There are a few new fields in the API as of Monday (some IDs and other additional fields) but none of the pre-existing fields should have changed as long as the XML parsing of any 3rd party utilities were using names to find fields and not using attribute position in the tags.

If there are still problems, please let me know and I'll look into it.

Thanks for the update, Bracket. Where can we get information about the additional fields that are now available? I just ran another update requesting the extended information pulling from character-level queries and am still receiving the following error:

---------------
Error:
(XML) Cannot retrieve XML data from the LOTRO website!

noCharacterData - No character data
---------------

When I run the update that uses just the kinship-level query, it works fine although several members are still missing from the roster. All of these members are no longer actively playing LOTRO and haven't been online for several months; however, they are still (appropriately) appearing on the in-game roster. The information for these characters used to be included prior to the my.lotro 3.0 update.

If those characters have been inactive for some time (a couple months or so), it's very likely that we do not have up-to-date information for them. To quote from one of the recent posts about this update:

Part of this update to my.lotro.com is a new player archiving system for dormant accounts. Normally players will be marked inactive 60 days after the last detected login for any of their characters. At that time their blogs and web access remain, but character data is archived to improve site performance.

Those characters will not have any detailed information from the charactersheet request. Their basic information (level, class, race) will still appear in the guildroster, however. The message that you're seeing (noCharacterData) is unique to that state so handling that appropriately should fix any errors you're seeing. Again, make note that you'll only have basic information about that character - unless they log back in, you will not know their professions, equipment, stats, and the like.

As to the additional fields, most of it is just for cross-reference purposes. Several ID fields have been added to data like race, class, etc. I've also added the explicit time at which the API response will fall out of the cache (the cached_until_gmt field at the bottom of the response). I'll double check, but I don't think there's any new "substantive" character data that wasn't there before. It's basically just utility fields for 3rd party devs.

Originally Posted by Bracket

If those characters have been inactive for some time (a couple months or so), it's very likely that we do not have up-to-date information for them. To quote from one of the recent posts about this update:



Those characters will not have any detailed information from the charactersheet request. Their basic information (level, class, race) will still appear in the guildroster, however. The message that you're seeing (noCharacterData) is unique to that state so handling that appropriately should fix any errors you're seeing. Again, make note that you'll only have basic information about that character - unless they log back in, you will not know their professions, equipment, stats, and the like.

As to the additional fields, most of it is just for cross-reference purposes. Several ID fields have been added to data like race, class, etc. I've also added the explicit time at which the API response will fall out of the cache (the cached_until_gmt field at the bottom of the response). I'll double check, but I don't think there's any new "substantive" character data that wasn't there before. It's basically just utility fields for 3rd party devs.

Thanks for the update bracket. Merlin is working on a fix, which is already in beta. Will be releasing soon. V. 1.3.0

Hi everyone,

LOTRoster 1.3.0 is now available for download. This new version is fully compatible with the updated version of my.lotro.com, and also supports characters up to level 65.

Changes in 1.3.0 (7-Dec-2009)
NEW: Option to set characters to the special "Inactive" rank when they are flagged as having been inactive for over 60 days by Turbine.
IMPROVED: Support levels up to 65
IMPROVED: Added claim information to CSV exporting.
IMPROVED: Parser will retry up to three times if an error occured while contacting data.lotro.com. Set logging to "Detailed" to have retries logged.
IMPROVED: Curl will now timeout after 60 secs instead of waiting for the whole script execution timeout limit.
FIXED: Would lose all existing extra character data if an error occured while contacting data.lotro.com for updated data.
FIXED: Harmless PHP notice in some situations when using the Drupal auth module.
FIXED: Don't abort updating if data.lotro.com returns "noCharacterData", meaning that this is an inactive character.
You can download it from http://www.lostrealm.ca/tower/lotrdownload

Thanks!