Forged Alliance Forever

Re: Module communication

2014-02-28T02:46:58+02:00

@faf.lobby:
What did you think about a client side avatar cache?
Atm you download each avatar at startup ...

Reason why I ask ...
If I call "respix(avatar['url'])" to early the avatar is not loaded yet
I did not want to hook into "addcurDownloadAvatar" ... and there is no signal ...

https://bitbucket.org/IDragonfire/modul ... ault#cl-92

Statistics: Posted by Dragonfire — 28 Feb 2014, 02:46

Re: Module communication

2014-02-26T20:21:57+02:00

Ze_PilOt wrote:
If we really need group of friends (I still want to hear why , it should be on the server so it's portable.

It is k without group, but with groups, people can order the friend list ...
like "real friends", "developer", "caster", "setons player" ...
Some people are more important, then other ... and if you have a huge friendlist it is hard to find them...

The friend system is also good for the notification system ...
e.g. show new games, if hoster is in group x ...

Statistics: Posted by Dragonfire — 26 Feb 2014, 20:21

Re: Module communication

2014-02-26T20:12:40+02:00

That is okay because they are preferences.
If we really need group of friends (I still want to hear why , it should be on the server so it's portable.

For the bot, it just need to be feed data to repeat from time to time, it can send a notice that is displayed to all players at the same time, or just to one user or a group of user.

Statistics: Posted by Ze_PilOt — 26 Feb 2014, 20:12

Re: Module communication

2014-02-26T20:10:41+02:00

Ze_PilOt wrote:
No. Please don't store anything locally. It's really not needed and will lead to more problems than it solve.

I stored settings locally ...
https://bitbucket.org/IDragonfire/modul ... ault#cl-47
https://bitbucket.org/IDragonfire/modul ... ault#cl-20
https://bitbucket.org/IDragonfire/modul ... ault#cl-41
https://bitbucket.org/IDragonfire/modul ... ault#cl-38

For a friend system a friend can have a group, notification: on/off, maybe note, last seen, ...

Ze_PilOt wrote:
No. Please don't store anything locally. It's really not needed and will lead to more problems than it solve.
For notifications, it's probably easier and more effective to program a bot able to do it in the chat.

Agree ...
You mean the bot pm the user and the notification system track it?

Statistics: Posted by Dragonfire — 26 Feb 2014, 20:10

Re: Module communication

2014-02-26T16:06:06+02:00

Dragonfire wrote:
Ze_PilOt wrote:I think he did it that way because he had no access to the FAF database to begin with.

Also, it forces me to do a join in the request to get the right clan tag at user login (as your table use different UIDs), and that's probably triggered more often than the page display

Yeah, we can optimize it later xd
If I have time I redesign it
Hope the game_stats materialized colum increases the performance.

1. what are your cons again the server<-> notification thing?

3. server <-> friendlist:
Should I store, friendgroup and some properties locally or on server?

No. Please don't store anything locally. It's really not needed and will lead to more problems than it solve.

For notifications, it's probably easier and more effective to program a bot able to do it in the chat.

Statistics: Posted by Ze_PilOt — 26 Feb 2014, 16:06

Re: Module communication

2014-02-26T15:55:20+02:00

Dragonfire wrote:
3. server <-> friendlist:
Should I store, friendgroup and some properties locally or on server?

On the server please, better for people who use multiple computers.

Statistics: Posted by burnstreet — 26 Feb 2014, 15:55

Re: Module communication

2014-02-26T11:00:47+02:00

Ze_PilOt wrote:
I think he did it that way because he had no access to the FAF database to begin with.

Also, it forces me to do a join in the request to get the right clan tag at user login (as your table use different UIDs), and that's probably triggered more often than the page display

Yeah, we can optimize it later xd
If I have time I redesign it
Hope the game_stats materialized colum increases the performance.

1. what are your cons again the server<-> notification thing?

3. server <-> friendlist:
Should I store, friendgroup and some properties locally or on server?

Statistics: Posted by Dragonfire — 26 Feb 2014, 11:00

Re: Module communication

2014-02-26T10:48:11+02:00

I think he did it that way because he had no access to the FAF database to begin with.

Also, it forces me to do a join in the request to get the right clan tag at user login (as your table use different UIDs), and that's probably triggered more often than the page display

Statistics: Posted by Ze_PilOt — 26 Feb 2014, 10:48

Re: Module communication

2014-02-26T10:39:43+02:00

Ze_PilOt wrote:
I don't think it's necessary at all.

Then I change the implementation, maybe thebeej can say something about his decision (wait 2 weeks), but more important is question 1.

Statistics: Posted by Dragonfire — 26 Feb 2014, 10:39

Re: Module communication

2014-02-26T08:49:48+02:00

Dragonfire wrote:
Ze_PilOt wrote:2. Why aren't using using the login table directly?

As I wrote I consider about it ...
My excuse: thebeej did it xD

But if the amount of users increase it is a nice performance increase ... because we query the tabe A LOT.
(some kind of materialized view...)

I don't think it's necessary at all.

Statistics: Posted by Ze_PilOt — 26 Feb 2014, 08:49

Re: Module communication

2014-02-26T00:46:54+02:00

[VoR]Aulex:
ya i saw it
[VoR]Aulex:
thanks
[VoR]Aulex:
i think that would be a great idea
[VoR]Aulex:
would allow information to be transferred a lot better
[VoR]Aulex:
and would probably ease a lot of zep's frustration
DEV_Dragonfire:
write that !
17:44
DEV_Dragonfire:
psot it ..
17:45
[VoR]Aulex:
fiiiine
DEV_Dragonfire:
btw. what of zep's furstation?
[VoR]Aulex:
he gets pissed when no one reads announcments
[VoR]Aulex:
that popup could say like "new post in What's New section"

Statistics: Posted by Aulex — 26 Feb 2014, 00:46

Re: Module communication

2014-02-26T00:36:58+02:00

Ze_PilOt wrote:
2. Why aren't using using the login table directly?

As I wrote I consider about it ...
My excuse: thebeej did it xD

But if the amount of users increase it is a nice performance increase ... because we query the tabe A LOT.
(some kind of materialized view...)

Statistics: Posted by Dragonfire — 26 Feb 2014, 00:36

Re: Module communication

2014-02-26T00:25:38+02:00

1. I have to think about it.

2. Why aren't using using the login table directly?

Statistics: Posted by Ze_PilOt — 26 Feb 2014, 00:25

Module communication

2014-02-26T00:03:41+02:00

Atm the clanapp is standalone ...
I can implement a email notification if you agree,
but it would be cool to have more connections ...

1. webserver <-> notification system:

livestreams, e.g. your ones
events
clan invitation
new map
...

For live events, we send it direct over json to the faf.lobby ...

For persistent events, like clan invites, new maps, ...
I have another solution:

We have a event table:

Code:: CREATE TABLE `event` ( `id` INT NOT NULL AUTO_INCREMENT, `data` VARCHAR(256) NOT NULL, `time` TIMESTAMP NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`));

(data is a json decoded dict)
Each startup the client ask for all events since the last logout time and show it, maybe persistent ...

2. name changes:
For performance reason we copy the player_name from the login table to a clan app table ...
Only if a player login again we check the original name and update it, if changed ...
Can I add a hook to the change_name.php script, that automatically updates the name?

Statistics: Posted by Dragonfire — 26 Feb 2014, 00:03