Jump to content

Exorcet

Members
  • Posts

    5092
  • Joined

  • Last visited

  • Days Won

    6

Everything posted by Exorcet

  1. I'm not sure what you mean. No one is asking for magic. The bug is that the gear breaks by being in contact with the carrier. That's clearly wrong. I've visited carrier museums and the Air Force planes on display don't fall apart out of fear of a slightly rocking deck. No one is asking for modifications to make the Viggen carrier rated, just to fix an unrealistic issue.
  2. Yes, that's the point. They underwent testing. Why can't we have a fiction Viggen carrier test program? Could at least make an interesting mission out of it. It would lack some of the real details of course, but sometimes you make due with what you have.
  3. Sure the Viggen isn't a carrier plane. But neither is the U-2 or C-130 and they've both done carrier operations. This might not be a huge priority, but it's a valid bug and should be fixed.
  4. Indeed it may not be extremely popular, but not everything has to be. Integration with CA would be a good idea. If there is concern over being limited to a downed pilot, then don't enforce being limited to just the pilot. Perhaps the player could jump between pilot and friendly infantry, or one of the crew of the rescue chopper. CA already allows jumping around between various units. I also wouldn't label DCS ground forces as a subpar experience. The ground units themselves are simple, but the air units aren't. DCS is superior in modeling that aspect compared to most other games, so what is subpar depends on which components you're interest in. That will in part depend on the cost. Something that is zero cost pays itself back even if there is zero return. I don't know where this project would stand in terms of development cost, but if it can worked on over time in small steps that could make it easier for the developers to deal with. That said, looking at this as an addition to CA and CSAR I do see some definite value in it even for the players that wouldn't want to sit around with their downed pilot for the entire duration. You could build situations around the feature to cut out whatever perceived boredom is present, and by allowing players to choose how much they interact with the feature you prevent it from being overbearing.
  5. We could have a few more options. Orbits always turn left, which can be limiting. Why not a turn right option? Flights always stick together during the orbit when in a CAP situation they could split in to two flights so that there is always a radar looking at the expected threat direction. Radius options are welcome as well, I wonder if instead of having a separate combat orbit option, we could add a turn radius input to the current orbit task?
  6. As long as it's not enforced, it should be fine. If there are options then missions/servers can be set to fit the players within. It could even be set on a per person basis. Player A would be set to autorespawn on eject while Player B would take control of the downed pilot.
  7. Besides the limited and slightly clunky mobility of the pilot in DCS, the waiting is fine. Not everyone minds something taking a while.
  8. A trick that works for FF planes is to R Atl + J out and then back in. Instant start up, no wait for align or anything. It might work for FC too, not sure. Only works in single player.
  9. What about using get velocity? You should be able to multiply the values for it by (desired time - current time) and then add to the position components. I haven't tried to do something like what you're attempting, but that seems like it should work.
  10. I don't know the exact context for your server, but if it's possible to pass information around outside of the mission, only the relevant players could be told how to input choices correctly. An example would be entering a password after the choice is made. The password could be a flag value randomly set on mission start. This might work for a private mission. For a public mission, it might be a hassle. Entering it is also a bit of an issue as if it's done by flags it would either need to be entered one digit at a time through the F10 menu or it would need to be a simple password to fit into the F10 list. It's not a great solution admittedly, but if there is no other approach, maybe it could be worth experimenting with.
  11. This is easily doable in ME as is, but the interface makes it more work than it has to be. There are many similar cases where a feature to directly control variability in some aspect of a mission would be nice to have. Along with group size, things like weapons carried, positions, and routes would be great parameters to make uncertain to the players participating in a mission. One good way to enable this might be the inclusion of variables in the ME. We can use variables indirectly with scripts, but having them built into the ME itself would make things much easier for mission builders.
  12. It's a good idea, but also has some problems. Namely weather is part of mission planning. Completely random weather can be horrible, making missions unplayable. You're not doing ground attack in a P-51 with overcast and fog or in the middle of the night. Multiple weather possibilities for a mission is a great request, but I don't think random is the way to do it. I'm not opposed to a truely random option, but I think it's secondary to things like: -List of preset weather choices -Random evolution of weather from a given starting point The difference between random and the other two is that they can weed out extremes that would just result in the mission being cancelled in real life.
  13. The menu needs a total overhaul. Weapons and fuel status is needed. We need second element commands for all planes. And I'm strongly in favor of a revised menu that makes giving effective commands easier:
  14. Those things can be used, but they have their own problems. This has been requested before. One of the options is a maintenance setting for aircraft. So we could choose say 100% (factor fresh) or 0% (plane is on its last legs). The former would give max performance, the latter would see reduced engine thrust and increased drag, reduced g limit, reduced radar range (maybe avionics, engine, etc could have their own settings). I think it's a good option, I just don't know how hard it would be to add to DCS while being realistic. Though to be honest when concerning the AI, a simple model would probably work.
  15. Placeable light objects are something I've found myself wanting as well. The best that can be done currently is to place the one or two vehicles with illuminating headlights as lights, or to use illumination flares. Both have issues though. For helipads though, there should be lights built in with the option to turn them on or off, it would save on the object count in missions and mean we only need to place the helipad and not many lights (though if the helipad lights were toggable, they could be toggled off and lights could be placed if the mission maker so wanted).
  16. Data has been sent.
  17. Comparing AB to Mil in acceleration it looks like it's probably thrust. AB accel is much closer to the real jet, especially when supersonic. Subsonic accel was slightly underperforming, but that was probably because of imperfect flying when the jet is close to stall at the low starting speed.
  18. For a while now I've felt like the mil power performance of the F-16 was a little low, though I chalked it up to the DCS version being Blk 50 as the GE engines favor AB over dry thrust. However I did finally get around to do some testing and it looks like there is a lack of thrust/overprediction in fuel flow even taking into account the F110's. I have tracks attached, though due to forum rules I am not posting the source info. I can send it via message. Summary of the issue: Testing at DI 102 at 34015 lbs weight to compare to data at DI 100 at 34000 lbs weight DCS shows increased Delta between speeds when accelerating under full mil power. This not only impacts acceleration, but climb and cruise, so the F-16 has a harder time getting to optimum altitude and uses too much fuel when cruising. DCS fuel burn at 510 knots is approximately 4200 PPH while the actual value should be just under 3900 PPH. Ideally some more testing is needed to see if this is more of an engine issue or drag issue, and it should be tested at more speeds, altitudes, and weights, but the condition that I did test is an important one as it's relevant to the F-16 in a CAP role. F-16CFuelFlow_35000FT_102DI.trk F-16CMilAccel_30000FT_102DI.trk
  19. You can use "time since flag" to get what you want. So for example 1, Target A is hit > flag A on, then flag A = true > explode Target A, time since A = 10 > smoke on B, time since A = 15 smoke on C.
  20. Have you tried AI Task Set to see if it is more reliable? Does the AI have any other tasks? Task set will wipe out the AI's route, but it should also eliminate any other tasks that may be causing a conflict. You can pass a new route to the AI via script if necessary as well.
  21. This topic comes from my experience creating missions. DCS has a powerful flag system that can be used for many things, but I keep finding that I need scripts to trigger flags for specific things. One example is signaling that the AI has completed its mission. Take for example AI on a strike mission being escorted by the player. It would be ideal for the AI to communicate the completion of its mission to the player so the player knows to leave. You can do this with triggers but the options for doing so aren't ideal: -Target destroyed > requires strikers survive, attack target, and hit target. If this is not triggered there is no message to indicate that something went wrong -Bombs in zone > Can be falsely triggered by bombs from other aircraft (and possibly jettisonned bombs, I don't remember now) is also finicky when you need to evaluate multiple bombs (and you need to consider what happens if a plane is destroyed and a different number of bombs than expected enter the zone). -Group in zone > You can check that the AI is close to target, but then this will go off even if the AI fails to engage its mission The solution that is best is to write an event handler that looks at multiple things. It's great that this is an option and it works well, though sometimes there are debugging issues and even with a library of scripts it seems like I somehow always find a need for something new. An alternative would be to add some additional AI communication options to missions and flag triggers: Message on Task start/end - Tell the AI to send a message (or use the text messages) when a task is started or finished, or a certain amount of time after the start/finish Message when under attack - AI (or text message) announcement that they are under attack or even just being tracked by hostiles. Message when unable to perform mission - Message when losses are too great to continue mission. Might also apply to fuel or weapons. Ideally these would have their own prerecorded radio messages so they would be played by the AI naturally. Some emotion would also help from just having these messages fade into background radio chatter. For example when taking losses they should sound concerned and not speak in a flat tone. Tying to radio would also allow the messages to be tied to frequency properly, enhancing realism and immersion. Additions like this would be a huge improvement for complex missions where the result isn't scripted and there is some intentional ambiguity in the design of the mission itself. The player can't be expected to work in a vacuum and needs to help from allies to build a picture of what is happening in order to respond correctly.
      • 1
      • Like
  22. Difficulty is part of the point, but adding smart SAM behavior doesn't have to take away our options for setting up AI. They can still have skill levels, alarm states, triggered actions, etc. We can also control how many there will be and if intelligence is provided on locations. Ideally we should be able to go right back to static always emitting SAM's (may be useful for training missions) even after this change. The new behavior could be tweakable as well with options for SAM aggressiveness, reaction times, etc. Things will be perfectly workable as long as all AI units are brought to a similar standard. Smarter SAMs should have to deal with preemptive AI SEAD launches, jamming, and the fear of being destroying.
  23. Checks out for me, AI was able to fly through mountains at 200 AGL without crashing.
  24. This may not be desirable. Modules may be uninstalled for more than one reason, and some people might install and uninstall as needed. Seeing the full server list can also give you an idea of how popular a module is which can aid in buying it. Being able to store settings sound good but default I'm less sure about unless maybe it is very clearly highlighted. Being able to see all slots is useful. You can tell where most players are operating and what they're flying. Example you only own A-10 and want to know if CAP is around. If all the fighters are hidden, now it's harder. A lot of these would be fine as options, but as changes to default behavior they could cause problems.
  25. I think the SAM issue is one of the larger ones in DCS currently. From what I gather, ED seems to think AG is preferred to pure AA. Maybe that's true for most players, but I find it hard to get into AG with SAM's as they are. They barely do anything to warrant the I in AI since they just sit emitting until something gets close enough to be fired upon. When the Hornet came out I thought SEAD would be the most fun AG mission to fly, but it turns out it takes a lot of setup to make SAM's exciting. While SAM systems could be improved massively in a lot of areas, I think as a first improvement they need is having some kind of life to them even more than they need detailed systems or radars. At a minimum they need to try to hide emissions and work together with other radars around the map. That alone would make them many many times more engaging and threatening than they are now without putting a burden on mission editors to spend forever setting up triggers or IADS scripts. Then of course, like all AI, they also need some human fallibility. Without that we run the risk of going too far the other way and creating nigh unbeatable super weapons. Ideally some delay time in communication between units/groups, uncertainty on the part of the AI on what they're shooting at, especially if friends and foes are in the same area, and some kind of aversion to being shot at by the enemy.
×
×
  • Create New...