The problem with e-mail notifications is that I don't have e-mail addresses by default, so you have to enter them.
I respect e-mail notification settings for all other notification types (mentions, likes.. stuff that doesn't really matter!), but for offers, they have a direct influence on the sender of the notification. I found that Barter was more engaging once I went through the very convoluted system of adding my RSS feed to that external website and started getting notifications, so I feel like if you enter your e-mail address, it would be a shame not to use that. If you really change your mind, I can simply reset your e-mail address in the database, but it'll make you unable to receive any notifications until you re-enter it.

IMPROVED: The search engine is as close as possible to what I wanted. It features thumbnails (that load and show up in a fade-in effect), it gives you extra information to help you find your game (tells you if it's decommissioned, a Steam package, or an Origin or Uplay key...), mobile version takes up more space, I've fixed many of the bugs it used to have, and the sorting is now pretty, PRETTY accurate. I'm not going to reveal my algorithm but I found it was cool (and a quick trick, too.)
Oh, and if you can't find the game you're looking for after typing 5-6 characters, press Space then Backspace. It's sort of a cheat mode , not a bug. I could have fixed it but it helps compensate for issues that could come up with game names that are very common, such as typing 'the'... I may try to improve that in the future to avoid having to do that trick, though.

FIX: E-mail notifications for offers (accepted, declined) will now always be triggered immediately. That's a change from Barter where you had to wait for another site to parse its RSS :)

NEW: E-mail notifications now include a short text summary of the bundle offer. It's not perfect, I know. I'd rather send HTML, too, but I've noticed that sending in HTML tends to have Google flag my e-mails as Notifications (which, yeah, I *know* they are, but Google doesn't bother to give me a notification (sigh) on my phone when it's not a 'General tab' e-mail. Which defeats the purpose of these notifications entirely.)

@joaoarena, no, but you can ask me in private, I won't bite. :P

Hmm, yeah, that may be a thing I can do.
I'd still have to bother with quantities, though...I suppose so. But it won't be realistic until I add the mass-edit feature to lists. Which won't happen until I have a single-edit feature for game pages (to tag, modify quantities, etc.)

One thing I didn't realize when I opened the trading system to the public was that I couldn't 'play' with game lists anymore. Previously, if I broke something, I could just reset it from a backup or just wait until the sync was done automatically again. Now it's likely to eliminate offers sent between a potential backup and the moment I screwed up... Ah well, I can always backup the table right before I run a test, right? Well, I for one wouldn't like that. :P

It's one of the reasons it's not going as fast as I'd like right now. Just look at the notification system. It works fine, except it doesn't frigging send e-mails all the time. But now that there are thousands of trade offers flying around, any change can have a drastic effect.
I didn't write the initial code (which was quite messy, although I do appreciate and respect its author Dragooon), and I've had to rewrite it several times. At one point it was deleting a user entry from memory, then immediately testing that user entry (!!) to see if it was empty or not.[1]
From what I'm seeing right now (even after that fix which I hoped would fix e-mail notifications), it looks like notifications don't get sent if you still have an unread notification in your popup. Except that in this code, an "unread notification" is a notification for which you haven't read the preview. So, if you receive a "like" on a post, you open the popup, you see someone liked it, cool, you close the popup... That's it, you won't get any further e-mail notifications until you come back and click 'Mark as read' (which is my convenient addition for those who got too many notifications recently.) Worse, e-mail notifications are all disabled by default. I wouldn't enable like notifications by default of course, but it's not particularly easy to find these settings, and having to find it and enable it separately is daunting, for a noob-friendly website.
I'm thinking I'll just modify my code to check if it's an offer-related notification, and if yes, and an e-mail address was entered, forcibly send a notification.[2] And yes, I'm going to meet another problem: "Okay man, I don't want your notifications!!!"... But why did you enter your address then :P So I'll probably do it. If too many users complain, then I'll restore it to disabled by default, and I'll try to make it clearer where to set this up.The priority should be to help Lestrade's stand on its own. , not reference Barter for everything. Personally, I have no plans to trade over there anymore, and I don't get why Barter wouldn't offer the ability to import its lists from LT's. :P
I don't know about you, but regardless of the Barter admin's good will, I have no plans to trade over there anymore. (The last offer I sent was 5 days ago, and even then it was at best a way to compare something between our two offer systems.)
I want to find a good balance between helping out users and wanting to put LT first.Well, this would allows me to focus on more important parts of LT (according to me at least).You know what, you should do it. Know why? Because anyone who's used a user script to fix Barter before *is* already a frigging nerd. :P

1.	For the curious: https://github.com/Wedge/wedge/blob/master/core/app/Class-Notification.php#L220
2.	Unfortunately, there are only 178 users who bothered to enter one... So, it's like 700 users don't care. :P) (And no, I can't get their e-mail address automatically, Steam doesn't provide it, thankfully. It *should* be on a voluntary basis.

I can do it manually but not automatically. It would be a real mess. It would also automatically cancel all your offers, and even your previous offers could end up being unreadable because of changed tradable IDs.

Note: I just remembered that Barter never deletes its tradable entries. Maybe the admin (I still hate not even having a nickname to address him... -_-) could do an API that returns tradable IDs. That way I might be able (not sure) to keep track of tradable IDs from Barter (but that does imply an extra column to my tables >_<) and it'd be easier to sync. There would still be a problem with quantities, of course. And that I don't want to have too many columns. Eventually slows everything down.

Bed time.

(And I hate that this Barter sync thing is getting asked so much. I know we share most of our userbases, but why doesn't anyone ask SteamTrades to sync with Barter as well? And why shouldn't it be Barter that bothers syncing with LT? :P)

FIX: The search engine was a bit broken, as you all know. It would narrow results down too much when typing more letters. I finally found the reason for the problem-- the code to narrow the search down was written with member search in mind, and only kept a result if the exact beginning was your search string. I've modified it to instead behave the same way as the alternate path does: take each word you typed in the search box, and make sure each of them is part of a game's name. It's slower than the previous bit of code, by a few milliseconds. I'm really sorry about that. (No I'm not. I'm sorry for the half-broken search, though.)Again: it's technically impossible.
What I *could* do is load your Barter tradables, compare each of them with LT's, then offer to add games it couldn't find at LT's, and remove games that are at LT's but not on Barter. But again, it wouldn't be able to take multiple entries of a game into account. Well, it could, but that would make it even harder to sort out list modifications. Also, a single game's quantity can be set to different values. And even if the value is x1, it's pretty compicated. Let's say I have Firewatch on both LT's and Barter. Now I'm trading my copy of my game at LT's. I no longer have a copy. Let's sync with Barter. It says Fiewatch. Okay. So the question is now, is that a NEW copy that was recently added to Barter, in which case I should import it, or is that the copy I traded on LT, therefore needing to be ignored? So, Lestrade's now has several possible actions: ignore the game (which is silly), add it anyway (which is also silly), or the realistic one: load LT offer history, see how many copies of that game I possibly traded. Then check the last time LT imported Barter data. Then LT can determine the number of copies you had before your last sync. At this point, it has two choices: if you traded your copy at LT's after the last sync, then Barter's copy is likely (but not 'certain') to be the copy you traded, in which case we'll ignore it (and it's up to Barter to sync with LT and remove that copy), or you traded your copy before the last sync, in which case it's very likely the game should be added to the database again.

I'll let you imagine the complexity of adding this code, having to ask users for their opinion on all games that different in quantity (that would be a relatively complex UI and writing good UI isn't my strong suit), and having to keep track of the last time you synced with Barter, once for each different list. Not only that (!), but in order to make things realistic, Barter would have to do the exact same thing for its tradables, in the opposite direction. There's another alternative, sending each other completed offer data, but that wouldn't take care of items you added manually... So, we'd have to send each other, in real time, every single addition or removal we do (either manually or automatically) to our lists. And because networks are what they are, it can't be guaranteed that all data will be transmitted properly. For instance if one of the sites is down for an hour. So in that situation we need to create an update queue where additions and removals are temporarily stored, and sent regularly to the other site until it acknowledges it received the data. But we'd also have to enable an acknowledgement queue, just in case a network issue prevented sending confirmation to the other site. And finally, if we receive the data but there's a bug on the local website, we could get corrupted data that's seen as 'correctly transmitted', or even funnier, site crashes while attempting to add data, then all games being added in that moment get lost, probably without your knowledge of it.

So, in our realistic situation (i.e. all lists are perfectly synced in realtime), we find ourselves with a *monstruous* codebase just to implement the basic feature of syncing our lists. I know I won't write that, because I have more important things to write first, and I doubt the Barter admin would write that, because I'm not sure he'd think himself capable of building a network-fool-proof syncing mechanism.

Let's think about it again in a year's time, okay...?

There's also the possibility that someone would want to write user scripts to accommodate for these problems, but they'd have to keep all syncing dates in storage, and account for all situations I listed above from the top of my head (a word which here means "I'm sure there are plenty more ways to break sync.")
What you wanna do is maintain one list thoroughly and then update the other one from time to time. My Steamtrades list is far from complete, I try to put most of my unbundled (or rarely bundled) games there, because that's what gets traded the most at ST, and my bundle games can stay on LT.

I wouldn't have been able to automatically sync forever between Barter and LT like I did in February and most of March, because the moment you become able to edit your LT lists (and send offers), then it's no longer a simple game of scraping Barter for list data. You can't have your cake and eat it, if I may say.No, game IDs match, not tradable IDs. That's where it counts. But even if I did sync only by game ID (thereby destroying all metadata regarding quantities and stores), I'd still have the problem of having to determine whether the non-matching quantities for your games are due to the addition or removal of one game on one side... But which one, eh?Yeah it was useless anyway-- you'll understand when you start using the bundle game importer.

Which reminds me I still haven't finished writing the new bundle update script, AH AH...
That's always my problem with forums: either I answer thoroughly and hope it'll help, or I work on the code itself. I just spent half an hour explaining why I can't do syncing, but maybe someone will figure out a way to do perfect sync in less than half an hour. :P

It's been addressed 6727 times, + in the FAQ... :whistle: :ph34r: