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.)
Any thoughts on enabling a "sync Lestrades lists with barter lists"-feature?
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.
The numbers in the URL's still match, don't they?
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?
Personally, i don't see me using that feature.
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