DCS Features Wish List

[Poor mans sniper]

When you eject and touch the ground, ARMA 2 AH OP is ired and you have to survive until SAR or make your way back home, if behind the lines.

We already had this conversation somewhere, ARMA is a tactical shooter/vehicle combat game, and this isn't a tactical shooter.

[Poor mans sniper]

It would be awesome if you could call for back-up and have a few AI aircraft (type of aircraft depending on situation) take-off and lend you a hand.

EDIT: Sorry, double post :(

[nomdeplume]

It would be awesome if you could call for back-up and have a few AI aircraft (type of aircraft depending on situation) take-off and lend you a hand.

 

I think you'll be able to do this with the new triggers; looks like you can add radio commands so the mission could make a few AI groups spawn when the player issues a specific radio command. Not exactly sure how it's implemented, but this one feature opens a lot of possibilities! Can't wait. (Okay, technically I can and will wait. But only just.)

[Glowing_Amraam]

Might have been said before, but subtle low frequency vibrations in cockpit would add a lot of immersion to the sim - Check out the Payware B206 for X-Plane for the kind of effect Im talking about.

 

Ever flown in a heli that didnt shake 100% of the time?

 

Press "SHIFT-J" while in the cockpit. Vibrations, voila. ;)

[159th_Falcon]

Ever flown in a heli that didn't shake 100% of the time?

Yep, EC155B1

Well, technically, it was shaking when we looked at the Rotor Track and Balance data.

But only whit 0.05 IPS at its worst point during flaring.

Which already is barely noticeable.

The lowest was in slow cruise i believe, at 0.02 IPS.

 

To five an idea, helicopters like the S76B or the AW139 often are troublesome

to get under 0.15 IPS

[Bucic]

The debrief.log written by FC2 and DCS contains a wealth of data. It logs each weapon that was fired, when a unit was hit by a weapon, when a unit died. Unfortunately, it doesn't log some other crucial events or does not provide the information in a usable way.

 

This is my list of improvements to the debrief.log:

1. Add UTC timestamps to relate in game events to realtime
   
2. Add player names
   
3. Add unit type (vehicle, plane, helicopter, ship..)
   
4. Add unit name (Su-27, BMP-3, Mi-24V etc..)
   
5. Log actual game spawns (when a player actually enters in an aircraft into the mission)
   
6. Log actual game exits (when a player actually exits from the mission in an aircraft)
   
7. Log player connection information (IP, UCID)
   
8. Log actual kills (presently only hits and units dying are logged)
   
9. Add airbase coalition information
   
10. Add a trigger action that writes a string to the debrief.log to log non standard events from within the game
    

 

 

Most of these issues were encountered when making the 51st stats page.

+1

[Yellonet]

Immersion is what makes players come back for more

 

I know this is quite vague but for DCS: A-10C Warthog I would like anything that increases immersion.

The lack of immersion is mainly due to that you don't see or hear about there being a conflict or war going on around you, and this has been my main problem with "these" games since Flanker 2.0.

 

So, while taking on a few single missions to experience the flying and fighting, I could never muster up the energy to do more than that.

Flying and fighting has been very entertaining ever since back then and has become better and better for every new game, but the immersion factor has always been rather low in my opinion.

To me, and probably at least a few others, this makes playing through a campaign or even a long mission "difficult" because there's no atmosphere to get caught up in.

 

Some people obviously get on with campaigns and such without this atmosphere and fully enjoy the game, but then there are also people like me.

 

So, please, anything you can come up with to make the world less sterile is a good thing in my book.

Edited September 12, 2010 by Yellonet

[213]

vague suggestions are useless, basically.

 

what do you mean by immersion? do you want things exploding everywhere? do you want more vehicles firing at each other? i wonder how well your cpu will be able to handle that.

[CAT_101st]

I would like the ability to get the camra closer to the ground for better movie shots of ground troops shooting up at aircraft.

[Avilator]

I would like the ability to get the camra closer to the ground for better movie shots of ground troops shooting up at aircraft.

 

Or even a view down the barrel/launcher that follows the burst of rounds/missile when they are launched. Maybe?

[Moa]

The debrief.log written by FC2 and DCS contains a wealth of data. It logs each weapon that was fired, when a unit was hit by a weapon, when a unit died. Unfortunately, it doesn't log some other crucial events or does not provide the information in a usable way.

 

This is my list of improvements to the debrief.log:

1. Add UTC timestamps to relate in game events to realtime
   
2. Add player names
   
3. Add unit type (vehicle, plane, helicopter, ship..)
   
4. Add unit name (Su-27, BMP-3, Mi-24V etc..)
   
5. Log actual game spawns (when a player actually enters in an aircraft into the mission)
   
6. Log actual game exits (when a player actually exits from the mission in an aircraft)
   
7. Log player connection information (IP, UCID)
   
8. Log actual kills (presently only hits and units dying are logged)
   
9. Add airbase coalition information
   
10. Add a trigger action that writes a string to the debrief.log to log non standard events from within the game
    

 

Most of these issues were encountered when making the 51st stats page.

 

In addition:

11. Takeoffs and landings from aircraft carriers, cruisers (don't forget these, and oil rigs etc), and FARPS should be treated in the network scripts as any other runway takeoff. At the moment they are logged but the user-editable function in the network scripts is not invoked in all cases.

 

12. All events should include the 3D position (lat, long, alt) of the units involved. This allows things such as simulated probabilities for Search-and-Rescue and determination of A-pole and F-pole distances for launches.

 

13. Landings should include the side of the player and the side of the airbase/territory at the point of landing (since the airbase/FARP can change coalition due to a takeover). Landings reporting the closest airbase is ok, provided the 3D information suggested in #12 is included to distinguish 'landing close to an airbase' to 'landing at an airbase'; and 'taking off from a runway' from 'taking off from a taxiway' (antisocial! except in scramble situations). This is a regression from FC1 (which used to have such information).

 

14. It should be possible to correlate an initiator ID with a callsign. A function that could be called in the user-modifyable scripts would resolve this.

 

15. Chaff and flare release should be logged (if individual shells are, so should chaff and flare - for post-battle analysis).

 

16. Each event should have both UTC time (determined by the host's clock) for display purposes (in stats boards) and mission time-of-day (eg. to determine whether a carrier landing was in daylight, or at night [harder!] and can be also used to adjust flight durations to account for temporary admin-induced pauses in the game).

 

17. Both logs (network and debrief) should have common timestamps (with millisecond precision). At present one uses mission time-of-day and one uses time since the mission was loaded. Both logs should use have both UTC and mission time-of-day for every event (both to millisecond precision).

 

18. Every event should be self-contained (you shouldn't have to read any other events to determine everything you need to know about the current event). This means every event should include: timestamps, coalitions, callsigns, unit type, unique unit ID (needed for dynamic campaign), weapon names, 3D locations of all units, airbase/carrier/FARP name, event type identifier. Edit: This is useful so you don't have to maintain state between events for basic statistics - improving reliability of stats systems (if parser crashes and can't read one entry it can still read the others) and make them faster to process (real-time stats, which is the goal of the 104th stats system when released).

 

19. All information that is presently been added since FC1 should be preserved. For example, it is excellent to know the skill of an AI unit (with upcoming 104th stats uses this to adjust points for kills).

 

20. LockOn should never overwrite or delete any logs. Ever. For any reason. This means the 'cleanup' script should go or be configured off by default. The disk space used by logs is trivial in modern terms. Edit: Preserving all logs is important. We go through considerable effort to collect then logs so we don't want them deleted for any reason. Preserving the logs allows old data to be re-parsed in the case of a bug (which I have had to do in the past and allowed Case to do this in the last week or so) or a new feature that can make more use of existing logs.

 

21. A unique identifier should be placed in each network log and debrief log to tie them together. I recommend the same timestamp that appears on the mission file name, eg. 20100913-0845

 

22. Important: The debrief log should get a timestamp on the file name the same way that the network log does. That stops it getting overwritten on misison restart (which means an automated backup of the debrief log) and it is easy to see what debrief log goes with what network log. It is then easy to see what is the latest debrief log (using the timestamp in the filename), or even scan the directory for all the debrief logs that have not yet been processed. For the 104th stats it took me a while to do the same with a combination of LUA (by changing the network scripts, which is a maintenance hassle to integrate with each Servman version) and Java threads (my stats program that does the file renaming). Also note that I couldn't get the log file name/file name timestamp using LUA alone.

 

23. There should be a trigger action that allows writing to the debrief log. Oops, duplicate of Cases #10. Very useful, so repeated for emphasis.

 

24. Collisions should get their own event type, not appear as a generic 'hit' (you see this with aircraft collisions on taxiing and hard landings on carriers).

 

25. Better documentation/consistent naming of LUA functions and parameters. (I'm a professional developer, so I know I'm dreaming with this one).

 

26. The debrief log should include the mission name as an attribute of the mission start event (I got this slipped into the network log [thanks guys!] but it should also be in the debrief log header as well).

 

27. The user-editable scripts in the network scripts directory should be able to set and read (server-side) triggers in the mission at runtime.

 

For the 104th stats I had to add much of this information myself (thank good the system is now flexible enough to do this), but some information is still out-of-reach for us 3rd-party integrators. It sucks having to write the LUA to fix these things since it is now a maintenance hassle to adapt to each new version of DCS/LockOn and ServMan.

 

FC2 has made great strides in the logged information, but took some back-steps as well. I hope A-10C moves further ahead as well. In general it is better to log too much information rather than too little (as long as logs don't get above a few megs for each long-running mission, which they don't).

Edited September 13, 2010 by Moa

[power5]

vague suggestions are useless, basically.

 

what do you mean by immersion? do you want things exploding everywhere? do you want more vehicles firing at each other? i wonder how well your cpu will be able to handle that.

 

I think he means more in the radio comms. No idea what the typical chatter is like in war misisons, but would the pilot hear other pilots not in his group talking about what they are experiencing? I am playing the "fight back" mission in the Georgian Havoc campaign and the other flights never report anything about their missions or effectiveness. I have to press F2 to view what they are doing.

[sweinhart3]

Maybe a little bit of story line would be nice. The way the Deployment campaign in KA-50 was done, I enjoyed that. There was a story behind it and it felt more interactive. The GOW campaigns were just a bunch of missions. AI no longer talks to you and there was no real story line or sense of what was going on in the war.

[Moa]

Maybe a little bit of story line would be nice. The way the Deployment campaign in KA-50 was done, I enjoyed that. There was a story behind it and it felt more interactive. The GOW campaigns were just a bunch of missions. AI no longer talks to you and there was no real story line or sense of what was going on in the war.

 

You want a background storyline? well, what about some recent real history to get you in the mood?

 

These might be handy for some historical perspective:

http://en.wikipedia.org/wiki/Georgian_Civil_War

http://en.wikipedia.org/wiki/2008_Georgian_spy_plane_shootdowns (buildup to next war, aerial only as Georgians watch Russian preparations, so good to model in LockOn)

http://en.wikipedia.org/wiki/2008_South_Ossetia_war

 

and for a fictitious one:

http://en.wikipedia.org/wiki/Third_World_War

http://en.wikipedia.org/wiki/Able_Archer_83

[Bucic]

In addition:

11. Takeoffs and landings from aircraft carriers, cruisers (don't forget these, and oil rigs etc), and FARPS should be treated in the network scripts as any other runway takeoff. At the moment they are logged but the user-editable function in the network scripts is not invoked in all cases.

 

12. All events should include the 3D position (...)

.

.

.

 

27. The user-editable scripts in the network scripts directory should be able to set and read (server-side) triggers in the mission at runtime.

 

.

.

.

Wow! :shocked:

But I certainly don't mean the number of points but rather their depth and quality!

[Moa]

Thanks Bucic.

[Poor mans sniper]

An under-wing weapon release camera would be awesome.

[CAT_101st]

An under-wing weapon release camera would be awesome.

 

You can allready do that. Just learn all the view key options and it can be dun.

[Druid_]

Satellite/Live View for placing and orientating units in the Mission Editor.

 

Before I lose my mind through frustration when Mission Building.

 

Please.

[Poor mans sniper]

You can allready do that. Just learn all the view key options and it can be dun.

Oh, my Lock on: Platinum is still in the mail:P

Anyways, little kill markings below the cockpit in singleplayer for air-to-air kills would be epic!

[SilentEagle]

I would love to see 3 things:

 

1) Smoke state output via export lua (like you have with gear/flaps/brakes etc)

2) Smoke On and Smoke Off inputs instead of just a toggle switch

3) Smooth jiggle cam when padlocked onto an aircraft from either cockpit or an external/tower view. Currently you can use jiggle cam when padlocked, but even when you change parameters, the view snaps back to the object so quickly it's pointless.

[thisisentchris87]

How to improve this game.

 

What this game needs, in fact what this series needs, is dedicated server software. I don’t know if this has been mentioned before, but this game needs it. It’s an absurd design to have the hosting server also run as a client, there is so much needless and excess overhead. Perhaps this server scheme is the reason for the small amount of servers I see on DCS: Black Shark. Plus, it could be the reason for the somewhat high pings I consistently see. Now granted I’m connecting over Wi-Fi and DSL internet, but I can play Team Fortress 2 with 32+ players and have very few, if any, connection problems.

 

 

Not only do I want to see a dedicated server, I would also like to see it available in an unrestricted form. Or if that’s too much to ask perhaps it could be available as an option in the server set up screen, via a drop down menu. For example a use starts the multiplayer component of DCS: Warthog, they go to the server screen, they configure the server and select “dedicated server,” they start the server without the simulator component. The only thing the user would see is some form of limited GUI server management interface that doesn’t require high performance equipment, like the current system uses. However, consider making it unrestricted and separate from the retail software, it would make creating a server a lot more accessible and desirable. There are hundreds of servers for Team Fortress 2 and all run on dedicated servers, granted that’s a larger user base, but it could be because that anyone can download the server software for free and get a server running. I see no reason why ED doesn’t and shouldn’t have a dedicated server scheme.

 

 

To be blunt I would rather see ED make a dedicated server option than another aircraft. I don’t want an F/A-18 or whatever simulator or even a Scenery Update, I want a dedicated server. :noexpression:

It would benefit this community far more than anything.

 

In other news, the smilies here are bizarre. :music_whistling:

[sobek]

[...]

 

M8, not wanting to be rude but the sim is in feature freeze for months now, how do you expect ED to squeeze that one in? :huh:

[GGTharos]

What this game needs, in fact what this series needs, is dedicated server software. I don’t know if this has been mentioned before

 

It has been. It is on the list for some future module.

 

 

There are hundreds of servers for Team Fortress 2 and all run on dedicated servers, granted that’s a larger user base, but it could be because that anyone can download the server software for free and get a server running. I see no reason why ED doesn’t and shouldn’t have a dedicated server scheme.

How does TF2 even /compare/ to DCS in any way, shape or form?

 

To be blunt I would rather see ED make a dedicated server option than another aircraft.

Not going to happen.

 

I don’t want an F/A-18 or whatever simulator or even a Scenery Update, I want a dedicated server. :noexpression:

That's pretty close to 'it's just you' ;)

[Blaze]

Running as both a the host and a client since I am the lead on my team, I have NEVER had any problems with doing both at the same time. Smoother connections for everyone and more control of the server. Dedicated server is nice but there is NO problems with the way it is now. Internet speed is important and even with my pretty standard cable internet I can get a ~95 ping from one side of the US to the other, same with my teammates on my server when I host. And the pings are smooth enough for us to fly 18 inches apart at 400 mph while performing formation aerobatic maneuvers, and IMO that's pretty darn good. ;)