User talk:Flame2512

Hello, i wanted to ask you about radar resolution keybinding. It would seem that there is "change radar scope scale" hotkey for ground vehicles in settings, but it doesn't seem to work on chieftain marksman at all. Although vehicle itself changes resolution by itself from 12 to 10 km whenever i try to track something, and it also seems to make spotting easier in sniper mode (works only in sniper mode), since it changes resolution to 10k briefly, and actually catches things, that it normally misses. Do you know anything interesting about either of those things? I feel like this is a leftover from workaround for Vulcan and SIDAM, but maybe there is a way to change radar's range manually somehow? Seems useful against planes with small signature, or something along those lines. --bangerland (talk) 18:28, 23 April 2019 (UTC)

The chieftain marksman only has one range setting fixed at 12 km (some other SPAA have multiple, i.e. M247 has 10 km, 20 km and 40 km), so the radar range scale key has no effect as there is no other range scale to switch to. As for the other bit, the Marksman uses a combined tracking and search radar, with the radar capable of scanning out to 12 km and tracking out to 10 km. From what I can tell, what is happening is that when the lock key is pressed the radar briefly stops scanning and does a sweep in tracking mode. As once the radar is in tracking mode it's maximum range is only 10 km, so the radar display updates to show this. If no track is established the radar drops back into scanning mode with a max range of 12 km and the indicator range updates. If a lock is established you will notice the the radar stays in tracking mode (antenna not spinning and instead pointing directly at the locked target) and the max range remains at 10 km on the display (both in first and third person) until the track is lost, at which point the radar enters scanning mode with a max range of 12 km. When a lock is established the range display drops down the 10 km in both third and first person, but if it is not the momentary drop in range is only noticeable in first person, not sure why this is. --Flame2512 (talk) 19:41, 23 April 2019 (UTC)

Well, the reason why i even brough this up is, whenever marksman temporarily drops resolution to 10 km (IE just uses it's tracking radar) it scans for planes better. I even checked in test drive - it can't catch Mig 15 bis as it flies by, even when i force search radar to follow the turret, but when i specifically go into sniper mode and look at it, then press lock-on, bam, it locks on and even tracks it for a bit (though often it just does weird jiggle and breaks lock-on instantly). Do other radars lock on better when their search range is reduced like so? I kind of feel weird about all of this, since ingame i barely can lock on on things 4km away, and max range is 10km, lol. Should plane be like TU-4 on it's regular space bombing altitude for this to work? :D --bangerland (talk) 22:08, 23 April 2019 (UTC)

TTX table question

Flame2512, I believe you were working on these tables at one time if so, I have a question for you regarding one I am working on. Here is the code/table:

Test

??

??

?

I-16 type 5

test text

MiG-15bis

test text

I am having issues with the Tree-Unit template boxes, for some reason when they are positioned at the right side (ttx-value spot) of the table, the background grey color does not fully fill out behind the image and name of the aircraft (like it does in the aircraft trees). If the Tree-Unit box is moved to the ttx-name position, it does render the entire background, but centres the image in the table instead of shifting it all the way to the left. I would like the Tree-Unit to be on the right side of the table with the background all grey, not just the 1/6th it currently shows. I can pick apart the current coding, but I don't understand all of the different parameters to make this happen. If you have time to take a look and potentially find a solution, I would appreciate it. Thanks! AN_TRN_26 (talk) 21:50, 11 May 2019 (UTC)

Image seems to resize to text, so applying "bold" style to it fixed the image somehow. Though image is now "above" the text, because it is bigger --bangerland (talk) 00:15, 12 May 2019 (UTC)

That does fix the background, however, I wonder if there is a way to do that without bolding the text, getting the Tree-Unit template seated to the right (not center) and get the "test-text" to be centred on the left of the box. AN_TRN_26 (talk) 00:27, 12 May 2019 (UTC)

As i see engine treats the "images" as part of text, so you may want to look into the command that summons it there, to make it treat it as image somehow, so you can apply "image" formatting commands instead (like, "wrap around text", or "right". Even when you mess around in "visual" mode it just moves them a string up or down,so you can never really center them (as they are relative to eachother). I also don't see there any text editing types in "help" menu that are typical to "office word" or whatever, so i cannot really help you in any way with that. sorry. --bangerland (talk) 00:47, 12 May 2019 (UTC)

Welcome to the weird world of CSS (TL:DR at the bottom). As a quick intro if you haven't heard of CSS: CSS is a language which tells the browser how to correctly display a webpage; ttx-value is a CSS class which contains a list of instructions (in this case: align everything to the right, use non-bold text, etc., etc.). For some reason the Tree-Unit template does not play nice with the ttx-value class, you can prove that by somewhere sticking a tree unit template into a span, it will work, if you then add the ttx-value class to the span it breaks. And while we're at it, what bangerland did does bold the text, but not for the reason you would think. When bangerland applied wikitext formatting inside the class attribute all he actually did was change the class name from ttx-value to '''ttx-value''' there is no CSS class with that name, so it has the same effect as the class attribute not being there at all (indeed you test this this by deleting it on the one I left). As there is no ttx-value class assigned to it anymore it looses the instructions such as "align to the right" so appears in the wrong place. As for the bold text that appears because the template (and everything else in the table) are inside a div with the ttx class assigned, which states all text inside the div should be bold (among many other things), the ttx-value class tells the text to not be bold to counter this.

So how do we fix this? We know that the ttx-value class breaks the background on the Tree-Unit template, and as bangerland demonstrated removing that class fixes the background but causes other issues. You can apply CSS instructions without using classes, by using the style attribute, so the solution I found was to just right align the template to the right and set the text to not bold using in-line CSS instructions rather than using the class. As it happens the class does a few other things, but we can get the desired effect without including them. Interestingly you can apply all the instructions from the ttx-value class using in-line CSS just fine, this is likely some oddity of CSS to do with what order the rules get applied in depending on how you specify them (the wiki has a lot of CSS going on, so something is probably conflicting somewhere). I haven't included the other information from the ttx-value class as in-line CSS because it gets messy and we can achieve the desired effect without it. Keep on using the ttx-value method for everything other than this application though as it is best practice to do so, and my method here may have unexpected side effects if used for anything other than making the tree-unit template work.

TL:DR CSS was being weird, I fixed one of the templates so you can easily see what I changed compared to the other one in order to do so, it works for the purpose of making the template work but carry on using the normal method for everything else. --Flame2512 (talk) 08:29, 12 May 2019 (UTC)

Wasn't aware of this, since i'm unfamiliar with commands for wiki or websites in general. So it is possible to apply certain style manually to this instead of ordering it to treat it in certain way (hence, class)? At least that's what i gather from this. I wouldn't figure out real reason behind this anyhow, because when i specifically applied random symbols and numbers to class name to specifically break it, it didn't affect it. All is well that ends well, i guess. --bangerland (talk) 11:03, 12 May 2019 (UTC)

Mediawiki lets you insert HTML code to build your pages, as a result you can use the style attribute inside the HTML tag to apply CSS to the contents of that tag. This site is pretty good for learning HTML and CSS. I would advise against using too much inline css though because it will make the page code get messy quick.

The wiki has what is known as an external style sheet (well it has a couple but that's beside the point). The stylesheet contains a list of classes, with each class containing CSS code, when you assign the class to a html element it tells your browser to format it according to the code in that class. For instance the ttx-value class says to align all items and text to the right, says to use normal text (not bold), sets up a 5 pixel margin on the left edge and specifies a max length before a new line is started.

This is a good intro to the basic concept of CSS, on the left is the HTML code and on the right is the website. In the heading tag (the line starting "<h1") there is a style attribute and inside the quotes is CSS code. The HTML code tells the browser this is a heading while the CSS code tells the browser you should display the text as blue with a 30 pixel margin. You can change the colour specified in the CSS to "red" for example, and if you click the run button you will see the web page updates and the text is now red. That works fine for basic websites but if you want say nearly every heading to be red and have a whole bunch of other formatting you would write your HTML code in a class and then assign that class to each heading. When the browser sees a heading with a class assigned to it, it looks at the code in the class and treats it as if it was in the style attribute. That way you don't have to type out the same code over and over again and it keeps the code looking much neater. This is of course only a very simple explanation of what is going on.

That is an awesome explanation, finally someone pinpoints to me a language that is being used and why it's doing what it's doing. I have 0% CSS experience (I've looked at it, just never pursued it) so I guess that is why I didn't recognize it, time to learn! The information you provided makes more sense now on how/why the Specs|card code page works the way it does. I could look at that stuff and get an idea of what it's doing, but now that I know its CSS, I can actually learn CSS and understand exactely what it's doing. I have used w3schools for Java and Python, but not for CSS yet. Definitely would like to learn to balance the code on the pages to get the effect desired without having something it be messy and unruly! Awesome, thanks again for the explanation! AN_TRN_26 (talk) 22:14, 12 May 2019 (UTC)

CSS is a fairly simple concept but it can get a bit weird at times (as we've seen). There are some complex rules to do with which CSS take precedence. In that table we have the Tree-Unit template which consists of about 3 different components each with CSS attached, that is then inside a table line which has its own CSS (the "ttx-value" class), which is turn inside a table with its own CSS (the "ttx" class), so you end up with a load of different CSS rules for the browser to work out what to do with and what order to apply them in; presumably a few rules were interacting in ways which were unintended (whoever wrote the code for the wiki intended for the ttx class to only be used for vehicle stat cards and the tree-unit template to be used on tech trees so would have no reason to see what happens if you stick on inside the other). You can google the CSS order of precedence, but generally inline CSS is nearly at the top so you can overrule classes and stuff, and sort of say "ignore the other stuff, do this". Like I say best to only use inline CSS where necessary though and stick to using Gaijin's classes where possible; no one wants wiki pages full of: <div style="width: 300px;float: right;margin-left: 10px;margin-bottom: 15px;border: solid 1px #B0BEC5;background: #EEEEEE;color: #323246;font-weight: bold;line-height: 1.4em;"> (as an example that is what <div class="ttx"> would look like if you wrote it using inline CSS instead of calling a class, all that code is in the wiki's stylesheet and is loaded by the browser when you call the ttx class).

I found the CSS page here on the wiki which breaks down each of the classes (I believe that is what they are called) and can see what the parameter each one is calling for. That helps me understand better what is going on and what the limits of each one are for. Definitely not going to add any without first letting the wiki developers first take a look at it, however for now for what I need everything is there! Definitely will be looking at the order of precedence and such to see what else I can glean and use. AN_TRN_26 (talk) 23:08, 13 May 2019 (UTC)

I think I know the page your refering to. I'm pretty certain that is just a page where the Devs have documented the CSS which is being used. Unless mediawiki has some weird feature letting you pull in CSS stored on a wiki page (seems unlikely) the CSS is usually stored in a .css file on the server somewhere, and only editable if you log into the server and edit / replace the file. I don't see any reason you would really need to change anything there anyway, the ttx class we use for sidebars is rather comprehensive, and most other can be achieved with wikitables / markup. It is definitely interesting to read through the CSS though, at the very least it can help you work out why stuff does what it does.

I'm pretty sure Mediawiki:common.css is where it is stored. The manual here: https://www.mediawiki.org/wiki/Manual:Interface/Stylesheets says it should be applied globally.--blastedryan (talk) 17:55, 14 May 2019 (UTC)

Looking more into this, I believe blastedryan is correct. The page is protected at the administrator level, so I don't even have permissions to make adjustments, there are only about five people who do and they are all above my level here. AN_TRN_26 (talk) 18:07, 14 May 2019 (UTC)

New map format - A comment to omit

Hello Flame2512,

In your updated map templates, one of my suggestions during your drafting of the template still remains in the "strategy" section.

''Describe what focus a team should have when spawning into the map (Seems dependent on spawn zones and map sizes - recommend delete section and instead focus this description on game mode map designs?)''

It is not meant to be part of the actual section description, so please remove it in future updates.--Inceptor57 (talk) 01:26, 15 May 2019 (UTC)

Will do

Night Vision Devices tables and information

I have thrown together some WIP tables for use on vehicle pages to show the night vision capabilities (see bottom of my user page). I am working on an article to fully explain how night vision works (including an explanation of the information in the tables, and how it affects gameplay). Discuss any suggestions / feedback you have under this section.

Things I am looking at doing:

• Combining the two night vision tables together, and possibly joining them with the Optics table as well - Need to find a suitable layout
• Adding mouse-over text to briefly explain what the information means (like the tables on my radar pages) - Will probably do this, but another time (getting late now)
• Working out if helicopters require a different table layout

--Flame2512 (talk) 20:52, 18 September 2019 (UTC)

I like the looks of the tables you have created. With the optics table, is it necessary to have the sortable columns? Will there be more lines which can be added which would make sorting a practical option? In regards to the mouseovers, while I think they are helpful, I think too many can clutter up the table (this is just my thinking). Bangerland created a section with images viewed through the different optics, will you be doing something similar with your article to show the different NVD views and their differences too? I look forward to seeing your article. -AN_TRN_26 (talk) 22:04, 18 September 2019 (UTC)

I agree that the table being sort-able feels a bit unnecessary, I just copy-pasted the one currently in use (I had no role in creating it). In the article I plan to have images showing the difference between hi and low res devices and different light multipliers; also probably different search lights. --Flame2512 (talk) 18:33, 19 September 2019 (UTC)

I'd like to try to help with nightvision, but problem is, when i actually unlocked it on one of my tanks, i failed to make it work. I did set keys in my keybindings, but it just didn't work, IDK why. So i can't really be of any use in this regard, at least not until i figure how to use it on ground vehicles in arcade (i'd personally use them even during daytime, just to make aiming easier.). Sorry. I'll try to unlock it on some other vehicles to see if it's just specifically that one tank, or just me. As for tables, they seem nice, but references will be required to give an idea of what it looks like. I also could swear that i read somewhere that NVD can be used in 3PV, but i cannot find the text about it anywhere?... Am i mistaken?.. uh. --bangerland (talk) 01:01, 19 September 2019 (UTC)

Image enhancers (traditional night vision) can only be used at night, thermal imagers can be used at day and night. Whatever night vision solution the commander has (IIRC they only get image enhancers) can be used in third person and binoculars. --Flame2512 (talk) 18:33, 19 September 2019 (UTC)

Ok, so NVD does not work in test drive whatsoever and is a bit glitchy in game itself. By that, i mean, that when you shift between scopes it can leave thermal scope on even in 3pv for a moment. Also, it does not see through smoke screens at all (those appear to be about as bright as the sun, lol), in case if anyone was wondering. Extremely limited use in arcade for many tanks, as i can see. There is no technical mentioning of specs for these anywhere i can look at, so i'll need either a visual example of brightness and resolution differences (preferably 1920X1080 game output res) to fill out information for them. --bangerland (talk) 00:49, 20 September 2019 (UTC)

If you want to slap optics and NVD together, easiest way would be just to put "Optics"(with link) on top and "magnification" on left of "image intensifier", and whatever NVD stuff under their own title "night vision support" or something. Commander sight on tanks is always X6 (since bino is static between all tanks), gunner sight is variable and can be shrunk to "X5-X12" or two separate cells as right now (though "comparable with" section will have to go and mag is left simply to be entrusted on whoever writes about it), driver sight, i didn't ever check, but probably X1 (don't quote me on that)? Adding IR flashlight to that table seems improbable, though, as it is a separate thing, kind of? Or notes section must be removed, but since Thermal can replace normal NVD notes are necessary... So, RIP that idea. --bangerland (talk) 01:01, 19 September 2019 (UTC)

There, lazy attempt at merging optics and nvd. Actually took original optics table, which specified which optics had what zoom (very redundant, but whatever. Also, i forgot how to remove color tint from colums, so forget me for that one.). Can put NVD as part of optics page (a link would then lead to the specific section, that explains them specifically) or to a separate NVD page, whichever suits your goal better. --bangerland (talk) 01:18, 19 September 2019 (UTC)

{{PAGENAME}} Optics
Type of optic	Magnification	Night Vision Devices
		Image Intensifier			Thermal Imager Resolution	Notes
		Resolution	Light Mult	Noise Level
Gunner's Sight	X3.6 - X12	1600 x 1200	9.0	High	500 x 300	Thermal sight is a rank 4 mod, it replaces the image intensifier (rank 3 mod)
Commander's View	X6	1600 x 1200	9.0	High	Not Fitted	Image intensifier is a rank 3 mod
Driver's View	X1	1600 x 1200	5.0	High	Not Fitted	Image intensifier is a rank 3 mod

Good start on the table layout I tweaked the formatting of the magnification cells. I think that whatever table layout is decided should be moved under its own sub heading (something like "Optics / Night Vision"?)in the vehicle pages, instead of being under the main armament heading; you could also have a bit of text above it saying if the optics are good and giving any comparisons if you want. I'll do a bit of testing and see if there is any other information which should be added to the tables, and have a bit of a think about the searchlights table. --Flame2512 (talk) 18:33, 19 September 2019 (UTC)

The table is looking nice and clean, I like the direction it is going. --AN_TRN_26 (talk) 22:56, 19 September 2019 (UTC)

Well, the page layout is not for me to judge. Kind of inserted those tables in gun section and nobody objected, so that's how it went. Some of them already need updating due to patch notes, but that can wait until we finalize the looks of new one. Should we add "/3PV" to "commander view" magnification, just because it uses it's NVD? I can't seem to use gunner's thermal outside of sniper scope for longer than 1 second, so it's busted. --bangerland (talk) 00:49, 20 September 2019 (UTC)

• What does the noise level represent (I don't play tanks, so I have not unlocked any NVD yet)? Is it the pixelation of the image due to the thermal/infrared qualities of the image? If so, is there some sort of scale that can be created (maybe for the main page) which affixes a number or ratio that will help quantify the level other than low/med/high? I guess when I hear high I think blown out image, barely enough to make out any usable detail or barely usable. Just a thought. --AN_TRN_26 (talk) 23:22, 20 September 2019 (UTC)

On the Night Vision Devices page take a look at the two images under the Noise heading (may need to view the image in full screen), it basically determines how much static you see on the screen. If you dig through vehicle files then there is a property called "noiseFactor", at present for all the tanks in game that value is either set to 0.2 (the "high" image) or 0.05 / 0.04 (the low image), some helicopters also have 0.15. As effectively there are only two / three possible values at the moment (the difference between 0.05 and 0.04 is very small) I thought that low / med / high would be clearer for people, than posting an obscure number and trying to explain the significance of it. By comparison "Light mult" can be anything between 5 and 10 currently, so a number makes a bit more sense to me. Personally it also seems like a bit more of an intuitive number than the noise factor. I'm open to discussion on this point though.

• No problem, I wrote this before seeing the page you started. I was thinking there might be a different scale (more gradients) than just the three. I work with thermal imagers and some especially FLIR have very low noise and others which are made by the same company overseas which makes McDonald's toys tend to be a bit more grainier and have a higher amount of noise injected. TBH, between the images here to me there isn't that much of a noise difference and I would be happy with the "high noise" image any day at work. I guess I was expecting the high noise image to be almost washed out. I don't think that many people will dig through the vehicle files so staying with low/med/high should work, unless later on Gaijin makes an update to the NVD.

That sounds cool, I've been able to play with some cool stuff at work, but not found an excuse to use thermal imaging yet. Yeah Gaijin's implementation of Image Intensifier noise at the moment seems to be that you either have some slight graininess going on, or it is pretty much completely clear. --Flame2512 (talk) 20:54, 21 September 2019 (UTC)

• I have approved the two pages and have notified the other moderators/administrators to have a look and provide feedback, might take a day or two for people to see it with it being the weekend, I think it looks good though. -AN_TRN_26 (talk) 23:53, 27 September 2019 (UTC)

• Not sure if noise difference is very apparent with tanks that are now in the game, but resolution difference during day on thermal scope is actually considerable. I tried to use of the early ones during the day on winter map, felt almost like driving through twilight zone. Though until I get more tanks with NVD I can't judge if they are different or not. --bangerland (talk) 08:56, 4 October 2019 (UTC)

• The difference in noise applies to image intensifiers, the vast majority have high noise which is the slight graininess you can see with them on, the few with low noise are pretty much perfectly clear. I agree with thermals, I got the warrior thermals, and yeah it is incredibly noticeable on some maps, I think I will update the picture to better show that. --Flame2512 (talk) 09:33, 4 October 2019 (UTC)

• kind of resetting the conversation, for a separate question. There are 3 tanks with commander thermal scope (leo 2v5, leclerc and that type 16 i believe?). Do they have Thermal in 3PV? If not then 3PV is driver seat only, if they do, then commander view overrides driver whenever it is present. Would be nice to know to plaster 3PV sign in proper slot for tanks. --bangerland (talk) 22:55, 20 October 2019 (UTC)

• Don't own any of them myself so can't say for sure. Going off YouTube videos it looks like they have regular night vision in third person. --Flame2512 (talk) 21:18, 21 October 2019 (UTC)

• Well, i guess i'll have to just autoassume that 3PV is driver view then, at least until i unlock type 16 for myself, which will take an eternity. Only unlocked 75 SPH recently and barely touched rank VI. If you'll hear anything about that though, drop me a memo, please. --bangerland (talk) 06:59, 22 October 2019 (UTC)

CDK Documentation

Hey Flame! Thanks for going back on my revision of the Triggers article! I've just started getting into the CDK and wasn't sure if someone else was already trying to address the cruel lack of documentation (no wonder there is very few user content, the dagor editor is the most unintuitive, inconvenient and limited i've ever seen, and on top of that it's not even documented...)

I only have a few days of experience with the mission editor, very far from your years of experience, so i'm not sure what are the areas you already know and plan to document (so i can avoid making changes conflicting with yours)

--Pwa_ (talk) 11:41, 4 October 2019 (UTC)

You made a good contribution, even had some stuff worked out which I didn't know in my version. The Dagor editor does lack documentation, but between the two video tutorials and the Mission Editor guide there is enough to get started. The two articles I've written so far are the CSV files for missions and Triggers articles. There is a (not exactly large) community of experienced CDK people, but not many people are interested in documenting stuff publicly (I can see why, it's often a bit tedious and not the most rewarding activity). In terms of what I'm planning on doing, I am trying to put together an article on how to make a multiplayer user mission, but other stuff keeps taking priority. I was working through the list of trigger actions in order, but again that was going slowly mainly due to lack of motivation; unless I know exactly what it does from experience I like to test out each action before documenting it, so it was taking a long time. --Flame2512 (talk) 19:04, 4 October 2019 (UTC)

Excellent! I'm also going to test out actions to see how each works exactly, and try to create reference pages for fields that require IDs (such as keybinds). Pwa_ (talk) --06:56, 5 October 2019 (UTC)

Regarding the optics table

I suppose you managed to reverse engineer the files that we were talking about forever ago? If we want to simplify this, the numbers can be rounded. I think the minimal zooms that didn't go past *.35 can be rounded down, the .4 to .7 probably should be brought to .5 (french and soviet tanks mostly, some GE tanks) and .75+ rounded up, at least from what i see and comparing to what i tested, then it can be pretty much copy-pasted with minimal error, at least comparing to what i already looked at. If you aren't in the mood for it, i'll just do it manually later. --bangerland (talk) 18:55, 22 October 2019 (UTC)

I think most of this list is mostly legit after rounding, compared to all i had and some X-rays it all matches, although X12-13 is a bit strange, but my testing conditions were far from perfect to be honest, so i might have just estimated it wrong. Also lol the Foch optics are abysmal. Poor french. Thanks for the work. --bangerland (talk) 19:11, 22 October 2019 (UTC)

Yeah I ended up writing a program to pull in some data from the files then do some (more complex than originally thought) maths to get the magnifications. I think for rounding just take it to the closest "clean" looking number e.g. 1.85 - 3.52 rounds to 1.85 - 3.5, 2.49 - 5.03 rounds to 2.5 - 5.0, 5.69 - 8.22 rounds to 5.7 - 8.2, 8.92 - 10.14 rounds to either 8.9 - 10.1 or 8.9 - 10.15, etc. I will say it is interesting sorting the table by zoom low to high. --Flame2512 (talk) 20:41, 22 October 2019 (UTC)

I think the only uneven magnification on X-ray i saw was 5.6 on BMP-2 and 16.01 or something on otomatic. Well, i'll see how it goes. I dunno, if we could also compare them by BR and class at the same time it would be fire (to see what faction has upper hand and in what), but since BR changes a lot we can only realistically use rank, which is a bit too broad in my opinion. --bangerland (talk) 22:04, 22 October 2019 (UTC)

Seems to me like the zoom is a simple truncation to 1 decimal place.--blastedryan (talk) 05:07, 23 October 2019 (UTC)

Truncation is cutting off everything to the right without concern, correct? It would contradict X-rays a lot in cases of .49 and such. I will attempt to test various ~6.0 and ~6.2 zooms in the evening to see if they really are different in any way (unfortunately no 4k screen so i might have to resort to pixel-perfect compass comparsion or something). If they are different, then it's just rounding to 1 decimal and taking them all as legit, if not then it's complicated, because Stormer HVM and many ATGM tanks calculated stats are off by 0.7 from X-ray and what i consider real. --bangerland (talk) 07:09, 23 October 2019 (UTC)

Yeah. I was getting a bit hung up on the .05's that were getting rounded down. It might just be because the numbers are already being rounded to 2 decimal places. Flame can you rerun the exact numbers and round to 1 decimal place?--blastedryan (talk) 12:03, 23 October 2019 (UTC)

Results of tests: Hori VS type60ATM X6-6.2 zoom, compass is different by 1 mm and picture does look slightly closer in type 60 atm (might as well be difference in height, but whatever). Retest with challengers VS chieftain on X7-7.25: In chieftain scope trees and bushes seem closer and again compass seems to be wider (i think it's not affected by lenses themselves so it stays true?), and in this case the tanks are near identical in height. I suppose this confirms that the datamined zooms are actually more correct than X-ray, despite looking weird. I would still round them to 1 decimal just to make it look more clean where applicable. After that and ironing out standard with mods we can just dump it everywhere, i guess. --bangerland (talk) 16:44, 23 October 2019 (UTC)