xen dev blog

giv leak pics pls

 

While very helpful, I don't find it essential to the site. It's normally not enough to work on IPs alone anyway when banning people, it just sorta gives you something to work off or the final nail in the coffin.

I'm sure the site would last a short while without it very easily.

Yousuckv2 would be nothing without IP audit

IP audit before release

 

[Loyal 2 da game]

Club goin up

On a tuesday

 

[Syed]

yo but for real can i get mod back sythe? i'll stop shitposting and try my hardest to make this site better and provide any help I can with the transition to xenforo . let me know, i'm not kidding right now

 

Richard, honestly...
The injustice of conservatism is quite trivial in its tenacity.

 

I don't think the absence of the ip audit system will be a big deal. Correct me if I'm wrong, but mods should still be able to look up ip addresses if nessesary. If so, I don't think having the ip audit is a must have.

Yes, but the reports prompt the search in the first place. IP Audits are the base of investigation for ban evader reports. Take that away and reports drop significantly. Unless the mods are hunting for ban evaders (they shouldn't), then removing the audit allows vaders to roam under the radar more freely.

 

IP Audit first before official release

This. Also no more rounded edges? Pleaseeee?

We need IP Audit before release fam

 

Yes, but the reports prompt the search in the first place. IP Audits are the base of investigation for ban evader reports. Take that away and reports drop significantly. Unless the mods are hunting for ban evaders (they shouldn't), then removing the audit allows vaders to roam under the radar more freely.

I wasn't aware that the ip audits played a big role in catching vaders. Usually when someone is dumb enough to use the same ip, they use the same skype, emails, etc. The ip audit system is fairly new to me and we seemed to have comparable vader reports back then, without the use of ip auditing. I'm not really concerned either way, so whatever works best.

 

I wasn't aware that the ip audits played a big role in catching vaders. Usually when someone is dumb enough to use the same ip, they use the same skype, emails, etc. The ip audit system is fairly new to me and we seemed to have comparable vader reports back then, without the use of ip auditing. I'm not really concerned either way, so whatever works best.

A lot has changed since back in the day, they're a bit smarter than they used to be

 

Sorry big rich, I'm about to go off on a tangent.

A lot has changed since back in the day, they're a bit smarter than they used to be

I don't want to ruffle any feathers but very little has changed throughout my time here. I'm not saying this is a bad thing. I'm a believer in the idiom, "if it ain't broke, don't fix it", which Sythe does well.

This brings me to my previous point. When I browsed the report a ban evader section: http://www.sythe.org/report-ban-evader/ it appears that 3/3 threads caught the ban evader using past information, not the ip audit system. I realize I don't have much to go on and that the ip audit system probably helps, but it appears it mainly helps the mod reduce the effort involved with catching evaders.

Back then people would either pm, report suspicions, or instant message mods when they felt like a member was a possible vader. This created a lot of work for mods, but vaders were still caught. If anything, the "smart" ones know how to ip evade, which the ip audit system does not account for.

As I mentioned before, I don't believe the ip audit system is needed right away. Just like it was released later on originally, I believe it could also be released later on with xen.

 

From my experience modding now IP audit has been invaluable creating connections between members. We certainly could bring it in later but doing so would be unfair to the generic users who trade on sythe.org as it would temporarily result in more malicious members being on the loose (not tracked down with the aid of the IP audit tool).

 

Monday and coffee

Today's list

more work on xen dice, add cards

write targeted patcher

investigate css Verts has been doing

ipaudit

 

investigating some memcache session errors matt reported

 

Nice work!

 

investigating best way to write targeted patcher

 

going to use contextual diff

 

targeted patcher built and tested for 1/2 patches

currently working on dice again before adding the patch required for dice

 

changing the three line patch in ViewPublic_Helper_Message to a massive patch that pushes all manner of post information down to the bbcode level:

$options['states']['post_id'] = (isset($message['post_id']) ? $message['post_id'] : NULL);
$options['states']['thread_id'] = (isset($message['thread_id']) ? $message['thread_id'] : NULL);
$options['states']['post_date'] = (isset($message['post_date']) ? $message['post_date'] : NULL);
$options['states']['user_id'] = (isset($message['user_id']) ? $message['user_id'] : NULL);
$options['states']['username'] = (isset($message['username']) ? $message['username'] : NULL);
$options['states']['message_state'] = (isset($message['message_state']) ? $message['message_state'] : NULL);
$options['states']['last_edit_date'] = (isset($message['last_edit_date']) ? $message['last_edit_date'] : NULL);
$options['states']['edit_count'] = (isset($message['edit_count']) ? $message['edit_count'] : NULL);
$options['states']['user_group_id'] = (isset($message['user_group_id']) ? $message['user_group_id'] : NULL);
$options['states']['secondary_group_ids'] = (isset($message['secondary_group_ids']) ? $message['secondary_group_ids'] : NULL);
$options['states']['is_moderator'] = (isset($message['is_moderator']) ? $message['is_moderator'] : NULL);
$options['states']['is_admin'] = (isset($message['is_admin']) ? $message['is_admin'] : NULL);
$options['states']['is_staff'] = (isset($message['is_staff']) ? $message['is_staff'] : NULL);
$options['states']['like_count'] = (isset($message['like_count']) ? $message['like_count'] : NULL);
$options['states']['message_state'] = (isset($message['message_state']) ? $message['message_state'] : NULL);
$options['states']['style_id'] = (isset($message['style_id']) ? $message['style_id'] : NULL);

This will give us the ability to make rich bbcode extensions like we already have in vbulletin. Doesn't cost anything extra to extend the amount of information sent to the bbcode formatter because the post is rendered once and then cached in the database and will only be rendered again if modified. In other words it adds trivial overhead to an O(n) process which is still O(n) after the modification

 

changing the three line patch in ViewPublic_Helper_Message to a massive patch that pushes all manner of post information down to the bbcode level:



This will give us the ability to make rich bbcode extensions like we already have in vbulletin. Doesn't cost anything extra to extend the amount of information sent to the bbcode formatter because the post is rendered once and then cached in the database and will only be rendered again if modified. In other words it adds trivial overhead to an O(n) process which is still O(n) after the modification

O(1) or gtfo

only thing i remembered from data structures

 

ok targeted patcher tested and working

Ran into an annoying curiosity -- some of the files shipped with xenforo have windows line endings. I didn't put these in because the files have never left the server -- they were downloaded onto the server directly and then unzipped on the server. Anyway windows line-endings cause the gnu patch utility to mysteriously fail without specifying why it failed. Once I figured out what was wrong I just installed dos2unix and run that over the files before patching. Now it works fine.

Going to look at making sure all the existing dice results are correct before moving on to cards and then ipaudit