Characters are not marked as inactive

[atkinsj]

Updated on this -- initially misattributed it.

We have several hundred characters added and they are all marked as 'active' and none are ever marked as inactive. I can't seem to find where this marking is to test.

[atkinsj]

I believe this is because the getActiveUserCharacters gets the characterLog that matches but does not check it's age at all.

[exodus4d]

Short answer: Is your cronjob running?

---

Long answer:

Yeah I know, this is in known "problem" :(

The expectations of an character, beeing "active" is not clearly specified. For example:

1. "An active character is a pilot who is currently loged on in one of the systems on the map"
2. "An active character is a user who is currently viewing at a map (but not necessarily in-game, or in one of the systems on the map"
3. "An active character is any character that belongs to a user who has at least any other character in-game"
4. ....

Present state:

For now, any character is marked as "active" when he is currently in-game (IGB) in a system which is mapped. So this does not represent any user who is viewing at a map (e.g. desktop browser users).

• The character_log table is automatically updated for the current active user every 5 seconds.
• character_log data is automatically deleted by a cronjob in characterupdate.php (make sure your job is running). The "cache"-time for log data is 300seconds and can be adjusted in pathfinder.ini ("CHARACTER_LOG")

Hint: There is no other way to automatically detect when a character becomes "inactive" (The IGB does not send JS beforeunload events when a browser tab is closed,...)

Upcoming changes in v.1.0.0RC3

• The current location of a character is updated over CREST.
• The IGB Header data for location information will become the fallback for IGB users.
• Location data for multiple characters can even be fetched from CREST even if they are no longer using Pathfinder. We probably don´t depend on any cronjob for updating this table.
• All this is coming in the next weeks

The Future

• If all the new CREST API endpoints are implemented by CCP (e.g. current ship information,...) Ill try to add more character information, or even characters who are not online in any of the mapped systems

[exodus4d]

Anything else, you want to know about this feature?

[atkinsj]

Thanks for the explanation exodus!

That makes a lot of sense. My cron jobs aren't running and I can't see to get them started at all: hitting /cron results in apache throwing a 404. Is there any way to troubleshoot this?

[exodus4d]

For testing, open http://[YOUR_DOMAIN]/cron in your browser should work, if you haven´t changed the settings in cron.ini for:

[CRON]
log = TRUE
cli = TRUE
web = TRUE

How it works:

1. Any request (e.g. /cron) is redirected to index.php (this is defined in .htaccess (Apache) or your server config (Nginx)
2. In your index.php the Cron-Class is initialized index.php L17
3. The constructor of the Cron-Class cron.php L226 parse the cron.ini file, add all cronjob endpoints (like /cron, /cron/deleteLogData, or /cron/deleteMapData, ... )
4. /cron -> triggers ALL cronjobs, defined in cron.ini, /cron/deleteLogData will just execute this specific cronjob (keep in mind, if a job is defined as "run once a day" the specific job will not be executed again, until 24h have passed.

Hint

• For testing, you could change @hourly to @instant, in cron.ini for a specific job, then you should be able to run this job ever minute (60s)
• For testing, keep the vars in cron.ini for log, cli, web at TRUE. If you could successfully call each job by its URL path, you should change webto FALSEand setup a proper UNIX crontab for calling /cron. So no one could start your cronjobs by simply "guessing" or "enter" the URL.

CLI => "Command Line Interface"

Why so complicated?

• Its easy, once you have successfully set up a UNIX crontab for calling /cron. You don´t have to care about anything :)
• Any new cronjob coming in future will be added to cron.ini, and it will be automatically be called by its configured time interval
• The /cronpath works as a "dispatcher" that decides which of the configured cronjobs should be executed. Therefore you should "ping" /cron ever minute because it could be possible, that there are configured cronjobs supposed to run ever minute.

[mrmurb]

The current location of a character is updated over CREST.

@exodus4d How are you planning to tackle Alliance maps using CREST? I've been experimenting with this but CCP has yet to implement this part of the API as far as I can tell.

Will you be using "Corporate" maps and having people add each Corp instead of the Alliance as whole?

PS. Awesome job on this!

[exodus4d]

@mrmurb The CREST "location endpoint" was implemented by CCP in January .
Source: https://developers.eveonline.com/blog/article/crest-updates-for-january-2016

Once a character logged in (by SSO), You can request additional "Scopes" like "location endpoint". this allows me to update the current location of this character, whenever I want.

Doku: https://eveonline-third-party-documentation.readthedocs.org/en/latest/crest/character/char_location.html

You have to request the current location for each pilot individually by its "access_token" (given by CCP when a SSO login was successful). So can´t request locations for all pilots in a corporation or perform any kind of "bulk"-request.

So yeah, any pilot that is tracked in an corp/ally have to log in into Pathfinder. But you don´t have to use the IGB anymore for tracking.

Even if a character closes the desktop browser afterwards, the "access_key" is still cached for this character, which enables me to perform following CREST "location endpoint" requests for this character e.g. by a cronjob every X Seconds.

90% of the implementation is already done and can be tested. The "Develop" branch should be stable (more information in #84)

The "core" SSO controller that handles all CREST calls, can be found here: https://github.com/exodus4d/pathfinder/blob/develop/app/main/controller/ccp/sso.php#L512

The implementation is a bit complex but straight forward :) The CREST API is build like a "tree". If you want the "location endpoint" you have to perform multiple API calls, by recursively "walking down" the "tree" like:
Root->Decode->Character->location

The response for each call is cached individually by the Cache-Control Headers, which CCP sends back.

[mrmurb]

@exodus4d Thanks for the very detailed answer.

The develop branch seems to work real nice even though it's a WiP! Runs super smooth, really looking forward to see how this turns out.

I take it as the Alliance map type is still not completed in this version. Map creation.

{
    ["character"] => array(2) {
        ["id"] => int(123456789)
        ["name"] => string(9) "My Super Special Name"
    }
    ["corporation"] => array(3) {
        ["name"] => string(14) "Corporation Name" 
        ["isNPC"] => bool(false)
        ["id"] => int(987654321)
    }
}

This is $characterData at: sso.php#502
As far as I can see the Alliance ID is never pulled in sso.php therefore #577 will always be false, or does the character need to have certain rights in order to create such a map?

Sorry, I realize that this has diverted far from the actual topic of this issue, if you feel that this should be in another issue please move it accordingly.

[exodus4d]

Yeah that´s right. Alliance maps are not implemented yet. Im focusing on privat/corp maps for now.
If they are working well and I had some time with testing, fixing alliance is done in 5min.

There is a simple reason for that: No one of my chars in any of my 3 Acc is currently in an alliance ;) . I probably have to "mock" some fake ally data for testing them.

Please don´t open issues for missing features/bugs in develop branch. If I´m done with all the points on my TODO list, would love to see you testing ;)

[atkinsj]

Thanks @exodus4d. I figured out the issue and this might be helpful for others in future running new versions of apache:

If MultiViews are enabled in your apache configuration (as in Options Indexes FollowSymLinks MultiViews) then you will get a 404 when trying to hit /cron directly and it won't be called. Longer explanation is here.