sobek

AESA stands for Active Electronically Scanned Array, as opposed to PESA, which stands for Passive Electronically Scanned Array. Carlo Kopp is a fear mongerer. You have to take everything on that page with large amounts of salt.

I'm not sure procedural generation can do much for you in part of rendering performance at all. It can help reduce the physical memory footprint of theaters though.

Procedural generation can be made to set in at any LOD you want it to. It doesn't need to be an 'either/or' type of technology and at least according to Matts statements, they are working to integrate procedural techniques further down the line.

Don't think so. First time i ever heard of it.

nVidias Linux drivers are closed source and suck massively for a variety of reasons, if that is a consideration.

DP carries audio just fine... Also it's not that uncommon, most desktop monitors have display port nowadays alongside HDMI. It's uncommon for TVs though. It depends on the monitor and graphics card. DP is an expremely versatile format, you can even transmit USB lanes over DP.

TBS seems to be less a software package than a service. You (as a military institution) approach them with what you need and they make it happen.

You're right, that's why in a real AC, the stick will either go to full stop forward by itself through the weight of the elevator or whatever position the slipstream of the prop pushes it to. This is *not* a convenience thing, it is done for ground handling safety reasons. We're getting off topic though.

I don't know, i said human opponent to be sure.

Pilot body posture isn't the same in all aircraft, so why should g-tolerance be the same?

If you're flying against a human opponent, then he has to deal with comparable thermal limitations. If you're low on energy and your opponent isn't, you're dead either way (unless your opponent sucks, but then, how did he get you to bleed your energy...).

It is best practice in taildraggers to *always* have the stick in your lap unless you operate in a particularly strong tailwind.

To demonstrate that damage from improper RPM is modelled, contrary to what you stated previously.

They recently updated the forum software. Maybe it had something to do with this.

We oldtimers still have way too much back from before they nerfed the increment speed.

That test had nothing to do with the originally lamented issue. He set the hydraulic system to fail, not just the engine. Nobody really questioned that the hydraulically operated systems won't work when there is no pressure. The issue is that there is pressure even when the engine is only windmilling.

What his post boils down to for me is that in the absence of correct information about the pump output at anything other than nominal RPM, they had to estimate the behaviour. Estimates are by their nature faulty. What you are seeing is the error stemming from having to estimate the behaviour. Yo-Yo isn't saying that the manual is wrong, he's saying that with the data he has available to him, it is not possible to model it better. Knowing that the model is wrong is not enough to make a better model. It is only the first step.

You of all people recommend a tube amplifier? ;)

Is there a chance that ED will move to Vulkan instead of DirectX in the future?

All this JSGME talk is sidetracking the way it's meant to be used. Thou shalt not directly edit the control assignment lua files. That's what the lua.diff files are for. The question is, can the .diff system handle all eventualities or does it need to be expanded.

It's really easy if you have processes that aren't coupled at all. E.g. at work we do processing of sensor data. A sensor sends data and the server processes the incoming data and puts the results into databases. This is perfectly parallelizable. Each sensor that sends new data gets added to a queue. Once a CPU is free, the uppermost sensor in the queue is assigned to a worker that performs all tasks necessary for that sensor. Voila, you can easily scale that to as many CPUs/servers as you have available (with some limitations depending on the database interface, but that's the details). The problems start appearing once the threads need to talk to each other. With DCS, there are a lot of components that are tightly coupled, not just because they were programmed this way but because they depend on a lot of data from other components. That is the reason why the splitting up part is very hard. As previously mentioned, there may be components that can be pulled out because they can be made to run asynchronously. This in itself is usually a big task however. The only component that runs in a separate thread, the audio engine, only does so because at some point it was pretty much written from scratch (IIRC), at which point it was feasible to write it threaded. I imagine the same could potentially happen to other components, under the premise that they can be pulled out of the core engine thread without needing to communicate to the core too much.

Would be interesting to know if the .diff files can handle conditional commands. c0ff? :)

Would you mind describing your process? In the diff file, you have to write everything from scratch instead of editing a line.

That and add a way to use the cutoff detent (in both directions) in planes other than the A-10C.

You aren't even scratching the surface of the problem. This is way too superficial. It would run slower than if you'd execute it on one core. There are sequences in the code that can not be parallelized. To put it in simple terms, think of an algorithm as a sequence of a few mathematical operations. You can't perform the last operation before you have the result of the ones that precede it. It is simply not possible because of causality. There are other scenarios where it might be possible, but the time needed to realize it is prohibitive. Because for example they depend on results of other operations. If you split something into a second thread and that thread is going to sit there idling while the first thread needs to finish, you just effectively wasted precious worktime on something that actually worsened the execution speed of your program. Define "things". AI, maybe. Sound is already there. If by things however you mean other physics simulation topics then the answer is most likely no. The physics engine in DCS is, as far as i can gather, real time in the scientific sense, that is, frames need to be finished in a predetermined amount of time or bad things start to happen. That alone is very hard to achieve with a multithreaded application. When you factor in the level of dependency between all things physics, you end up in a place where multithreading won't do anything for you. What would that achieve? The sound engine isn't the bottleneck, it's not even close to running into performance problems. Besides if you split everything into threads until you are at atomic operations, you will have so much overhead that you are once again running slower than without splitting it up. Having more threads than cores can be beneficial, but it can also hurt you. No. The performance critical stuff doesn't run in lua. lua isn't meant for heavy lifting. That's what C++ is for. The bottom line is, this is an incredibly complicated topic (and by incredibly complicated i mean that some of the smartest minds in computer science are baking their noodles about it). If you really want to understand why multithreading is so complicated (and i mean *really*), learn a programming language and do a tutorial that teaches you to program a basic multithreaded application.