Jump to content

esb77

Members
  • Posts

    338
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by esb77

  1. If making a multiplayer mission with a client delayed activation group, if you call .activateGroup it can't activate the client group because the group table doesn't exist yet. There are workarounds, but the amount of workaround needed to perform a fairly basic mission function, spawning a player controlled group at a specified time or condition, is pretty ridiculous. If you're asking a mission maker, "What's a fairly challenging scripting task," I would argue that, "Spawning a player controlled unit in a multiplayer mission," should absolutely not be an answer to that question. Ideally, .activateGroup would just work when fed from Group.getByName(groupname) with no other intermediate steps needed, but there are legitimate reasons one might not want to create a group table for a group that may never be occupied. A method to look up a delayed activation unit placed in the Mission Editor and take its name to generate a group table that .activateGroup can take as input would be a reasonable intermediate solution. More generally, the biggest criticism I have of the Mission Editor and DCS Scripting Environment is inconsistent behavior across single player and multiplayer missions, and limitations of methods where the limitations are obscure and difficult to figure out. Using delayed activation and .activate as examples, if they were called SinglePlayerAI_UnitDelayedActivation and .activateSPDelayedGroup, then I'd have less of a problem with them. They'd then consistently and reliably do what they say they do, and instead of generating grumpy mission coders wondering "Why does this method not work," you'd instead get requests along the line of, "Hey, that's a nice function, do you think you could make a multiplayer version too?" I know that there's good reason not to change names of existing methods to avoid, so making an effort to upgrade existing methods that aren't general in how they act across SP an MP to be general would be good, and then going forward, if new limited use methods are created, reflect that in the naming. Then if they are later upgraded the upgraded version can be named without an indication that it's limited scope.
  2. So in scouring for more info I found a solution: migGroupFromTable = migGroupsToActivate[1] nextMigGroup = Group.getByName(migGroupFromTable) nextMigGroup:activate() That does what I want, grabs a value from a table, and activates the group with that name. But I still don't understand why the general structure of: trigger.action.activateGroup("groupName") --or trigger.action.activateGroup(stringVariable) -- where stringVariable == "groupName" doesn't do basically the same thing. I'll look into it some more, because if trigger.action.activateGroup(Group) actually wants the group mission ID number, or the GUID number of the group and not the name, then I'm doing my most frequent ME script bug of wrong format of input into a function. I probably also need to go back and look up the difference between . and : in LUA, which I looked up two days ago and have already forgotten. Something about functions that pass self as the first parameter I think. I'll update if I manage to un-confuse myself. I managed to get it to work with this --Modifying it again, trying trigger.action: trigger.action.outText("testing activate method", 20, false) migGroupFromTable = migGroupsToActivate[1] trigger.action.outText(migGroupFromTable, 20, false) nextMigGroup = Group.getByName(migGroupFromTable) trigger.action.activateGroup(nextMigGroup) trigger.action.outText("Group getbyname got: " .. nextMigGroup, 20, false) which throws and error on the final outText and I think reveals my problem. trigger.action.activateGroup wants the Group object table, not the Group name string. Using .getByName gets the right input, and with that it works.
  3. I've got a mission I'm working on where I'm trying to have delayed activation client aircraft. I've done missions before where I've used the ME triggers to do this successfully, but the conditions are more complicated, and ideally I'd like to spawn in up to 60 or so units and therefore I'd rather do the activation with a script, instead of creating a massive amount of triggers in ME. So my approach so far as been: Create a table of groups to spawn in a ONCE At Mission Start trigger. --migSpawn Test code -- objective: assuming that a global variable named mig29ActivationIndex has been initialized with a value of zero at mission start -- have a reapeating trigger activate a series of delayed start groups in response to a specific condition -- and display a counter of how many groups have been activated so far. --Create an integer indexed table with the names of the groups that are to be spawned, note for performance reasons this probably shouldn't be in a reapeating trigger in the actual mission, create the table in an initialization trigger and make the table global migGroupsToActivate = {} --table with names of mig groups to activate. local groupRootName = "Mig " local numbGroupsInTable = 5 -- enter how many groups of migs are to be delayed activated in the mission local groupIndexStart = 1 local indexValue = 1 --if the table values are Root_i this is the value of the current subscript for increment = groupIndexStart, numbGroupsInTable, 1 do -- starting at the index start, stopping when the index is equal to numbGroupsInTable with a step size of one table.insert(migGroupsToActivate, groupRootName .. indexValue) -- in table migGroupsToActivate for the next integer key enter the value groupRootName concatenated with the current indexValue indexValue = indexValue + 1 end local tableValueTest = migGroupsToActivate[4] trigger.action.outText(tableValueTest, 20, false) --checking that the table of mig groups exists and has valid value fields This part seems to be working. I get returns from the outText action that look like what I expect them to. Then in a separate trigger I have an if then structure to examine a global variable, and if true, advance a counter that starts at 0, and then activate the group from the table of group names along with a message to let me (and eventually players in the mission) know that the unit has been activated and is available. if speedViolation > 1 then --if a speeder was detected in the speed monitoring section mig29ActivationIndex = mig29ActivationIndex + 1 --increment the global variable that counts the index of how many mig groups have been activated. trigger.action.outText("Activation index = " .. mig29ActivationIndex, 20, false) --debugging line, test that index is advancing properly local nextMigGroup = migGroupsToActivate[mig29ActivationIndex] --use the mig index as an input to find the i th group in the mig groups table trigger.action.outText(nextMigGroup, 20, false) --debugging did I capture the value from the groups table trigger.action.activateGroup(nextMigGroup) --activate that group trigger.action.outText("Mig 29 unit: " .. mig29ActivationIndex .. " activated.", 20, false) --message players that the group has been activated. speedViolation = 0 -- reset the speed violation variable for the next monitoring loop. end It didn't work of course, which is how all my lines of code normally start out. I have debugged as far as trigger.action.activateGroup(nextMigGroup) and everything up to there seems to be working as I expect. I didn't entirely understand the error message: So I made a new mission, set up a ONCE trigger, TIME MORE (10) condition, and Do Script trigger.action.activateGroup("Aerial-1") to have the simplest possible version of the activate script, and I get this So having tried to simplify this as much as possible, it looks to me like when I use trigger.action and append .activateGroup to it, DCS looks for a method called "activate" and can't find it? So the questions are: Am I interpreting that error correctly? and How do I help the scripting environment find the activateGroup method? I'm getting reasonably good at figuring out how my incorrect input types make script functions not work (I get lots of practice), but not being able to call a script function is a first for me, and I'm not quite sure how to approach debugging that. I'm working off of https://wiki.hoggitworld.com/view/DCS_func_activateGroup this as documentation for activateGroups.
  4. This is how it works for me. I'm starting to get to the point where I can feel those first four slices shrinking though. Also to the point where I can start doing things the canned scripts in the ME either can't do, or can do but would be tedious beyond belief to create triggers for every unit instead of just using a loop in a custom script.
  5. System failures in MP would indeed be lovely. Having more parts of the systems/damage models hooked up would be nice too. Things like broken rudders, flaps, ailerons, airbrakes, etc. There are lots of things you can break with bad flying or from weapon hits that the failures system doesn't capture.
  6. Does anyone know how exactly this reads the file structure for loading the misison? I.e. static or relative? Trying to figure out if there are going to be issues loading with this trigger if the mission is moved between computers with different file structures. If the target file in the ME trigger action dialogue box is: SampleReloadMission.miz will changes in the bolded section below cause problems? C:\Users\Myusername\Saved Games\DCS.openbeta\Missions\NewMP_MissionsTestFolder\SampleReloadMission.miz It's going from my personal computer to someone else's dedicated server, so some differences in the file hierarchy are likely, for example they won't have the mess of folders where I sort different new, old, and under construction, MP, and SP mission files,
  7. Did you change it from a single player mission with the plane controller designated as Player to a multiplayer mission with the plane controller designated as Client at some point? The AI not shooting at you below a certain hitpoint threshold is a known issue in multiplayer missions. I haven't checked recently to see if it's working that way in single player too right now.
  8. Hm, well I'm not sure if the server in question will have SSB or not, so I was thinking of primarily solutions that could be implemented in the .miz. I didn't know that the hook scripts were a separate category that needed to be implemented in .lua files in a particular spot in the server's install directory in order to be loaded and used. Thank you very, very much for pointing that out Dangerzone and cfrag, it's a huge minefield that would have had me very frustrated at, "why is all this cool stuff not working for me." In checking out hooks and a brief overview of how they work, I stumbled across documentation for the DCS Singleton net. Which has the force slot script. Apparently added in 2.7.6, so pretty new. So option 3, or a 2 & 3 hybrid look doable even stand-alone. Just need to make sure I follow the Singleton documentation, and not the Hook documentation, though I'm not sure if there's actually any difference. I'm sure SSB is the quickest, easiest and most reliable approach, and that'll be my backup plan, but I think I'll have a go at seeing if I can get the behavior I want from inside .miz file. At this point, even when I try things that fail, I'm learning so much from each failure that it's sort of worth it, and I fail enough that an extra failure or two doesn't really slow me down much because I'm already so slow. I'll try to remember to post an update here once I've got results of some sort. Thanks for taking a look, and for the advice.
  9. I think it can be done, probably in multiple ways, but I don't know enough to tell the difference between good ways and bad ways. Desired behavior in a MP mission: On no-fly-zone violation (any of coalitionA in zone), for each violation v1, v2, . . . ,vn, spawn one Coalition B fighter client slot, parking hot, with a specific payload. If one of these client fighters dies or lands, it should not be able to respawn/rearm. Basically I want a single-use player controlled aircraft slot to spawn based on a trigger, and become unavailable again once the player is done with it. I'm considering 3 different approaches to solving this, and if anyone has good advice on one of them being obviously better than the others, or all being terrible compared to option 4 that I've never heard of, I'd appreciate any guidance. I'm only about 10 days into the script/LUA rabbit hole, an I'm still not sure I've found a complete set of documentation yet (have Grimes's wiki and learned about script/Hooks docs in DCS install from looking at Ciribob's SSB mod). Oh, and of course the LUA project wiki. Approach 1 Base all the desired units at one airfield and increment warehouse weapon amounts on each violation. This just controls missile numbers, doesn't worry about number of planes or whether they can respawn, but unarmed sorties aren't that effective so it should have the same effect more or less. Haven't yet found any DCSscripts that look like they can be easily combined into a LUA script to increment/set the number of available rounds of a specific weapon as a trigger action. Possible workaround, spawn AI units on short final and hope they despawn correctly after landing so that DCS increments their payload into the warehouse. Sources have mixed reports on if this works, I haven't tested yet. Approach 2 Activate - deactivate groups. CoalitionA unit entering zone sets flag v_i, i=1,2,3,... Switched condition Flag v_i activates delayed activation group g_i with single unit with desired payload. Switched conditon Flag g_i monitors, death, crash, or landing and deactivates group g_i if Flag g_i = true. Activation works for me, deactivation is very inconsistent, not sure why, though single player, fly option from Mission Editor, and MP server all seem to behave differently maybe? Need to test more, but I have problems where I'm able to spawn back into a group that should be deactivated. Also having a player in the plane seems to prevent deactivation. Sure, explode unit can solve that, but it's not an elegant solution in terms of wreckage on taxiways/runways. Approach 3 Steal from the last few lines of Ciribob's- Simple Slot Blocking, ie. use the net.force_player_slot(playerID, sideID, slotID) -> boolean to force kick to spectator in MP, to just boot players out of the slot with a message explaining it's unavailable if flags monitoring whether or not the aircraft has been used are true and the death/landing/despawn flag(s) are also true. Using the kick function from 3 also seems like it might be an option for making 2 work more consistently. Any thoughts?
  10. For a military simulator it would be very nice to be able to display mission tasks accomplished or not accomplished to the players, better than DCS presently does. For all its faults and limitations, in the Mission Editor it's fairly easy to set flags to keep detailed track of things that have or have not been accomplished in a mission. Getting those results out to players in a convenient, on demand, human readable format is a nightmare. A UI element, that would take a Mission Goal Mission_Goal_Name(score, coalition) So say an example: Save the fuel truck(10, BLUE) and an accomplished/not accomplished set of the associated conditions: for example: UNIT DEAD(EnemyArmor1-1) and UNIT ALIVE(FriendlySupply1-1) with a script or dialog entry that would let the mission designer assign the conditions a text string as a name to be reported to the UI GOAL CONDITION(1,"Armor killed") = UNIT DEAD(EnemyArmor1-1) and GOAL CONDITION(2,"Fuel Truck Alive") = UNIT ALIVE(FriendlySupply1-1) where the output would be like this if both the enemy armor and the fuel truck were still alive: Mission Goal Scores Coalition Blue Coalition Red Goal Points Objectives Goal Points Objectives Save the fuel truck 0/10 points 1 Armor killed false Nul Nul Nul 2 Fuel Truck Alive true Code only used to preserve column alignment here, obviously you'd want to have some sort of GUI display set up for the various fields. Probably a check mark or other graphic for the condition display rather than a print out of the boolean value. I suppose you'd probably also have to limit the number of goals per coalition, and the number of conditions per goal to keep the display reasonably readable. At any rate, I think this would be a tremendously useful addition to the current scoring functionality which is really just a kill counter. Note, I have no particular preference about whether this sort of function would be integrated into the existing SP and MP score displays, or implemented as a completely independent UI and keybind.
  11. If clever in route planning often you do not need to actively reposition the vehicle before lazing, operating radar, or shooting. The way it works now is: 1) enter vehicle, 2) vehicle stops 3) player takes control or 4) goes back to map 5) resets route 6) commands vehicle to follow reset route, 7) return to F1 view 8: puts vehicle in gear 9) engages autopilot 10) finally get to laze, irradiate, shoot etc. The way I want it to work is to go from step 1 directly to step 10, skipping everything in between by having the autopilot defaulting to stay on rather than turning off. It doesn't take long to do all those intermediate steps, but it's long enough to interfere with a CA operator's ability to be sneaky, devious, and downright evil, especially in some air defense applications. If you have autopilot default to stay on, and have it turn off at player steering/throttle/brake inputs, then the player gets to go from step 1 to step 3 or from step 1 to step 10 without an administrative hassle that allows AI or human opponents time in which to shoot them. It's not a huge deal, but it is a minor to moderate annoyance if you want to push the limits of what Combined Arms can do. Basically for times when you need that one unit to be smarter than the AI for something like 5 to 15 seconds. Jump in, help, jump out is really useful, but it would be more useful if you didn't have to spend half of the time you intended to be in the vehicle redoing a waypoint route in F10. It has nothing to do with physics. It has to do with wanting finer input resolution than a binary 0% or 100% with no intermediate values. Driving precision is better if you can continuously adjust input amounts instead of just stuttering between 0 and 100 to make a very crude discrete approximation to analog inputs. I want to have input curves, not input stairsteps. Mostly looking for making it easier to avoid overshoots when driving fast in tight urban environments. I'd love better vehicle physics, but this isn't ARMA, and I'd settle for improved control input for the game "physics" we currently have. CA is interesting, but really the ground vehicles in DCS are just targets/objectives for aircraft to do things to. Physics for them may not be reasonable. Improved control interface for what they already do, may also not be reasonable, but it's maybe a smaller more practical request than proper physics.
  12. Yes, pretty much this. There are a lot of situations where for movement you'd just stay in F10 view and play with waypoints, without ever jumping in to drive a vehicle. However, it's often potentially very useful to shoot/laze/operate radar/observe from a vehicle that's in a group that's already moving on a waypoint route. Oddly, the lead vehicle often has the best view of the battlespace due to a lack of obstruction from other units in the group. Even in other vehicles in the order, if the route is a road following route that is constrained by terrain or structures, having one vehicle stop can create a very disruptive roadblock, not to mention that stopping makes a much easier target. I think that in general, it would be more useful to jump in and have the default behavior be autopilot continuing to operate, and have driving inputs cancel the autopilot in the same way throttle or brake cancel the cruise control. That way it's responsive if you're jumping in to drive, but doesn't create disruption if you're attempting to enter the vehicle for some other purpose.
  13. I'm not a pilot so there may be missing steps, but I think the procedure for GA in a plane with the 109's level of equipment would be along these lines: Tune radio to VHF 121.5 (optional if you know local ATC freq., which you probably should, in which case just tune to ATC). Pick up microphone (if not using headset mic) and press transmit key. Say, "Mayday, mayday, mayday," and then give aircraft identifier. When ATC asks if you're declaring an emergency say yes, and tell them that you're a VFR aircraft in IMC. Then you'd ask ATC to give you emergency assistance using their radar to vector you to a divert field that is not covered in fog. If the the above procedure did not work, and you didn't have enough fuel to wait out the fog or fly to acceptable emergency landing terrain with VFR weather, you would almost certainly die in a fatal CFIT crash. Taking a VFR plane or VFR pilot into IFR conditions isn't quite a death sentence, but it is a life and death emergency, and prospects for survival are very poor. In the event that you survived I believe you'd also have to fill out an incident report. Definitely recommended to make all your suicidally stupid aviation mistakes in a simulator rather than in real life though. Edit: There also might be a free lecture after landing (if you survived) on the foolishness of not installing a Mode C transponder and ADS-B on your vintage warbird.
  14. If you have a control input device where you can bind your trim to an axis, you can just go into the axis tune menu for that axis and desaturate it. That's what I usually do for trim and also for a lot of planes with target designator boxes. If you have some but not enough axis inputs on your HOTAS, you can use a modifier or several to work around that, though it's not ideal because it locks out the base function for that input while the modifier is active. If you're just working with momentary switches for trim, then yeah, it's annoying.
  15. This is a feature that I'd like for mission making. There are so many scenarios where a two faction system is inadequate. It doesn't have to be a huge number of course, but at least five.
  16. At a guess you're overspeeding the gear. Not sure what the official max gear up speed is, but I'd recommend trying to get them up by about 350 km/h or 195 knots IAS. What I would like on the Su-25 gear is improved ability to land and taxi on grass, and a wheel brake axis (or two).
  17. Interesting observation I had looking at this thread. I think when people are talking about "Core game function" there's some disagreement on what the core function is. If you look at DCS World as an aircraft simulator, then there is a lot of work on core functionalities. Typically there are significant upgrades on something, or even many things, coming out every month to two months. The changelogs bear this out. If you look at DCS World as a warfare simulator, and feel that once an aircraft is in game and more or less functional further updates don't really count as "core," then there's a reasonable argument that there have been long periods of inaction on core functions. Especially if you define core as anything that's key to your personal sense of immersion and/or fun, which are some what more subjective. What's more "core" in a list of: armored vehicle damage model, naval damage model, AI dogfighting logic, or air defense AI can depend heavily on what sort of aircraft and what sort of mission a person prefers to fly. I'd say that on balance, DCS has been, is, and for the forseeable future will continue to be, primarily an aircraft simulator. That's the focus, and they do a really superb job of it. For simulating everything else, well it's nice when stuff works well, but it's probably forgivable if for example my attempt to make a fun and engaging RallySyria.miz failed because a HMMWV couldn't make it up a hill that it would have had no trouble with in real life. DCS tries to be a high fidelity simulator, but it's a narrowly targeted high fidelity simulator.
  18. Requests I'd add: Vehicle movement controls, left/right axis Vehicle movement controls Brake axis. When taking control of a vehicle that is on a waypoint route as a JTAC or Tactical Commander, instead of defaulting to disabling the route and stopping, default to the vehicle continuing to travel on the active route on autopilot until the player actively takes control. The current behavior can create havoc if you grab a unit in a convoy in tight quarters.
  19. Slingloading animals is a thing in real life. It was a classic staple of '70s and '80s wildlife documentary TV shows. Of course the cow slingload should be based on a generic large quadraped slingloading API so that if more large animals are introduced slingloading can be easily added to them as well. There are some obvious possibilities after all: Warthogs Rhinos Wild horses Crocodiles Tigersharks aren't quadrapeds, but whales sort of are on a technicality, and the shape is similar enough that I bet you could make it work.
  20. You can also center the Track IR cursor (as displayed in the track ir program interface). Setting a sufficiently large central deadzone can make this easier. Target lock in Combined Arms can also somewhat compensate, but TrackIR cursor has to be close to centered before targets can be locked. It's difficult and annoying though, so just pausing TrackIR, default is F9 I think, while shooting is the easiest workaround.
  21. Fooling around with some CA air defense missions shooting down heli's, I noticed that Shilkas and Tunguskas could not shoot down a CH-53E Superstallion with guns. Strelas hit the CH-53E, but appeared to do no visible damage. To see if it was Combined Arms specific I tossed a Su-27 into the mission. R-27ER, R-27ET, and R73 missiles all worked fine, however cannon rounds appeared to have no interaction/effect with the Ch-53E.
  22. I seem to recall that in the mission editor there's an option to configure the aircraft in an air start. I think it's in the same menu as the fly mission, and it basically puts you into active pause so you can configure the plane, then you exit back to the editor to save those settings. I may have details wrong given that it's been years since I've used that feature, as it's generally easier to just put the plane in a position and at a speed where there's enough time and space for the pilot to configure the aircraft to their own tastes. It may not be the module that you need to direct your ire at, but a mission author that is cutting corners. Though to be honest, it has been so long that I can't say for certain that aircraft configuration as a feature still exists, as the ME has gone through several major updates since I last used that feature.
  23. I haven't troubleshot the issue all that much other than to check that Win 10 is updated, and that my driver is reasonably recent (probably not the absolute newest). Always loads well to menu screen. Always loads the missions to the point where I can hit the FLY button. Flies nicely for anywhere from 20 seconds to about 5 min, then crashes, though sound keeps going after the crash. Severity of crash varies, sometimes I can CTRL-ALT-DELETE out to task manager and generate a crash log, other times it's just a power off hard reboot of the computer. Not too fussed about it at this point, as I regard 2.5 release as really still an early to mid Beta as far as compatibility goes. Log attached dcs.log-20180716-231322.zip
  24. I'm on a older notebook that's getting a bit creaky for DCS, but I'm getting a few minutes of really nice gameplay followed by crashes of varying severity. Haven't had time to do trouble shooting other than setting the GPU settings on my machine from application aware (which tends to default to integrated graphics no matter what the program is), to forced use of the discrete video card. First crash ended with DCS sending in an automated crash report, second involved End Task via task manager, third neutralized task manager enough so that a CTRL-ALT-DEL restart was required. I'll monkey around a bit more and post further info if any of the standard remedies produce visible changes. This is with DCS 2.5.0.15365
  25. The radar will be illuminating the chaff as well as the target airplane. The radar illuminates a volume more or less centered on the target, and unless the plane has moved a significant distance from the chaff it has deployed, the chaff will also be within that volume. The reason the radar has to illuminate a volume is that the target is moving, and can change direction unpredictably. So radar has to illuminate a large enough area so that no matter how the target maneuvers the target will still be well within the area of illumination, otherwise it would be very easy for targets to evade all radar locks by maneuvering a bit. The inaccuracies in the sim have to do with how seeker vs countermeasure situations are resolved. In real life there are a large number of factors of signal strength, signal characteristics, and sensor limitations that determine if the real target or the countermeasure is more attractive to the missile seeker. A lot of that information about that is not publicly available, so DCS uses a simple probability test where each countermeasure has a 0.x chance to fool the seeker, modified by a few parameters. It leads to missiles sometimes hitting when they should miss, sometime missing when they should hit, and it rewards pumping out large volumes of chaff and flares more than it really should. The community consensus seems to be overall that missiles should be a bit more deadly, a bit longer range at high altitude, but that with professional quality piloting there's a high probability that most A2A battles are likely to resolve in the WVR arena. The general advice is to practice flying like a real combat pilot, as the trend in DCS is toward increasing realism. The real techniques generally work well even against the not quite realistic elements of the game, and when those elements are revised to be more realistic, you don't want to have a collection of bad habits that only work against unrealistic game features. Practicing techniques that are game oriented has given a lot of people nasty surprises in the past when a patch has increased realism and what used to "work" is suddenly suicidal. I'd recommend hanging out with some of the Multiplayer realism oriented groups that work on realistic combat flying. There's a lot to learn, and having skilled teachers really helps a lot.
×
×
  • Create New...