http://www.diezcuriosidades.com/wp-c...stradamus2.jpg
Printable View
The first one doesn't really matter. Take the scenario after the decay of Neobot, for instance: right after it went out, both RedBot and XenoBot were already arround, but it was iBot, released quite a while later, that dominated the market until WindBot, which came over an year later, took its position. Of course, you do have some lead by being the first one but it's not that much.
While that's true, you need to look at why. The reason iBot won is because RedBot was terrible and people were scared of injection because of the precedent set by NeoBot. It had nothing to do with the merit or funtionality of iBot, or a failure on the part of XenoBot, but rather the fear made by Ekx.
I'm sure when the new client comes to stay, this stigma will be somewhat depleted due to both the new environment and the example that XenoBot has set. Because of that, whether or not the first bot is injected, its timing will propel it to the top *unless* it happens to be terrible.
Minor is an understatement. In order to send accurate mouse clicks to the UI, the bot absolutely must have some idea of the structure of the client's UI. That's one of the most complicated things to work with currently, and the only reason they've managed (imho) is because the structure and information was freely released on tpforums.
They'll need to start from square one and reverse engineer this structure, and likely the creatures and containers structures, before they're able to do things like attack monsters, move items, and use the shop. Even with a perfect proxy, there's simply no way to do all of this without some way to identify the rough shape of the UI.
In fact, while XenoBot also relies on this data, it would likely be much easier for me to replace the existing XenoBot UI with an external UI, thus breaking my reliance on this data, than it would be for WB to reverse engineer the new UI structure.
Just when I planned better TA integration into the client... ;P
Anyway, the new client might be actually easier to RE because Qt unifies lots of stuff.
Just whole events ping-pong is annoying, but I believe it requires some IDA scripts matched to the Qt5 meta compiler used, and it should be easy enough to move around.
I'll drop a post on TPForums if I figure something out.
While it's true that QT leaves behind a sufficient amount of metadata, it's actually the structures that will be difficult. When everything is coded with C++ best practices, it's the data structures that bite your ass. Proper OOP means pointer chains for days. It's slightly more complex to read an std::vector than a flat array, and extremely more complex to read an std::map or std::set. std::list is somewhere in the middle, but if they're using things like QString and QList, it's much harder again. It really depends on how it was designed.