Pikey
-
Posts
5916 -
Joined
-
Last visited
-
Days Won
4
Content Type
Profiles
Forums
Events
Posts posted by Pikey
-
-
To bring something new to this that only ED can do, I would want to see the routes and tasks that a player gave a unit via Combined arms, saved. This provides a complete RTS game, the ability to alter the battle, then save it, rather than watch all units sit still after saving because they no longer have their original route.
Similarly, the routes and tasks that are provided by scripting, should be saved, i.e. what the unit is currently doing, not what it was told at the mission start.
There's been so many methods to save unit positions over the years, so many people have had their take on this, including myself. Saving positions, is something. Saving the actual AI state (not even the scripting state, i'm not asking for that) is important because thats a fundamental requirement to restore the mission that we have never had. People don't really know how to ask for this because most of them don't understand about scripting, they just want to start where they left the game and cannot volcalize their needs because they wont know that the AI is just reusing the original mission file in the save game. If they move their carrier, save the game, they will be disappointed to find it sitting still with no route after loading. But even worse, if an AI commander is moving units, these all now stop and the battle is stationary.
The request is another request for the ability to getTasks() from an AI controller. There is no API for actually asking for the current task of a AI unit. Some people might be surprised to learn this, others dont really care because they assume soemone can fix something like that, they don't know the scripting API. With this API, the unit position can be saved, as before and then the units route and task can be reliably given back to the AI so it can move to where it was last sent, providing a dynamic save, one that keeps the movement and orders should they have changed. This allows scripting to work freely. Scripters still need to pick up their units control at mission start, but they dont need to task any of the groups. Doing that takes a lot of work in collecting the "orders" in a remote database and tracking all the orders for reissue.
I feel this has to be said because folks generally dont provide feedback at this level, so not providing this feedback allows anyone to assume that it wasnt wanted or needed, when it has been dearly wanted for many many years.
-
4
-
-
On 6/23/2025 at 9:50 PM, upyr1 said:
I was hoping to get a developer to confirm or deny. I have been looking at the lau
-- 127mm definition ********************************
def_heavy_AA_mg_LN = { type = 3, --/N/ big caliber 14.5 and bigger distanceMin = 100, reactionTime = 2.0, reflection_limit = 0.22, connectorFire = true, -- sensor = {}, PL = {}, } set_recursive_metatable(def_heavy_AA_mg_LN.sensor, GT_t.WSN_t[10]); --/N/ NAVY gun, from \Database\scripts\sensors.lua
Type 3 in the WS declaration is AA. But in tests it will engage surface targets if it can. Type 6 is naval arty, Type 11 mixed iirc. The issue with this as I have found is that ED schemes are limiting. 5" were used as very poor barrage, 1 in 1000 rounds hit. I've spent hours on mods tuning this effect and it's not easily replicated. Worse, gun allocation is poor, there is some internal gun to target distribution that makes dual purpose weapons stupid. For example if close range to a high surface threat, in dual purpose it will use first come first served target allocation.
It's going to be an issue when you see 18 inch guns and 5 inch guns together and 5 inches target the ship and 18 sits doing nothing.
-
Although not explicitly stated in the news letter, we can infer from the forum position that this will be EDs module. That's important when looking at development time and features, what's coming is fairly predictable.
-
1
-
-
5 hours ago, tobi said:
That sounds more like incorrect use
It might be related to materials from the searches I'm doing, I have no experience in this and don't know how to troubleshoot it. Ive done the same thing with lots of configurations. The information is spread out over years. I'd like to get started on modelling but I have no end to end process. I managed it about 8 years ago iirc.
-
This appears to be the polling rate issue for the OP. It had all but been solved for most hardware some months back. If you have another mouse lying around, try it out and see. There might be some old communications about it. There's more information out there I'm sure, but you'll need to provide more specific hardware details, its a hardware based problem.
-
I tried version 4.5 and version 3.6 of Blender and the latest ED tools and thetobi one and i just get 1KB files. Does anyone have a working export configuration for Blender?
-
On 7/10/2025 at 7:53 PM, Lidozin said:
If there’s a mismatch in energy performance, turn rate, climb, etc., under those circumstances — that’s something worth looking into. But if the concerns are about form-up logic, taxiing behavior, or scripted transitions, those are separate layers of the simulation, and not what’s being discussed when we refer to the AI using a physics-based trajectory model during combat.
You already said you wont accept AI doing unphysical things as evidence it does unphysical things, based on when in the game it does them - "Layers" you call them. You then accepted climbing outside of combat as evidence it supports that AI doesnt cheat in dogfights. Meanwhile you conveniently ignore that AI picks when and how it observes the SFM according to no logic that you see, it is in fact, at code level for which you continue to assume, is bound in physics.
Simply put, you've made an assertion and said 'prove me wrong'. Which is shifting the burden of proof and a logical fallacy. In fact its a well known situation called Hitchens razor in that What can be asserted without evidence can also be dismissed without evidence. You disagree because you think you've supplied evidence that the SFM is working because you observed it at some point(s) doign so. Unfortunately it doesnt work that way. By the same token, God exists because you saw a miracle.
This is not solvable empirically, it only needs reasonable doubt about how the AI does work. And that reasonable doubt can come from observational data, not just empirical data. The reaosonable doubt is, because I saw a plane float, I know AI is not confined to physics. Its software and has no regard for Physics and chooses when and where to use it as a convention that helps the game play elements of the game. This is all that is needed to dismiss your assertion, no matter what you want to throw at it. The burden of proof falls upon YOU to prove that the AI always uses Physics. Not sometimes, but always. Until then I shall continue to spectate, just in case you manage to satisfy my curiosity. Because I am open to all things, even if you have code level access.
Continue with your argument. WHy dont you try a counter hypothesis approach where you formulate a hypothesis that proves your own is wrong, seek to eliminate that instead, like an actual scientist.-
1
-
1
-
-
14 minutes ago, diego999 said:
Just last night my AI wingman crashed into me while I was lining up for landing.
In the same sortie, two C-130 decided to block each other at the end of the runway, effectively ruining the entire mission.
Does this count as a complaint? Or do I need to fill a form?
Yes, please fill out this accident form:
I would definitely recommend this AI to a friend or family. (Tick a number below)
10 10 10 10 10 10 10 10 10 10-
2
-
1
-
-
I'm going to play with this sarcastically. I'm going to parody the ideas in Comic Sans. Once more, its not personal, I'm sure I'd like you as a person, just the ideas don't sit well with me and its got to a point where its a bit funny now. Heres the sracasm highlights.
We see an SFM table in the coremods of the plane lua. This means that the AI uses this when calculating its dogfight state table. We know that the existence of the SFM means we only need to look at the actual model, not how its executed or used in the software. The fact that the table exists means DCS uses it. It doesnt matter that the C code is encrypted and unreadable, its only the LUA. And anyway, I can read the program, I know things for sure. Just use a stopwatch.
We can rule out misuse of the SFM data because that doesnt make sense. Why would a game need to force the AI to do something at all, when it flies realistically? Stupid.
There is no evidence of the AI not using the SFM data. Apart from the times when it doesnt, like when its following the player in line abreast perfectly and can turn at the same time and aero brake stop 100kts in 1 second. But this doesnt actually matter because we know because of the SFM data that the AI doesnt behave like that during dogfights. SFM = dogfight and climb. Everything else can be scripted, thats ok, but we know for sure its not breaking this rule.
We can prove this by looking at when the AI isn't doing something stupid, like climbing. If we examine the climbing then we know for sure this must apply to the dogfight data.
When we look at tacview, we can see the moment to moment forces and speeds and alpha recorded for the AI. It's OK to see things here that are within the SFM data. Look, the plane is going at 500kts straight up. That's perfectly OK, so the entire fight must be fine here. I don't need to see the plane doign these 500kt climbs again and again, because its just flying perfectly, there is no issue over time with the energy state.
We havent seen any evidence of the AI using scripted behaviour. At least not between 3.30pm and 3.45pm in the afternoon of June 12th 2025. The AI would tell us he is using scripted behaviour through the comms menu.
We haven't seen the Scripts folder of the DCS application where the AI routines are kept. At least, the ones that apply to normal flight. The dogfight ones got moved some years ago to protect people keep on arguing about this non existent problem because they are just bad fliers and need to stop wasting their time looking for excuses.
We know the DCS AI is very good so the routines can be shared from MiG pilots to the Luftwaffe, so they can use boom and zoom too. Its a special trick, it might look the same, but actually each plane type, jet or prop can use the identical vertical manouvers and energy. But the SFM is what decides how it really is different.
We also know that ED eventually gave up their special Flight model in development after realising it was pointless. It was pointless because the AI already was perfect. Why develop something to make it different when it is already the best?
Also we know a lot of things about planes and so we've marked ourself as the solution very early on in this thread. Quite simply, they dont understand about SFM, its only for aeronautical engineers and high IQ. So being the solution saves time and is more effective in conversations.
-
2
-
1
-
-
@Lidozin I'm not picking on you, i'm defintiely picking on your argument, its got more reversals than an IL2 Sopwith Camel dogfight. Here's your 3 page argument condensed down and fall apart, summarized, with quotes since you like empirical data.
Step 1. Claim the FM is fine.
Step 2. Be told its not applied consistently and thus it is in doubt.
Step 3. Argue that you were only talking about Combat routines and not non combat routines like land/takeoff, follow/escort
Step 4. Show that by verifying non combat routines like climb performance, it proves the AI is following physical models and limits all the time in combat!
Am I the only one here noticing this?
You can say the FM observes the rules sometimes: Accepted. You cannot say that because it uses physics soemtimes that it always does.
You know, and everyone knows here that the software chooses when to use flight models, but the key to knowing that its using a flight model is to wether the moment to moment decisions are natural, or its a repeat of a sequenced set of events sewn together to look like its real. And that is what you miss. WHich is why I say you dont play the game enough to notice. Those loops. I see the WW2 planes also using them. Its just canned sequential responses, not a real FM and its not staying within physics between these sequences. They can do it forever.
You can be 100% correct, 1% of the time. But you can't use the example of being right once as evidence that you are always right!
The point is that AI strings together canned tracks and puts them together. You need to look at the enitre picture holistically. Its software, its simplified, its designed to work well enough for casual scrutiny, but when you put the whole picture together, it collapses, along with your argument that the AI observes physics.
Where is ED's GFM they talked about? The one that should react properly to physics, they said. By your reckoning, we dont even need it!
On 7/10/2025 at 8:11 AM, Pikey said:Ive got some news for you. You built your premise on an assumption, that the physics model is being used all the time.
See those routines AI performs... See how they follow patterns...see how they snap together so neatly... or maybe you aren't looking.
Let me tell you something you apparently don't know or have ever seen. it will come as a shock.
Ai doesn't use physical models during all aspects of flight.
On 7/10/2025 at 7:53 PM, Lidozin said:The original discussion wasn’t about general AI behavior across all mission stages. It was specifically about how the AI performs in a dogfight, and whether the AI's flight model during combat is based on real aerodynamic parameters that correspond to those of the real aircraft.
On 7/13/2025 at 12:06 PM, Lidozin said:I’m not suggesting that the AI behaves perfectly in every respect — only that, in this specific context, its energy performance in sustained climb matches both the manual and computed data to within a few percent. That’s not “superhuman” — that’s simply a correct implementation of aerodynamic tables.
The formation example is a common misunderstanding:
On 7/12/2025 at 4:16 PM, Lidozin said:The confidence in how the simulation behaves stems from well-established knowledge of the trajectory model in use.
[..snip..]
It’s a modest investment of effort, but it yields clear data: either the simulation behaves as predicted by the aerodynamic tables, or it does not — and in either case, we move from speculation to grounded evaluation. The test can also be easily shared and repeated by others, allowing for open verification.
On 7/13/2025 at 1:20 PM, Lidozin said:That said, I’d like to remind everyone that the original goal of this analysis was not to examine AI behavior in terms of tactics or input realism, but simply to test the claim that the AI “doesn’t obey physics, or has physical performance beyond what a player-controlled aircraft can achieve.” The flight test results suggest otherwise. Let’s avoid shifting the discussion away from that specific and measurable question.
I can get you your empirical data that AI doesnt observe physics, but its more fun listening to the various ways you avoid finding that important.
-
2
-
2
-
-
On 7/10/2025 at 7:53 PM, Lidozin said:
If there’s a mismatch in energy performance, turn rate, climb, etc., under those circumstances — that’s something worth looking into. But if the concerns are about form-up logic, taxiing behavior, or scripted transitions, those are separate layers of the simulation, and not what’s being discussed when we refer to the AI using a physics-based trajectory model during combat.
The examples provided prove physics is not observed 100% of the time. Only that. Nothing else.
You can state any physics observation you like, but it doesnt serve as evidence to a question of software.What makes you so certain that the software is being used properly and consistently when you never wrote it and don't have access to it?
A model can be correct, physics, can be proved. I'm happy that a model is safely beyond reproach. What I'm not convinced of is that its applied correctly or consistently. You cannot read the software, its going on beyond your eyesight. Software does not observe laws therefore you cannot use physics to prove that software conforms.
Now, you marked yourself as the solution in this thread. I don't care about the arrogance of that, but it's a sign that you don't consider any previous or future argument to be of value. SO, since you are th esolution to your own thread, I think you can dispense with everyone else in the world and go back to single player. It's where you shine.
-
4
-
2
-
-
35 minutes ago, rhoady said:
Has anyone ever used chatgpt for creating/editing missions? I'm trying to set up one now and I'm not familiar with scripting in the miz file so any words of wisdom would be great
No, but ive used it for performing workflows it knew about. However you ar etalking about two different things in two sentences about the same thing. Misison creation doesnt need scripting. And ChatGPT will struggle to tell you how to use the ME apart from click here to place a plane, click here to place a tank.
Scripting....well if you havent used the mission editor yet (you seem to think its about scripting) then you have a lot to learn before you script and just go read the docs and play around with it, its not that hard. -
On 7/8/2025 at 11:39 PM, Lidozin said:
I’d like to respond to your points, because I think there’s a fundamental misunderstanding here — not about opinions, but about how flight models actually work.
First of all, a trajectory-based model (point mass model) is not something that can be "good" or "bad" in itself. It's simply a set of well-known, well-defined differential equations that describe the motion of an aircraft CoG under the influence of aerodynamic, thrust, and gravity forces. Solving these equations — through numerical integration — gives us the actual flight trajectory, including climb, acceleration, turn performance, and so on.
What determines whether such a model is accurate or not is not whether it "feels right" in a game, but whether it reproduces known flight characteristics of the real aircraft. These include:
-
the flight envelope (available from test data),
-
maximum climb rates and the speeds at which they occur,
-
sustained and instantaneous turn rates,
-
energy performance (specific excess power),
-
and so on.
All of these characteristics are known and documented — especially for legacy aircraft — and are the benchmark against which a simulation model is validated.
You mentioned that “you tweak it to behave in-game like something that works well,” but that’s exactly the problem: "works well" is subjective unless it's backed by reference data. If you're modifying parameters by feel, to make the model "fly right," you're essentially distorting the data to compensate for a misunderstanding of the model structure.
In fact, the graphs shown earlier in this thread are not just visualizations — they represent the analytical outcome of the same trajectory equations, using real aerodynamic input data. They describe how the aircraft behaves across different regimes: acceleration, climb, turn performance, etc. And when the simulated data closely matches the known performance of the real aircraft, the model is working — regardless of whether it was coded as SFM, EFM, or otherwise.
Lastly, it’s worth emphasizing that trajectory models — even fairly simple ones — have been used for decades in serious aerospace simulation. What matters is the quality of the input data and the validation process, not whether the model includes every rotational dynamic detail. That’s what 6-DOF models are for — and even then, they too rely on accurate aerodynamic input to produce valid behavior.
Ah. "Yoyo mk2". "it's right because it is physics and that is unquestionable". Argument over. You based your argument on data which is physics so it's unquestionable.
Ive got some news for you. You built your premise on an assumption, that the physics model is being used all the time.
See those routines AI performs... See how they follow patterns...see how they snap together so neatly... or maybe you aren't looking.
Let me tell you something you apparently don't know or have ever seen. it will come as a shock.
Ai doesn't use physical models during all aspects of flight.
Have you even watched AI forming up and suddenly braking in the air 50 knots suddenly stopping like a car crash?
Have you seen AI brake on the runway?
Have you seen the points of the SFM curve when the AI gets stuck between two drag coefficients and snaps between them causing it to flip and jerk.
Have you seen the AI warbirds flying around with no engine floating at cruising speed, not losing altitude?
Have you seen the AI in this game perform something that is not physically possible, despite apparently using a model that is physically sound?
I think you don't play this game!
You don't need to be Sir Isaac Newton to know an apple falls down, it doesn't float. Physics is not the problem here. You are arguing about physics when the topic is software, where magic is possible and under that illusion is this game. You talk models but have assumed it's being used, at least all the time. I'm here to tell you they aren't, much like the people who think little 'mitochondria' come out of the nose of aircraft with radar...they don't either, it's software.
I don't want to hear about models that are not applying to this simulation, it is a worthless and impractical spend of my time when every year I report some strange behaviour where it might be the most accurate nasa supercomputer model using quantum mechanics for all I care but if a plane is floating upside down or even if it's just got the attributes of a rocket or a snail, no one cares, it's wrong, end of conversation.
-
9
-
1
-
-
11 hours ago, Nealius said:
Is there any way to tone down the lighting on the Fletcher class? They're super green.
I'm working with Hawkeye on his Discord to find the model that he did where the green UFO light was removed. Ive checked two his offered now but no joy.
If you join on his DIscord there's a bit of a mod renaissance going on. https://discord.gg/Uxypkx2j
and there's a few mods Ive never seen that look fantastic that are worth the journey.-
3
-
-
I've already got my AI Indefatigable Seafires and skin landing on the Essex. There's a post in hawkeye60's mods for a plugin that allows AI hook deployment.
TF57 had to copy the Americans who were well ahead of them in carrier warfare, but copy they did, fought with them, they did, right to Tokyo. It's sadly missed story, you dont get many Oscars for a supporting role.-
2
-
-
This was the same type of reasoning provided by ED, that their model is using real world data so the results are perfect.
I can and do edit SFM's and i'm doing some right now and it really doesnt matter what you put in to the model, it relies on the model being perfect, not the data.
You tweak it to behave in the game like something that works well. All of a sudden you broken it somewhere else. Same model, have to change the real world data to fit.-
3
-
-
On 2/16/2016 at 8:18 AM, Markindel said:
Thanks again to all.
Hi Eddie, I knew you'd guessed it right away.
I have also models of ships:
Glorious
King George
Queen elizabeth (battleship)
Renown
and other ships from the German and Italian battle.
But, before you think about what I do next, I have to solve the problems I have with the Bismarck.
as soon as I finish all the animations I have to make even the damage model, but I must be careful not to overburden the model, I fear a drop in FPS.
Apologies for the time machine post - HMS Howe and HMS King George V would look nice if Task Force 57 in the Pacific were to get back together for a reunion! Now we have a corsair and carrier the timing is better for resisting the Pacific and giving it a touch up
-
1
-
-
What is the impact when run on a connected client in mp from the pov of server and client being in sych? Not everything works or is designed to work like this. I've seen lots of occasions in MP many years back where clients run around invisible because they aren't synched.
I'd be glad if it did, but it's not an area I've found the simulation was strong in.
-
Mind That although you can run things on your host ID 0, it doesn't mean that ED made any network code for it for a connected client. Most mission editor toys are a single player convenience, like gates, they just don't show to clients, so health related stuff executed on the server may have no impact or make weird things happen.
The game wasn't designed well when it comes to multiplayer. I can imagine why ED doesn't want to make that code synchronised.
-
1
-
-
On 3/14/2025 at 7:06 PM, Whiskey11 said:
Going to dump this here and see if it helps you any... while the scope of The IADS Project is a bit more broad than Germany, we DO have most of the air bases and heliports in West Germany circa like 1991 pulled from an aviation airport publication for Europe.
https://github.com/Whiskey-11/The-IADS-Project
We also have a few of the more prominent missile bases (Pershing launch sites) and a few of the training ranges in Germany labeled, but it's not complete as that was a little out of the scope of our project.
West German NATO bases:
East German Bases:
Obviously the IADS project includes as many of the known locations for SAM sites in Germany in this time frame except some of the more mobile SAM systems. ED has said Nike isn't coming from them, so hopefully modders can fix that...
The chaos (Without Nike):
this is incredibly useful, thank you for bringing this to my attention. It's goign to take a couple of weekends to figure out the duplicates and overlaps and see which layer it fits in, but thank you!
-
I love hearing and reading about this stuff.
We've got our hands full just getting units in there just now, I will try to circle back to get the information later!-
1
-
-
Detmold please - huge Garrison at Hobart Barracks with small airstrip, gazelles and Lynx and CHallenger 1 when I went in '92!
-
5
-
-
Just by way of an update, I've got a lot of German data from a willing volunteer and we are in the process of merging that with the existing US and British data. The remaining list of things to do are;
- Call the KML done and post it to GitHub so that people can pull and fork.
- Perfect the script I have that extracts the KML data to a simplified csv.
- FInish the script I made that spawns a unit named something appropriate - name | type.
- Save the mission of all the spawns.
- Review innaccuracy - I'll find out how badly converting coordinate twice is going to really be on the map.
- Break it all back up into parts that would work for an STM file
- Add the STM's and entire MIZ to this thread and uploads section.
- Add the STM's and MIZ to GH so they can be refined in public.
- Drink beer and fly.-
8
-
-
22 hours ago, Don Rudi said:
Really looking forward to that file, as it will help us mission builders a lot. And I know how much work goes into it, I spent the last two days creating something similar for Lower Saxony alone
Btw, do you happen to know, if ED will give us a Nike Hercules for the Cold War era? Imho it is absolutely mandatory.I'd go with Northstars take on it, it would be faster to buy the high digit SAM team a lot of beer, and more certain.
The nuclear warhead option would be fascinating for DCS, right?!-
2
-
Save feature feedback.
in Wish List
Posted
This isn't related to the request or the post, but the way the save game feature works is it takes the mission file as it was originally, captures the unit placement at the time of saving, updates the route of the units as if they have been following their route (so you are in between wp 3 and 4 then your new waypoint on save is WP4 and your current position is WP0.) Wreckage is persisted (now). scripts and triggers and all ME settings are exactly the same as the original file, the only thing that changes is the positions and routes. However, this cant apply to anything you moved in combined arms or Game Master or Tacitical Commander, those routes are essentially lost and the unit will RTB if air or sit still if ground.
I didnt test scenery, I wasnt aware if that persisted I woudlnt be surprised if buildigns and briudges are handled.