Tey

Yeah, there is a race condition in xmqp_events.py: if onBattleInit() is called before the XMQP connection has been made, the capabilities of players that are already connected to the XMQP server are not sent to the flash modules, so you don't see icons for them. It happens with fast computers on slow connections I guess (my case at least). Calling _sendCapabilities() at the end of onXmqpConnected() fixes that issue for me: diff --git "a/C:\\Games\\World_of_Tanks\\res_mods\\mods\\packages\\xvm_battle\\python\\xmqp_events.py.bak" "b/C:\\Games\\World_of_Tanks\\res_mods\\mods\\packages\\xvm_battle\\python\\xmqp_events.py" index 032c9c4..d401c94 100644 --- "a/C:\\Games\\World_of_Tanks\\res_mods\\mods\\packages\\xvm_battle\\python\\xmqp_events.py.bak" +++ "b/C:\\Games\\World_of_Tanks\\res_mods\\mods\\packages\\xvm_battle\\python\\xmqp_events.py" @@ -40,6 +40,8 @@ def onXmqpConnected(e): if xmqp.is_active(): xmqp.call(data) + _sendCapabilities() + def onBattleInit(): _sendCapabilities() There's a similar (somehow) issue when WoT exits/crashes in the middle of a game, and the player starts it again. WoT will resume the game, but the XMQP client will not be started: _start() from xmqp.py will be called, but since no XVM token would have been downloaded yet, config.networkServicesSettings.xmqp will be false, so no _XMQP instance is ever created. EDIT: check this patch for a way to fix that second issue (but I'm almost sure you won't like it because of the FIXME).

Dunno if it's okay to talk English in here, so sorry if it's not. Thanks a lot adri1, your script is really clever and useful. Unfortunately, there's a big limitation as it only works for arties that are within the view range of your tank (BigWorld.entity(vid) returns None otherwise). It's even worse for arties in arty view (strategic mode), as it depends on where the arty is aiming: your tank can be located near another friendly arty, and yet you won't see where he aims at if you aim too far from his position (even if both of you aim at the same location!). But that's still a very useful addon, and probably a good base for implementing the XMQP arty features suggested there. I'll give it a try... Updating every seconds is probably too slow, but doing it every frames is probably too much. Something like every 10 frames should probably be better (using ON_EVERY_FRAME and a frame counter in refreshAimPos()). Here are the instructions for those who haven't understand how to install that wonderful addon: download attachment from adri1 post and extract it into res_mods\configs\xvm\py_macro\xvm create a new file in res_mods\configs\xvm\py_macro, name it aimpos.py (name doesn't matter) and put the following in it (original code from adri1 is invalid): from xvm import aimingposition @xvm.export('xvm.aimpos', deterministic = False) def refreshAimPos(): aimingposition.posManager.refreshList() return '' edit the file res_mods\configs\xvm\default\battleLabelsTemplates.xc and add the following lines just before the line "hitlogHeader": {: "AimPos": { "enabled": true, //"updateEvent": "ON_EVERY_FRAME", "updateEvent": "ON_EVERY_SECOND", "alpha": 0, "format": "{{py:xvm.aimpos}}" }, edit the file res_mods\configs\xvm\default\battleLabels.xc and add the following line just before the line ${ "battleLabelsTemplates.xc":"def.hitlogHeader" },: ${ "battleLabelsTemplates.xc":"def.AimPos" },

Thanks for your answers, I'll follow your advice. Oops sorry, I've just realized I linked to the wrong thread. The proper thread is this one where some XMQP features are being discussed. I'm interested in developing the arty parts, like showing on the minimap when ally arties are reloading (and maybe for how long), where they are spotting and when/where they are shooting (I believe these features will be added by WG sooner or later anyway). I can't read Russian, so I can only rely on the poor Google translation to understand that thread content, and I'm not sure if seriych is working on these features or only suggesting them. Also, I've only developed a few Python mod for WoT so far, but never played with the AS/SWF part. I guess it's only a matter of using the proper tools, but it's gonna take some time, so if someone else is already working on that, I'll just wait patiently EDIT: looks like someone is actually working on that, so I'll just follow the progresses from the thread he used.

Hi, Just so you know, since tonight, the XMQP features don't work for me anymore (no sixth sense icon next to my name in the players panel). Tonight, the XMQP server simply dropped all the connections (with a "low memory" reason as observed using Wireshark), but right now, it accepts the connections, but never sends any messages (so the exchange name is never known, and sending messages from client raise an exception). EDIT: it's fixed now. I also have a few questions: does the server only forward known messages (those in xmqp_events.EVENTS) or does it also forwards unknown messages? I'd like to extend the XMQP feature, but if the new messages my script sends are not forwarded, I won't be able to test :( does the server makes sure the messages are only forwarded to teammates? If so, does it verify that each connected XMQP client actually belong to the team they said they belong to? For instance, if my script sends sensitive information, I don't want the enemies to be able to receive them using a specially crafted XVM client. is anyone working on the suggested features described there? I'd like to try implementing the arty stuffs, but if someone else is already doing it, I'd rather not waste my time. Thanks.

Thanks, I was expecting experimental data but this is good enough for my needs :)

Where can we get an up-to-date scale please? I mean a table which shows the WN8 rate for each player percentile (with a small step, like 1%). I didn't find anything like that on noobmeter or wnefficiency (or what I found was pretty old). I like the wotlabs color scale because it contains more levels than the XVM one which jumps from 20% to 60% and then to 90%. But if the wotlabs levels do not match the reality, it's useless indeed :(

Thanks for that new feature, but you should validate the input of the update script, as it is easy to set the "flag" attribute to unexpected values (even inject HTML code, maybe script too). For instance, you can replace the flag icon by the word "XX" using the following URL (there's an extra step to perform, but I won't reveal it to avoid script kiddies): https://account.modxvm.com/account/updsrv?service=flag&value=%27%3EXX%3Cimg%20src=%27You can validate the value (on the server side) using a regexp like m/^(default|unknown|[a-z]{2})$/i for instance.