Group badges not loading over https?

[Gaby]

Hi!

This might seem like a very noob question, but RZ is kind of my last resort. I had group badges working for YEARS, but after a certain point in time (probably when I switched to https), my group badge does not change, when I change my favorite group.

You can see it in the screen here, changed favorite, but group badge doesn't change:



This actually does work on my localhost, but just not on the live website. Also loading of the group badges on profiles and in rooms seems to work fine, the problem is just that the badge doesn't change when you switch your favorite group.

Somebody has an idea?

[MentaL]

[MattSantos]

You put these lines :
.htacces:

RewriteRule ^habbo-imaging/badge/(.*).gif$ ./habbo-imaging/badge.php?badge=$1

web.config:

<rule name="Habbo Imaging Group Badges">
<match url="^habbo-imaging/badge/([^/]+)" ignoreCase="false" />
<action type="Rewrite" url="/habbo-imaging/badge.php?badge={R:1}" appendQueryString="false" />
</rule>
<rule name="Habbo Imaging Avatarimage 1">
<match url="^habbo-imaging/avatar/([^/]+)" ignoreCase="false" />
<action type="Rewrite" url="habbo-imaging/avatarimage.php?figure={R:1}" appendQueryString="false" />
</rule>
<rule name="Habbo Imaging Avatar Image 2">
<match url="^habbo-imaging/avatarimage/([^/]+)" ignoreCase="false" />
<action type="Rewrite" url="habbo-imaging/avatarimage.php?username={R:1}" appendQueryString="false" />
</rule>
<rule name="Habbo Imaging Avatar Head">
<match url="^habbo-imaging/head/([^/]+)" ignoreCase="false" />
<action type="Rewrite" url="habbo-imaging/head.php?figure={R:1}" appendQueryString="false" />
</rule>

[Gaby]

You put these lines :
.htacces:


web.config:

I definitely already have that stuff haha. The badges show just fine, just not when you switch your favorits group

[Gaby]

Problem solved. The outgoing packets for favorite group change and stuff only got send to the personal session instead of the whole room. Also all of the group badges got refreshed instead of just one. Don't know why my localhost "reacted" differently to this, but yeah, it's fixed now.