Tippis
-
Posts
2797 -
Joined
-
Last visited
-
Days Won
9
Content Type
Profiles
Forums
Events
Posts posted by Tippis
-
-
If you don't have one, you can just create it. Preferably, use a proper editor like Notepad++ rather than regular notepad.
If your %USERPROFILE%\Saved Games\DCS\Config, directory (or equivalent working directory you select via the command line) create a new file called autoexec.cfg. Make sure it is actually named that and that Windows or your editor isn't hiding the true extension (hence why regular notepad is not a good option — it loves to make it .txt no matter how much you protest).
From my testing so far, the file Special K offers in this post is sufficient and can even be pared down further. Basically, if you have no other settings and it's newly created, it should contain
if not net then net = {} end net.allow_unsafe_api = { "userhooks" } net.allow_dostring_in = { "server" }This has worked for my setup and use case, but we don't use the full set of slmod functions — it's entirely possible that some other functionality is lost with just this. Similarly, you might be using other server mods that require other context to be allowed, but you're going to have to ask around to figure out which ones are needed for which mods.
-
1
-
1
-
-
On 7/26/2025 at 2:20 PM, Special K said:
He? I don't think you're understanding the change mate.
They are quite easy to understand and you have described it fully.
On 7/26/2025 at 2:20 PM, Special K said:I told people to NOT open up everything but to create a file which works for their solution. I provided one which opens the minimum
…which is still more than it should be and which creates insecurities that didn't exist and shouldn't exist. It's that simple. This is a bad solution, implemented hastily with no warning and seemingly no testing of value. The number of things it breaks for no gain is ridiculous. The workarounds create bigger problems than what initially existed and does the exact opposite of what was intended with this whole idea. Hell, even the OP gives a big red warning sign.
The reason I say that you didn't do any testing is because you've managed to break SLmod for a number of people — probably other common and crucial mods that are used all over the place. This should have been an immediate discovery and show-stopper.
On 7/26/2025 at 2:20 PM, Special K said:But if you know it better, I'm all ears how you would go with the scripts that use net.dostring_in() now.
I would suggest a two-step process:
- Hotfix-patch rollback.
- Do any of the things cfrag has suggested. Or see two posts above.
This may seem drastic and contrary to how ED does anything, but trust me, the alterative is much much worse. That alternative would require them to, first thing tomorrow morning…
- At the top of the forums, the DCS website, the launcher, in the game main menu, and on every reddit, discord, and My Little Pony Online chatroom where they have any kind of social media presence, put out a warning sign in huge blinking letters that they have changed the security model in such a way that users may now be tricked into allowing remote code execution.
- In a very public post — not hidden away in this obscure “mission editor” corner of a forum that not many visit to begin with — document, in full, what the function does, how the different scopes work and what they affect, and under what circumstances each scope might allow for ACE.
- List and publicly endorse the minimalist exception rules for the 12 most common scenarios where you might want to allow dostring_in to work, from an end user perspective (eg if you want to use some of the products ED sells, or use userfiles of some kind), from a server perspective (how do you still allow common server mods to function, what are the caveats, how does it minimalisticly mesh with eg. shared moderation roles), from a coder perspective (what are the most common uses, what do these require in terms of exceptions, what are other more secure ways of doing the same thing). 36 cases in total, full documentation, full transparency of where, when, and how code (and in particular remote code) can be executed.
- Determine and clearly communicate which scopes and combinations should pretty much never be used because of what they open up. And in doing so, maybe just not allow that to begin with. Again, anything that creeps towards “remote…” should probably be stomped hard.
- Implement some kind of code signing so the end user can differentiate between trusted developers and random junk they find on the intenet. Congratulations, you are now Microsoft. Oh, it's just text files and there is no way to sign those…? You don't say… It's almost as if it has caused new problems.
- Implement a security tab in the game settings where this and related settings are made. Too many things are affected by this to just leave it as an obscure text file code injection — that just leaves option the ability to trick people into putting harmful code in there.
- If kept, the model need to be extended to not just be “these scopes are allowed use; these scopes are allowed access” but rather make it a proper model where you can decide, scope by scope, what is allowed. A full set of access control lists — congratulations, you're Microsoft again. This, once more, requires something a lot more complex than can be safely relegated to code in a cfg file. Rather, in the Security tab, these options can be explained to the user and particularly bad combinations can trigger warnings our outright blocks (here, at this level, is where it might be appropriate to allow overrides via cfg file edits).
All that to make sure we don't get a slew of malicious code out there, combined with malicious suggestions for “solutions” that leave the client wide open.
Again, the problem here, as others have mentioned, is that users will just be faced with an error box and go search for the first available solution. This will not be your clean three-line autoexec addition, but rather something far more malicious. ED's official answer and suggestion needs to be the first hit on every search engine, and anything that deviates from that should come with a huge warning that the player will notice. The information campaign needed to combat malicious use of this new security hole is immense. Let's just be kind and say that huge information campaigns are… not ED's forte.
-
10
-
1
-
8 hours ago, Special K said:
You don't need to fix anything in your scripts. People that use it just need to amend their autoexec.cfg like people need to amend MissionScripting.lua since ages already. As said I have provided one in here, costs you 2 mins to share it.
Your solution is unsafe and does the exact opposite of what this change is meant to accomplish.
-
7
-
2
-
-
On 2/14/2025 at 11:47 AM, LeCuvier said:
I totally agree, ED should add all the bindings available in the "default.lua" to the files for the MFD's.
But I don't expect ED to make the change.
We'll see. I've given them my files, but I suspect others have as well.
For anyone interested, they are here: A-10C_MFDs.zip and A-10C_2_MFDs.zip for the A-10C and A-10C II respectively. Use your favourite mod manager to plonk them into the module's Input/Joystick directory and everything is opened up.
-
2
-
-
On 2/14/2025 at 12:56 AM, Yurgon said:
I see, good point! I've filed an internal wishlist report.
I can do you one better.
These are the files needed for the A-10C, cleaned up and modded to include all the relevant inputs (so no axes and no FFB): A-10C_MFDs.zip
…and these are the same files for the A-10C II: A-10C_2_MFDs.zipThey just need to replace the existing ones in the modules' input/joystick directories, and will retain the same default binds while opening up all other controls to be bound as well.
-
1
-
-
Just noticed this old thing while doing the rounds as well, and this is the same problem.
For various reasons, this ancient annoyance just popped up for me and I feel it needs to be addressed at some point.
The problem is that the A-10C module comes with a pre-defined bind template specifically for the MFDs, and this template blocks out all other bind capabilities. No other functions are available to be bound and the UI reflects this by greying out binds that do not specifically match the button config.
A “left” Cougar MFD can only ever be bound to left-MFD fuctions. A “right” Cougar MFD can only ever be bound to right-MFD functions. No other binds are available because the module hasn't defined them for these input devices. If, like many do after the Hornet and Mudhen came out, run with triple or quad MFDs, the A-10C module still only sees those as 2x Left MFD and 2x Right MFD, and all those extra buttons can't be used.
This can be bodged by hard-modding the module and adding all other binds to the templates, but of course, this gets wiped by every update and require a mod manager to maintain (not to mention that if you're not careful, your “incorrect” binds will be wiped as well).
This is a long-standing error in how the module has been made to match specific input hardware, but done in a uselessly restrictive way so that you are not allowed to use that special-supported hardware in any other way than what the module programmers imagined. It is actually pretty trivial to fix — just about every other module that detects and default-binds the MFDs can handle it just fine so it's already a solved problem. ED just needs to do it for the A-10C as well.
-
On 10/8/2024 at 4:04 PM, Yurgon said:
I use two of those MFD frames and they keep working fine here.
I'd suggest you
a) run a DCS repair
b) rename your entire folder Saved Games\DCS and try with a bare minimum config
Does either of these steps solve the issue?
That is not the problem.
The problem is that the A-10C module comes with a pre-defined bind template specifically for the MFDs, and this template blocks out all other bind capabilities. No other functions are available to be bound and the UI reflects this by greying out binds that do not specifically match the button config.
A “left” Cougar MFD can only ever be bound to left-MFD fuctions. A “right” Cougar MFD can only ever be bound to right-MFD functions. No other binds are available because the module hasn't defined them for these input devices. If, like many do after the Hornet and Mudhen came out, run with triple or quad MFDs, the A-10C module still only sees those as 2x Left MFD and 2x Right MFD, and all those extra buttons can't be used.
This can be bodged by hard-modding the module and adding all other binds to the templates, but of course, this gets wiped by every update and require a mod manager to maintain (not to mention that if you're not careful, your “incorrect” binds will be wiped as well).
This is a long-standing error in how the module has been made to match specific input hardware, but done in a uselessly restrictive way so that you are not allowed to use that special-supported hardware in any other way than what the module programmers imagined. It is actually pretty trivial to fix — just about every other module that detects and default-binds the MFDs can handle it just fine so it's already a solved problem. ED just needs to do it for the A-10C as well.
-
2
-
-
8 hours ago, SharpeXB said:
Yeah but at this stage they’re just simplistic in the extreme. They’re just dot labels.
They are very obviously not dot labels and they can already do the thing you claim they can't.
The problem is that you don't understand what the various dots we have are, what they represent, or how they work. Nor do you understand how monitors work. It's these technical details that keep tripping you up when you say that the system you claim you wanted but then didn't but then it was fine but then it wasn't doesn't work like you want to. It's because you keep wanting new things, and none of them actually relate to the issue at hand, and none of the arise from any of the technical aspects you complain about. And you always complain. You never offer any kind of constructive input or… you know… feedback.
The only constant has been that you are deathly afraid of some hypothetical advantage that someone might gain over you in a vanishingly small and utterly irrelevant PvP scenario, which itself goes counter to your previous claim about how everything was absolutely fine in PvP because of the advantages you gained over others.
8 hours ago, SharpeXB said:Providing feedback, which is what this topic is all about.
You're not providing feedback, though. To do that, you'd have to know what on earth you're talking about and at no point in the entire history of spotting discussion in DCS has anything you've said every been even remotely related to reality. Every single claim you've ever made has been uninformed and objectively, factually wrong.
You refuse to do the research.
You refuse to learn how anything works.
You refuse to actually use reality rather than your own imagination, and you always end up proving your own point wrong.That is not feedback. That is just plain old trolling.
-
2
-
2
-
-
5 minutes ago, draconus said:
Your blind faith in the old tech that doesn't fix anything as "the only solution" is interesting too.
It fixes exactly what it is supposed to fix, and while the original is old:ish, it's still aeons ahead of the even more antiquated system DCS is trying to use and iterate on. That system has been abandoned by everyone for very good reasons.
If you can come up with something more feasible and easy to implement, please elaborate.
The fact that you call this "the only solution" in response to a post that explains that it isn't is interesting too...
-
2
-
-
1 minute ago, draconus said:
tldr, maybe you need, not DCS.
DCS needs it too if it wants to be a good simulation of air combat.
Your dislike for proven systems that solve this whole problem is not sufficient reason to keep DCS in the dark ages.
-
2
-
-
1 hour ago, SharpeXB said:
This new feature has only been around for about a year. What did people do before this?
They exploited the old system.
You know this because you were one of them, and your screenshots of the excessive visual range some people could get out of the system where others didn't was a crucial part in nailing shut the coffin on that system. Ironically - as always - because you tried to argue that this excessive visibility meant the system was working fine and actually people just needed to git gud. The fact that you could see things that far out and that this was obviously nonsensical and unfair just didn't hit home for some reason... that we can all guess.
Then you realised that the same system could be exploited to your disadvantage, and suddenly it was the worst thing ever and you campaigned hard to have it changed. Remember that?
33 minutes ago, SharpeXB said:Auto at least prevents the easy exploit in the above example.
It really doesn't, but not for the reason you want to suggest. It doesn't prevent "the easy exploit" because your imaginary exploit doesn't actually exist. So there is nothing for the setting to prevent. Quite simple, really, and as such you will undoubtedly not be able to grasp what is happening.
33 minutes ago, SharpeXB said:Yes but as it turned out this didn’t work as well or as easily as was assumed.
Actually, it did. That was why it was so popular and why even "serious" servers concerned about game fairness and integrity would shut off IC to make sure it was still possible to use. The problem we have now is that only the basic concept of that mod was integrated into the game, but they skipped over any of the tweaking that had done with it and instead started from scratch. To be fair to ED, though, they kind of had to because of how it now integrated in the actual rendering loop.
33 minutes ago, SharpeXB said:This topic seemed to be really dormant for a long time following the Model Enlargement mess.
No, it wasn't.
You know this because you were consistently part of the topic, trying to shut down any conversation that threatened the new system and your ability to exploit it. It's pretty trivial to dig up the 8+ year-long thread of Why485 and others trying to explain basic graphics and gameplay to you, starting with how and why the impostor system didn't work and how and why the new dots were only barely better.
The topic wasn't dormant. It was just not going your way at any time and you desperately tied to shut down the conversation. That obviously didn't work because here we are. You're still not getting your excessive-visibility exploit back, and if it turns out that one of the settings re-enable it, guess what will happen? That setting will be banned from MP if not outright removed from the game. So be careful (once again) what you wish for.
-
4
-
-
8 hours ago, draconus said:
No. The vision is on the player.
The player isn't in the game.
The virtual pilot is.You cannot simulate the player. You must simulate the pilot.
This isn't about what the player sees — that's indeed on them — but about what the pilot sees that should be offered up to the player for them to notice or not. The game must offer up a realistic selection of details of the game world that matches what a pilot would* see in that situation. That may (hint: will) involve excluding details that the player might spot because the detail level our display systems are capable of exceeds what the pilot's vision can handle (eg. distant targets, or just very small ones). It may also include adding details the pilot would not see IRL, at least not in that particular manner, but which need to be conveyed to the player to give them cues the pilot would have but which can't be displayed properly on our systems (eg. glint, fine-grained parallax, proper contrast against the background). That last part also includes countering the effects varying FoV and display resolutions.
You seem to be confused what I'm promoting here, and what part of the problem I'm trying to address.
It's not about using in-game tricks to compensate for the player not seeing things — it's about using making sure that, when the player does or doesn't see something, it's on them, and not because the game isn't showing them the right thing.* “Might” is probably the better modality here, veers into issues of what should be filtered and what should be left out. If we're going to do the thing where we rely on the player to spot or miss things, we need to interpret it as “everything the pilot could possibly see”, under the assumption that the pilot is at all times looking in every conceivable direction the player could look at. This is not how the pilot sees the world — they're only looking at one thing at a time, after all — but it is how we must render that world to give the player the ability to look at whatever they want to look at.
It's not that the player should be given perfect information. Quite the opposite. It's that the player should be given accurate information that they can then succeed or fail to process and make use of. To create this accurate information, the pilot must be part of the simulation, same as how we simulate the plane to give the player an accurate behaviour of that horrid lump of metal, except this simulation must extend to the entire drawn field of view rather than just the focal point in the middle. We must simulate what the pilot could see so we know what they player must not be allowed to see as well as what the player must be given a chance to see.
Hence why we need dots — so we can filter out long-range targets and not show them to the player even though the display system can draw them. You may not like it, but it's the only way to combat pop-in at higher resolutions.
Hence why we need scaling — so we can cue aspect changes and show them to the player even though the pilot would not see targets vary in size like that. You may not like it, but it's the only way to convey the proper cues on conventional current hardware.8 hours ago, draconus said:If you can't spot the targets use available options in the game.
That only works if the game and its options create a situation where targets are “correctly spottable” (for the lack of a better description) and can be sensibly adjusted to begin with. They never have been in DCS for various technical and political reasons. Part of that is the insistence on showing naive geometry and trigonometry to draw targets way outside of what the in-game pilot should be able to pick up and showing them to the player as if it was the most natural thing in the world to have targets show up at 40nm+ ranges, and using very simplistic cues that flicker on and off to make targets disappear and/or reappear when they shouldn't. Or to oscillate between the two states to make them show up like pixel fireworks when they should be barely noticeable.
Some of those are just bugs that need to be fixed. Some are missing settings, so you can't actually do what you're suggesting. And some of those shouldn't be adjustable and just be part of the core simulation. To fix this, the rendering of contacts need to be made realistic, and potentially new options need to be added to tweak that rendering in line with all your other local settings.
1 hour ago, SharpeXB said:Simply enforcing Auto mode prevents the easy exploit above.
FFS, this is a new level of astonishing achievement in ignorance, even for you.
You are complaining about a problem that doesn't exist because its supposed downside has already been solved, and you are calling it an exploit that some people don't care to use this setting?! GTFO.
2 minutes ago, SharpeXB said:What I’m curious about is these dynamic war servers that depend on people playing roles like flying support helicopters and ground attack etc. What happens when they see nobody stepping up for that role?
Nothing. If something breaks, you fix the mission to not have such dependencies. Like everything you've ever complained about, it's a solved problem and you're just not informed enough on the topic to have any valuable, rational, coherent, or useful input. You're just looking to invent new imaginary problems that don't exist so you can complain about “exploiters” because you don't know how anything works.
-
3
-
-
19 hours ago, draconus said:
No, it should simulate RL view as best as possible.
In other words, a full-spectrum simulation of pilot's vision.
Because that's the RL view, done as best as possible. We're dealing with a simulation. The end goal is a good simulation covering as many aspects as possible. Vision is one of those aspects. That much should be obvious.
11 hours ago, SharpeXB said:In 1080x1920
That's not what your screenshots show, though. Don't you think it's about time you learn how resolutions work?
7 hours ago, SharpeXB said:The trouble is it’s possible to exploit the system in multiplayer then.
It really isn't. You just think that “exploit” means “thing that is not what I want”, when in the real world, it's getting an unintended and undue advantage from flaws in the system. That's not what's going on here. Instead, what's happening is that people get to choose (or not) their visual setup to match their hardware and room setup, fully in line with how the system is intended to work, and by all accounts working better now than ever before.
That is the very opposite of an exploit. Just because you can't exploit it to get an advantage over others like you want to doesn't mean others can and will do the same to you. It just means it's the same for everyone, which again makes it inherently not an exploit.
2 hours ago, SharpeXB said:I can’t imagine there are too many people who actually like seeing the giant squares.
What you can imagine is of absolutely zero relevance to anything, and doubly so to this topic where you have demonstrated your inability to imagine that people see different things — in particular, that they don't see giant squares. This is particularly hilarious in view of how you have shown that you also don't see giant squares. You have consistently failed to produce any evidence of any such effect happening.
You can keep crying about your hallucinatory giant squares and your imaginary exploits but none of those actually exist. Until you start complaining about real things, your opinions and imagination is invalid, wrong, and devoid of any value or contribution to the conversation. Just be happy that you got the option you were clamouring for, even though — as predicted — it ends up not doing the thing you want, largely because you don't understand what it is you're actually asking for and can't articulate a problem that your desired solution should solve.
1 hour ago, SharpeXB said:If you recall the Model Enlargement feature, one of the reasons that didn’t work out was likely because nobody online could agree on a setting.
That's not what happened, no. That's just more imagination on your part.
-
2
-
-
8 hours ago, okopanja said:
Sharpe will never be happy as long as it does not let him give an advantage over others that they can't control. Every time he has flipped on this issue, it can be traced back to him realising that what he just asked for does the opposite of what he wants by giving others the same advantage he has, or by removing his advantage over them. He then pivots to some new fundamental misunderstanding of how the game or computer graphics in general work in the hope that this will give him an advantage instead.
Personally, my preference is for there to be no setting at all.
It's a core part of the simulation. You shouldn't be able to turn that off, same as how you can't turn off drag or gravity. It's the same level of integral part of what is going on in the air.
The end goal here is a full-spectrum simulation of pilot's vision, with all this entails in terms of offering whatever cues and shortcuts elementary 3D graphics can't provide on its own. This means dots, scaling, forced fading, over- and undersaturation of colours, and any of the myriad of things that will help convey the cognitive process of perception as opposed to inherently incorrect naive maths.
3 hours ago, SharpeXB said:That looks intentional. It’s like you get light dots in front of dark backgrounds and dark dots in front of light backgrounds.
It's called contrast. Another basic part of graphics you will no doubt fail to grasp because of how very simple it is to understand and somehow try to make the foundational part of yet more accusations of exploitation.
10 hours ago, SharpeXB said:In order to exploit the system
There is no exploit. Give it a rest. There is only you remaining wilfully ignorant about how computer graphics work. Just because you don't get the advantage you want, doesn't mean others are exploiting. Especially not when your own “evidence” shows that things have improved massively over your old preferred state where you — and not necessarily others — could trivially see targets at 40nm. That was an exploit. And you exploited it gleefully and to the fullest.
And stop playing in portrait mode.
-
6
-
-
13 minutes ago, SharpeXB said:
With the (local) setting this is how the other players can make you appear. Visible at 35 miles or as giant cubes
So it's working as intended then. For the bajillionth time, you try to make a point but instead accidentally prove yourself objectively wrong. You have shown that it is not an exploit. Congratulations, case closed.
You do understand that players being able to pick their own settings is a good thing, right? And that just because they don't use the same settings you want for yourself, that doesn't mean they're doing something wrong. Right?
…right?
-
1
-
-
7 minutes ago, SharpeXB said:
An in-game setting that’s an exploit
No. Just an in-game setting. It is how all mission settings work.
If that's the nonsensical notion of “exploit” you have, then you need to ban yourself from all MP servers because you run at whatever resolution you've set because the server allows you to play at that resolution.
Are you willing to stand by your definition and do that? Or admit that it you're just trolling? Those are your only two options.
-
2
-
-
2 minutes ago, SparrowLT said:
I dont know how or why but yesterday on enigma i could see enemy fighters coming head on.. managed to merge with a Phamtom twice with the SU25 and in the F-5 could see dots at arround over 5nm
seconc picture is the phantom at arround 2 nm. first one i think its about 9
Most likely, you're affected by the dot culling bug, which gets triggered reliably, but unevenly depending on what else is spawned in and in what order, in the direction you're looking. For bonus funpoints, the dots are culled front to back — i.e. you lose closer-in targets first, so things you are meant to see, you don't, and things you're meant not to (or at least struggle with) show up very clearly.
-
3
-
-
1 hour ago, SharpeXB said:
Compressed still screenshots don’t illustrate this issue very accurately.
So don't use a lossy format. Simple.
-
1
-
-
7 hours ago, draconus said:
You can't turn them off!
You can, if you do it right, but it's a bit of a bug… some might even say an exploit.
-
1
-
-
2 hours ago, SharpeXB said:
But I can see very distant aircraft in DCS on a 4K screen (with the spotting dots off), perhaps too far to be realistic.
And fixing that is exactly what the spotting dots do. They're already an improvement even if the end result sill make them show far too far out and even if the end result skews towards the too obvious. But you're not getting your 40nm spotting back, nor are you getting back your precious advantage over others who don't see targets that far out — the tweaking continues and we'll end up in a state where you will have to play on a level playing field.
Sucks, huh?
-
1
-
-
1 hour ago, draconus said:
Ok then, unless you want to simulate gravitational lense, aircraft scale linearly with distance.
…in pure measurements, but those don't matter. It's what you see that matters. That's what the graphics need to simulate. That's where scaling has a place in simulation.
Again, if we want to have an actual simulation, we can't rely on something as simplistic as just trigonometry. That is not how we perceive the world. It's the same mistake as all the old nonsense about our eyes only see [some random number] frames per second, so that's what the monitor should display. It's a cognitive process. We want to simulate a signal processing machine operating on bad data. Trigonometry will not yield a realistic answer.
1 hour ago, draconus said:If the fov is correct (VR) your eyes will become natural limit.
…in 15-20 years when we can also assume that everyone runs on >90°-coverage displays with sub-MoA pixel densities, raytraced, HDR, eye tracking and foveated rendering and player distance ranging — even in pancake — and are absolutely not allowed to change their settings in any way.
But what about here, now, and also any time the player can choose to change their settings? Whenever we need to have a hard cap on how far out targets are rendered (and this will always be the case) because otherwise targets are drawn, and thus can be seen, when they shouldn't be. Or they will pop in and be tremendously obvious, when they shouldn't be.
There are no good or even viable ways around this to create a realistic result other than a solution that uses scaling for intermediate distances and non-geometric rendering at the extreme limit of vision. It is also vastly more trivially implemented than all the other rendering techniques to hide distant targets, and more tweakable to reach that realistic outcome. It also solves the problem of leaning in and having a zoom function — an infinitely less realistic feature than scaling could ever possibly be… but where's the campaign to get rid of that? If realism is your goal, and you want it now rather than in DCS 7.0, you need to overcome this false notion that we should forego realism because the numbers feel wrong.
1 hour ago, draconus said:Not a problem currently - majority of people rather complain about not seeing anything or unrealistic squares.
…both of which could be solved with a spotting simulation that didn't try to rely on a single solution to solve a multi-levelled problem.
38 minutes ago, SharpeXB said:Because the system is totally exploitable and unequal in effect.
…and that's exactly why it's a ultimately a bad idea to let people turn off the dots, ironically enough. And let's not forget that you were all in favour of such an exploitable and unequal system when you were on the beneficial end of the equation, and have been campaigning hard against all attempts to make it equal and non-exploitable.
-
1
-
-
1 hour ago, SharpeXB said:
Smart Scaling was intended to make very small objects more visible by scaling them up.
No.
Smart Scaling was intended to make the aspect of small-to-medium objects more realistically identifiable. It is not a spotting solution — it's a simulation of perception to accurately convey cues used for tracking an already clearly visible target.
Scaling is not about making objects visible — the objects are already visible so that would be pointless. As long as you assume that is about object visibility, you are objectively wrong and any everything that follows from that assumption — all claims, arguments, and options — are incorrect and absolute nonsense.
1 hour ago, SharpeXB said:If you want to go the route of just scaling up every object that’s what the zoom view does.
Zoom does not do what scaling does, nor does scaling do what zoom does. That's why zoom is a separate thing that exists alongside scaling (and why proper scaling algorithms take zoom into account and-counter-scale to remove the effect).
It would help your case if you read up what scaling is and what it does so you don't make such silly mistakes out of sheer ignorance about the topic.
1 hour ago, SharpeXB said:The problem with that smart scaling demonstration is the it only shows the aircraft examples against blank background
…which is exactly how it woks for everything else that isn't a background object. An aircraft carrier is not a background object, and as such would be scaled to match as well — not that you'd be able to notice at the distances where it's really active.
You'd know this if you had any idea what smart scaling is; what it does; what its design intent is; how it works; or… anything about it really.
2 hours ago, draconus said:Graphics should correctly display angles/scale or have them wrong and simulate subjective acuity instead? Sound should be as real as heard IRL or modified one that accounts for lack of haptic feedback or maybe the one that cater to player comfort more?
Graphics in a simulation should obviously… you know… simulate what you see. Otherwise the result is unrealistic by very definition. Why is this even a question?
2 hours ago, draconus said:Some high resolution monitors have already reached the point where we won't spot the difference between the pixels and VR will surely get there in coming years, so it's no longer resolution problem.
Not quite. It is now becoming a resolution problem in the opposite direction, where naively using “real” angles and scales creates a hugely unrealistic outcome because the game renders — and the display shows — far smaller details than you should be shown. As such, the rendering pipeline can't just throw pixels on the screen where they “should” be according to maths; it has to simulate the limits of perception to not put pixels in where they shouldn't be seen.
Scaling is an increasingly more necessary part of that package unless you want to create jarring transitions from one state to another, with the target popping in and out of different degrees of visibility, and unless you want to introduce harmful differences between different display systems and setups. It is obviously not the only solution, but there is really nothing else that can do the same thing in its particular range band.
-
3
-
-
3 hours ago, Phil C6 said:
Why not? smart scalling depends of the distance so what is the prob with that? closer you are, more the scale up is small
From your answer you seem don't know it and never tried, so how can you be sure your conclusion isn't irrelevant too?He doesn't. He only goes by his own fantastical assumptions and dreams because those are better demonstrations of how the thing works than the thing itself, somehow. He even admitted as much when after a long slugfest, it was eventually dragged out of him that he actively refuses to read the research and look into the matter, because once again, he uses fantastical assumptions to fill in the gaps and reading actually looking it up would obviously reveal those assumptions for the nonsense they are.
You will never convince Sharpe that reality doesn't match his fantasies, and as such, any argument based on reality and facts will not work on him.
The general rule is, if Sharpe says something about scaling, it is false. He has no idea what it is, how it works, what it looks like, or what its purpose is. He doesn't want to know. He just knows that he's against it because people suggest it as an improvement to the game, and will invent any number of increasingly absurd falsehoods to “support” that position. As amply demonstrated in this and other (merged) threads, he also doesn't understand how resolutions work, or monitors, or basic trigonometry, or angles… so the same general rule applies there as well. Just look back a few dozen pages and watch him trying to argue that 4000 is 3000 and 50 is 60, because if they aren't, his attempted argument falls apart.
-
1
-
-
Getting the AI to not see through the airframe and terrain was a major milestone. Fog and cloud is… aspirational, let's call it.
-
2
-
Changes to the behaviour of net.dostring_in()
in Scripting Tips, Tricks & Issues
Posted
Yay!
There are plenty of good ideas in the thread to work from, so I'm sure you can reach a well-intentioned end goal with a more suitable and less disruptive solution.