kupjones

I'll be standing by

I have to be honest here -- losing control *usually* means packet loss even though the game client is still running.   Download PingPlotter and point it to, say, Google and see if it reports any loss in the path.  If it does then you can use the trace to "backwalk" toward you until you identify the source of the loss.   In the past the loss was right at the WOT NA game servers and I  spent months sending then traces and telling them exactly which piece of hardware was showing the loss.   WG ended up moving to Central US off the East coast and things have been better sicen.

Good Luck

Try installing a virgin copy of WOT via the Game Center, then try that copy.   I wish Game Center would allow us to rename the game instance but it doesnt (at least I havent found a way) so you have to remember which instance it is as they are assigned a number.

LOL -- I guess I missed that part in your original post, sorry.   And for Aslain to look at it you have to upload the python.log file.  I've never seen the archiver *not* do its thing, so no idea why that wouldnt do it.   Follow this link

I assume this behavior does not happen in vanilla (safe) mode?

Post back if you need any additional help.  I've set this topic to notify me when there are updates.

If there is no obvious error in the log file then I start by renaming "mod" first to see if a packaged mod is the culprit.   If a crash continues I revert back and rename "resmods" and repeat.  That at least helps home in on the class of mod first (packaged or not).  Then start disabling mods one at a time.

BTW, I have found that sound mods typically are the most bugged mods -- although I did discover recently that an external python script for XVM was causing a problem in that it was outdated.  I forgot my first rule of python -- everything is evaluated, regardless of whether or not the code is actually used.  I caught the error in the python.log file.

8 hours ago, RaJCeL said:

Yes, maybe it was WG bug with event hangar. Wait and see...

Doesnt that always seem to be the case with event hangers?????   Sigh.

.... Ok, I added Custom Manager back in after the 1.6.0.1 patch --- and it seems to be operating now as expected, but I'll keep working with it to see.   One thing I noticed that is different -- when switching  to "Exterior" mode there is a pause, the tank disappears from the "garage" (now the festival), one only sees the festival and a shadow where the tank was, then we switch into the Exterior modification mode.   Before all I saw was an immediate switch into that tunnel area.

I'm thinking WG did something odd and then "fixed" it in the recent patch.

On 8/18/2019 at 12:29 PM, RaJCeL said:

I am back from my short vacations, so I will try to investigate the root cause in close future.

 

//EDIT:
Haven't found anything in logs and can't reproduce error, so it is hard to find anything to solve that... :(

Yes, very strange.  Is there a way to add some additional debugging that can be enabled/disabled through a JSON config file?   This only occurs in the hanger ....

Kind of crazy behavior -- does Customization Manager store its data in ......\AppData\Roaming\Wargaming.net\WorldOfTanks?   I ask because I went in and swapped an older copy of that directory in and CM started working -- for awhile.   Its almost as if data is being corrupted or not written out correctly.

Plus I am seeing new errors in the python log (attached)

python.log

On 8/8/2019 at 3:30 PM, RaJCeL said:

Also a solution from other user from forum thread:
"It's a temporary bug, if I switch to some other tanks and back to that one which had the bug, bug is gone."

Confirmed.  I had to switch between 3 different tanks 4 times before clearing the bug -- and I now see an error that I hadnt seen before (not that I stare at the log files all of the time).  I've attached the python logfile but this error I hadnt seen before:

2019-08-10 10:32:52.251: WARNING: [gui.Scaleform.managers.SoundManager] Sound effect "effects.vehicle_changing" not found
2019-08-10 10:32:53.887: WARNING: [helpers.i18n] Arguments do not match string read by key ''#system_messages:customization/added/camouflageValue'': (6,)
2019-08-10 10:32:58.910: WARNING: [gui.Scaleform.managers.SoundManager] Sound effect "effects.vehicle_changing" not found

2019-08-10 10:33:28.596: ERROR: [gui.Scaleform.daapi.view.lobby.customization.vehicle_anchors_updater] Vehicle entity is not loaded/exist. 

python.log

4 minutes ago, kupjones said:

Confirmed.  I had to switch between 3 different tanks 4 times before clearing the bug -- and I now see an error that I hadnt seen before (not that I stare at the log files all of the time).  I've attached the python logfile but this error I hadnt seen before:

 

2019-08-10 10:32:52.251: WARNING: [gui.Scaleform.managers.SoundManager] Sound effect "effects.vehicle_changing" not found
2019-08-10 10:32:53.887: WARNING: [helpers.i18n] Arguments do not match string read by key ''#system_messages:customization/added/camouflageValue'': (6,)
2019-08-10 10:32:58.910: WARNING: [gui.Scaleform.managers.SoundManager] Sound effect "effects.vehicle_changing" not found

 

2019-08-10 10:33:28.596: ERROR: [gui.Scaleform.daapi.view.lobby.customization.vehicle_anchors_updater] Vehicle entity is not loaded/exist. 

python.log 27.23 kB · 0 downloads

Sadly, the switching back and forth does not effect a fix for the current game session.  Even after a tank shows up properly, it may revert back to the scene "under the bridge" - and sometimes one can even see a bicyclist ride by!

Duplicate of thread

I just reported the same issue -- sorry, wasnt aware that this one existed.  

well, my log archives were in my other post -- all gone now.

A completely new install of WOT using only Aslain #5.   I've attached log archives of before and after -- a new Aslain load with Customization Manager and an archive where one change was made, removing Customization Manager.   I've also included screenshots of with and without.

I have run cache cleaner - no effect.

I even tried completely deleting the Worldoftanks folder under Appdata and forcing a rebuild -- same result.

Could use Auxilium -- but the unrestrained use of gold to satisfy a camo request was unacceptable (and I assume this is still the case).

I'm willing to try other combinations -- I did already remove all mods except this one but obtained the same result.  I'd hate to think I am missing something obvious -- but I have no idea what it would be.

Aslains_WoT_Logs with Customization Manager.zip Aslains_WoT_Logs without Cuscomization Manager.zip

51 minutes ago, Quaksen said:

You have been told what to do already.

 

Create the folder specified in the error message.

 

It cannot be anymore simple.

Well, it COULD be made simpler --- MUD dude could simply uninstall/re-install WOT.   But then we would probably have to describe each Windoze step.  **sigh**

Yes, it is a minor thing -- just annoying so I thought I would ask.  Now I know -- thanks @Quaksen!

I'm trying to determine what drives the use of the tank icon when looking at a crew member.  I can see that the icons in the folder \res_mods\1.4.1.2\gui\maps\icons\vehicle\contours feeds these, but WOT appears to want to flip the icon around since the same icon is used in two different views, as below.   Is this something we live with or is there somehow that we can tell WOT (maybe via XVM?) that there are 2 sets of icons? 

Shura, you are of course correct.   The rest of us have no idea how things work or even how they are supposed to work -- we defer to the depths of your insights.

Nevertheless, and I really hate to do this  --  You Are Fired.

... and not seeing us as consumers of his product.   Oh well, I tried.

My thoughts exactly  

Feedback from Shura -- there is no problem, only 3 people have complained, no one on the RU server, nothing is wrong with the mod.

1 hour ago, Aslain said:

The mod will be removed in next modpack update, mostly for safety sake of users. It may return in future when it'll be confirmed that the mod is functioning properly.

I have a thread going with Shura over at http://forum.worldoftanks.com/index.php?/topic/517569-mod-auxilium-savelastserver-autoequip-autocrew-autohandbrake-region-changer-and-more/page__st__80#topmost.

Its unfortunate that in this case some of us lost real currency.   But, with mods comes risk and I am willing to own that.

Developers can be rather touchy -- and Shura did respond with (all caps) "   Mod does NOT BUY ANYTHING!"  

The statement is strictly correct -- it is the WOT client making the purchase.  However, I place this into the category of misaligned semantics -- its rather like someone taking my hand, using my finger to enter my debit card pin, then extracting money from my bank account.  Strictly speaking, it WAS my finger that touched the buttons --- but ignores the fact that my hand was being manipulated, not by my person, but by outside influences.   the WOT client is simply doing what it is being told to do.

I do have some issues, however, Shura indicated that if the warehouse didnt have the camo, then the client would go ahead and buy more camo.  But I know when I go into the client I can see quite a bit of free gold camo (I had put camo on my prem tanks) that appears to be available.  yet, Auxilium still would make a purchase.  So I have some questions about the algorithm being used -- but like I said, developers are touchy when questions come from those whom the developer  assumes have no idea what it is like to code.

14 minutes ago, Quaksen said:

When you go to buy camouflage, you are met with a confirmation box.

 

Do you get one, when using the mod? Probably not.......

Precisely.  There is even an option to choose silver in the client, but gold is the top choice, so my assumption is whatever is "auto ok'ing" the purchase is simply taking the first choice. 

It will be interesting to see if Shura can put in place some checks that will determine before hand if there is camo in the "warehouse".

Also, Shura explained the "Gold Lock" and how it functions:

>Also, and asking again, is whether or not the mod honors the "Gold Locker"

The "gold lock" function works in the interface not allowing you to select it.
But if you choose "buy for gold", and then turn on the lock, then auto-completion will use gold.
The purchase procedure takes place on the server side and not the client.

So, I read this to mean "If I already bought something for gold, auto-completion will simply do it again since the server keeps track of these transactions."

I've confirmed with Shura that the WOT client (at the direction of Auxilium) WILL spend your gold on camo if you applied gold camo and try to use the same gold camo among several tanks.  To be clear, and what Shura has said, Auxilium really doesnt "spend your gold" --- Auxilium only tells the client to mount "camouflage Nexx" and if that is not available the client (not Auxilium) will automatically spend gold for a new set of camo's.  Thus, Auxilium has absolutely no way of knowing a priori if gold is going to be spent or not.

I get the behavior and the defense of this functionality -- but to an and user it is a matter of Semantics:  Either I manually approve the spending of Gold (which takes conscious thought and intent) or a program (Auxilium) makes the "decision" for me based upon the misunderstanding of how the mod actually works.

In practice the only fix that we as users can effect is to ONLY use Auxilium to share the free camo that came with the latest update.  Use gold camo only if you are aware of the consequences.