winz

Cold War Warrior only requires that you overfly your two "attack" waypoints. You don't have to destroy anything. :) But now to the topic. I agree with you that this can be a huge immersion breaker, especially when some campaign missions task you with destroying unreasonable amount of enemies (I'm looking at you A-10Cs Push campaign) and failing to destroy that last one tank results in mission failure, forcing you to replay the same mission. And is especially irritating when the whole campaign is basically the same template repeated, with increasing amount of enemies and AA systems (once again A-10C Push campaign). This is where the lack of dynamic campaign is felt the most, because in ideal circumstances a dynamic campaign engine would look at what you acheived in your previous mission and create the next generic mission. Some campaigns are working around this problem by offering more missions for campaign stage (A-10A Valley, Oil War), so when even when you fail (or draw, to be more precise) you don't fly the same mission again (but if you fail too many times, or are unlucky with the rng...). Or allowing the campaign to move backwards (Oil War), so the battle can end in a failure, draw, or win. But it is still too much 'black or white' especially when the result depends on your performance, not the preformance of your side (but on the other side, this approach makes mission design a lot harder). But in more variate campaigns (like BS 1/2 Deplyoment or Su-25 : Revanche), where each mission has it's own, distinguish, setting and feeling there has to be a (reasonable) objective you have to acheive before you are allowed to move to the next mission. And such campaign should never, ever, progress backwards.

One issue I have with labels is that you cannot specify transparency for different distances. So once you're in the defined distance the labels will just pop-in. And you, the player, go from "I don't know if there is anything there" to "There is something on that precise spot" without any kind of effort. Sure, you have to id the target, but that is most of the time easy when you know the exact locations. I use the newline to somewhat work around this. Pointing your sensor on the label at max distance will not help you, you have to search the area around the label to find and id the target. As you get closer, the displacement between label and target gets smaller (because labels don't have prespective), so at close ranges the target sits next to the label. Anyway, that's the reason why I use it. Maybe someone else will like it, if not, then no harm done :)

What you can also do is put a newline before the label, so the label isn't sitting on the target, but is displaced, so you cannot just aim at the label.

It might be because PeterP uses different versions of SweetFX than DrCrow. And those two version have incompatible settings files.

Wow, very usefull tip. Thank you :)

+Intel :) With Mantle/Nvidia API you once again have the question how low lvl will it be in the end? If you want to be better than DircetX/OpenGL then you have to ensure that all your next architectures will not require DirectX/OpenGL level of abstraction for backward compatibility (which might in the end somehow hurt your architecture). Just to be clear, I'm not saying having lvl api is a bad thing (it is a good thing), but people should be realistic about what it will bring. I personaly don't think that api bound to a single brand will become anything more then a marketing gimmick (*cough* physx *cough*). DirectX was bigger mess before, and it didn't die so it's unrealistic to expect it to die now, when it's basicaly the only API used on MS platforms. And there really isn't that much pressure for increased performance in PC Games. PC perfomance (even with all the high-lvl api load it carries) is on par with latest generation of consoles, and PC will once again outperform consoles in the comming years.

The problem with talking 'directly to the HW' is that you're sacrificing compatibility for performance. In low level calls you're using functions that are specific for that HW, but might not be available in previous generation of cards, might not be available in the next generation, might not be optimal in next generation and are certainly not available on other brands. So you cannot use low level calls for main optimalization, because there is no way you will be able to make custom code for every HW your game will be played on. And some minor tweaks will most likely not be done for cards 2+ generations old which would benefit the most. So PC Games don't talk to HW because they cannot, but because it's impractical. We've been there in the good ol' Dos days, where you had to i.e. select your soundcard manufacter&model for sound/music to work. If your card wasn't supported, then you were out of luck. This isn't an issue for consoles, because their HW is set and doesn't change.

I took a more pragmatic approach - I edited the mission to lower the difficulty.

It's still working...nothing duct tape couldn't fix...;)

For SP you can try this little app I made: http://forums.eagle.ru/showthread.php?t=108409

Will definitely tune in during the weekend, just curious about one thing. any particual reason you are using livestream and not twitch? :)

It isn't all unicorns and rainbows, but some post are really, for the lack of better word, childish. The change log is full of sweet changes and shows that ED is trying to fix the hottest issues (MP stability). ED is a small studio, and SW development is more complex than some people realize.

"ECM effectiveness against air defense systems has been significantly increased." "Reworked the Dynamic Launch Zone (DLZ) of SAMs. It will now take to account the target’s data instead of the earlier fixed zone." Wohoooo.... Looking forward to the patch, hopefully it will be before christmas :)

I'm running DCS in windowed mode for years without any problems.

Glad it worked. Well, there might be some kind of bug, will have to investigate when I got the time. :) And, nope, I'm a sw developer with high copy-paste skills :D

Troposhpere changes me_mission lua, and that change is rollback by the DCS autoupdate, so it has to be re-injected after each update. But the problem lies elsewhere I think. The Vergeevs group missions are marked as read-only. To fix it you need to manually delete the Troposhpere temp folder 1)Go to the temp folder - Start and type %TEMP% in the search field, enter 2)That should open the main temp folder. Delete the DCS_WEATHER folder, present there. To prevent this happening in the future you need to umark the Vergeevs group 'read only' attrubutes. Hope it helps, and thans for the kind words :)

Nothing worthy will come from the OP... Lets share muffins recipes instead. My favourite is blueberry muffins Ingredients: 2 cups all-purpose flour 1 tablespoon baking powder ½ teaspoon salt 1 egg 1 cup granulated sugar 4 tablespoons (2 ounces) unsalted butter, melted and cooled slightly 1¼ cups sour cream 1½ cups frozen or fresh blueberries Directions: 1. Preheat the oven to 350 degrees F*(170C). Grease a standard 12-cup muffin tin (or line with paper liners) and set aside. 2. Whisk the flour, baking powder and salt in a medium bowl untill combined. Whisk the egg in a separate medium bowl until well-combined and light-colored, about 20 seconds. Add the sugar and whisk vigorously until thick, about 30 seconds. Add the melted butter in 2 or 3 additions, whisking to combine after each addition. Add the sour cream in 2 additions, whisking just to combine. 3. Add the berries to the dry ingredients and gently toss just to combine. Add the sour cream mixture and fold with a rubber spatula until the batter comes together and the berries are evenly distributed, 25 to 30 seconds. Small spots of flour may remain and the batter will be very thick. Do not overmix. 4. Using a large spoon or a cookie scoop sprayed with nonstick cooking spray, divide the batter amount the muffin cups. Bake until the muffins are light golden brown and a toothpick or thin knife inserted into the center of a muffin comes out clean, 25 to 30 minutes, rotating the pan from front to back halfway through the baking time. Immediately remove muffins to a wire rack and cool for at least 5 minutes. Serve immediately or at room temperature. Store leftovers in an airtight container at room temperature.

No, you cannot just dump an app memory and restore it at a later date, that doesn't work. I.e. the the dump wouldn't contain kernel memory = handles to kernel resources, like opened files would be invalid after the restoration. Yes it is very clear what you have to do to save a game, it's the implementation part that is time consuming. And to add a personal note to the 'quick & dirty' solutions people try to figure out here. I can tell you, from my experience as SW developer, that quick & dirty solutions will in the end cost you more development time than proper solutions. Because while you hack it quickly together, and it kinda works in your happy end scenario you visioned, it doesn't work in any other, so you spend a ton of time plumbing all those holes the quick and dirty solution has...more ofthe than not with another bunch of quick & dirty solutions.

Because it would not work. Those data are not enough to recreate the mission. Imagine you saved with your method with an AI in the middle of landing approach. After load it would in better case abort the landing, in worse case crash into the ground. You are also ommiting one huge aspect of mission - triggers and lua scripts. In this method you don't perseve their states. Not to mention that all units will be recreated new, without any damage they received. I don't need to damage the plane to acheive this. I can fly on one engine for 20minutes, or I can leave the APU running for the same thing to happen. And that's for A-10C. In P-51D, where you manually select tank used, there is no way to recreate the fuel values from a single number. You need to store fuel load for each tank separately. Yes, in order to climb on mount everest, you only have to climb the damn mountain.... The problem is that the program doesn't know which variables needs to be stored to recreate the object state. A bunch of programers need to spent time indetify those variables. And there are tons of them, the fuel is just the most basic, obvious expample. If you look how many parameters you change in CDU and other systems in the A-10C you realize how many variables there are. Then there is damage persistance, wear and tear on equipment (i.e. engines)...etc. It's not hard, in sense that it's a complicated process requiring some insane research paper, it's just very time consuming. That's your opinion. My opinion is that EDGE + Dedicated Server is more important than save functionality. TacView only have to save basic object properties, like location, velocity and major game events. I.e. it doesn't know how much fuel was left in tanks of an airplane, or what kind of damage was done to an unit. It doesn't need to, it's not required for what its aim is.

Because a ton off properties are not exposed in the mission editor (or stored in mission files) and are initialized from default values when you hit the fly button. Those properties need to be saved as well, because the default values no longer apply in mid-mission situation. Cockpit switches poisition would be the most basic example. Another simple example - Fuel for A-10C. You specify your fuel-load in mission editor. When you hit the play button the module code takes this value and distributes the fuel evenly between your two tanks. Now imagine you get damaged tank, and lose all your fuel in one of yours tank. What happens if you would like to save now? The fuel load as whole is no longer sufficient, because using it would (once again) distribute fuel evenly once you load your savegame. Resulting in half of your remaining fuel beeing put into the ruptured tank..not good. For savegame functionality you need to store fuel in each tank. There are tons of such variables, because DCS modules are the most complex flight simulator modules available for civilian market. What is 'worse' is that DCS is modular, so the modules themselves would have to tell DCS World what they need to save. Yes, it woud be a great functionality, I agree. But it is a lot of work and ED doens't have a big team and there things higher on the TO-DO list than this.

Saving the one particular moment is where the problems start in sw as complex as DCS. Track needs to save just timestamped keystrokes and replay them from a defined starting position, that's prety straightforward. But to save a particular moment is big effort for a sw that wasn't build with such functionality in mind. You have to store tons of variables (physics model state, ai routines state, systems state, models state...etc), which you must first identify - that is a lot of work that has to be done for every module.

Yes, ticking 'no' will allow you to play the mission in original weather. DCS always makes a copy from the launched mission. It's this copy that is used by the sim, and it's this copy that is modified the app. So the original file remains untouched.:) After each patch you need to re-inject it into dcs, but yours setting will be preserved.

Yep, you understand it correctly. The weather 'injection' is all done, so some kind of script that would call the app should work. :)

Sadly, not done yet and on halt. :( I was able to do some work during vacation, but since then I've been spending 10+ hours a day at work. Hard to find motivation to open Visual Studio when I get home in the evening. :noexpression: I still plan to finnish it when things calm down a little IRL.

Yes, DCS is pretty unrealistic when it comes to IADS, because their modeling is very simple. The individual systems have only very basic AI routine (radar on all the time, engage anything in range, missile flying pure pursuit) and operate as individual units, not as an integrated system. I'm sure improving the I aspect of IADS is on the to-do list :) But improving IADS opens another can of worms - ECM.