Jump to content

FlightControl

Members
  • Posts

    2070
  • Joined

  • Last visited

  • Days Won

    3

Everything posted by FlightControl

  1. assumed this would be the issue indeed. No worries. Happened to me too, still does sometimes :-) Fc
  2. Please do. I have experienced similar situations like the one you described when designing missions. Runs fine in SP, but in MP the mission starts before you're in a plane. So this brings an additional different dynamic. Pls check and let us know. Fc
  3. There is one thing though... When exactly is this code executed? Does the group already exist? I mean, really exist. That means, a player joined that unit? Client units or groups don't exist in the sim if they aren't manned with players.
  4. Watch carefully this video: Catch the land event, and destroy the unit. Let me know if this is enough. Sven
  5. Is there more than one client slot in your group? Does it also happen if you have only 1 client in your group? There are a couple of known issues that have been reported. Please verify the above questions and provide feedback. Sven
  6. getPlayerName() Just want to let all know that it seems in a multi-player environment, the Unit:getPlayerName() bug seems to be solved ... This bug caused the Unit:getPlayerName() method to return a nil or an empty string on a Unit containing a logged in player as a client. Now it seems this method is returning correctly a player name. So all good.
  7. Guys, really... Don't waste your time discussing this :)) Pikey, you are right, Stone house, you are right. Why? A couple of reasons: 1. Moose is a component based framework. It allows great flexibility, but requires some programming skills (about 20% lua knowledge). 2. Moose has now a couple of building blocks that allow airplanes and helicopters to patrol in a zone, to cap in a zone and cas in a zone, including various options... 3. These building blocks are the first step towards something bigger. Overarching components are in the make that will use these building blocks. 4. Skilled programmers are able however as of today, to utilize the event handling mechanisms to achieve fancy things, extending and building on the default mechanisms. So, as I said earlier. GCICAP is a valued script in the community. Those who want a quick plug-in to have CAP functionality should use this. Those who like to play and try out new stuff, can have a peek into the AI_PATROL_ZONE and AI_CAP_ZONE and AI_CAS_ZONE classes. Those people with more programing skills can even combine these with other moose capabilities to create some nice little CAP behavior to their own design. Will there be a time when there is a more high-level plugin in Moose. Of course there will. But with a different design and offering plus minus the same functionality, but more flexible, and extendible. However, am right now working on something different in the framework. Can only do one thing at the time... And I am taking my time for that to have a good design. FC
  8. Forgive me for asking but... The DCS scripting engine method of the class Group:isExist() returns true when all Units in that Group are destroyed. Is this normal? Enquiring Group:getUnit(1) returns nil in that case, which is correct. Fc
  9. How can I embed pictures in posts so that they are visible when reading the post? I noticed that embedding pictures don't show the pictures when posted. I embed pictures by using the insert picture icon in the toolbar and then cut and paste the URL of the picture location into the box. But it seems this is not working.
  10. Something I wondered also if such is possible. Sometimes I do a post, but then notice that the title has an error or that it is not clear enough. Is there a way that the authors of their posts can change the title?
  11. Guys... Please let us put our minds at rest. Life is too short. GCICAP is a valuable script in the community. MOOSE is a framework in development. It contains today components to execute CAP, PATROL and CAS in a zone. This is just the beginning of the story. MOOSE is a modular framework. More modules and capabilities will come. The goal is to provide flexibility to mission designers and to increase the fun part making missions. It is just a question of time. GCICAP will not be blindly copied, the approach will be different so the same functionality can be mimicked, but others things will be possible too... I think stone house and myself are in the same level. Just time is needed to get to that point as explained above. So, my advice is for the moment: You want to have a GCICAP functionality that you know today? Use the known GCICAP script. Wanna try out something different? Have a look at the MOOSE framework or other frameworks. It is as simple as that. The suggestion from Pikey is a lot of fun. So is the one from Delta. At the end it is about your choices, time available and whether you want to invest your time.
  12. We will only know for sure what the problem is if we can look at the whole picture. Thanks for your help Delta. Fc
  13. Aha. Good to know. The fps drop % will depend on how they index the 3D space and how efficiently range searches and ray casting can be performed. Also, trees and forests are different things. We've been doin some testing in ntrr, and it seems AI detection does not incorporate trees... Fc
  14. Does somebody know if in the future of the DCS product, the line of sight calculation logic during detection is going to be improved in future maps or future releases? Right now trees in villages are not taken into account when calculating the line of sight between 2 points. Is this going to change in future releases? Who can help answering this question?
  15. Share your mission so we can have a look. Send it to flightcontrol_moose@outlook.com. Fc
  16. That was not my intention of my post :-) but thanks for the feedback. I think honestly the GCICAP script will still suit you the best solution for the moment. Some more juice is needed in the MOOSE framework to level to that kind of process automation. Slowly this will come though and the API will become more accessible. It will work different though, I mean, it will provide more flexibility and the approach will be different. Sven
  17. An other option that allows you to reactivate units, is to use an object oriented framework. The framework is a collection of "classes" = objects that you can use to enhance your mission with simple additional commands or methods. Suggest you have a look at the mechanism behind the SPAWN class, that allows you to reactivate groups in various forms (in zones, at points, scheduled, limited, using random templates, uncontrolled, ...) A lot is documented around that capability, and I am not going to write all down here. Maybe have a look at the following youtube videos that illustrate the usage of the SPAWN class: For a more comprehensive setup guide of the MOOSE framework, look here: There are test missions that you can try out and look at the code how it is done: https://github.com/FlightControl-Master/MOOSE/tree/master/Moose%20Test%20Missions/SPA%20-%20Spawning (Just don't try SPA-010, because that one has a problem i still need to fix). Just check below in my signature for more info if you find this useful. Sven
  18. When using the helicopter MI-28N in a ground attack scenario where there is a radar threat, you'll notice that the behaviour of the helicopter is completely bollocks. With default settings, you'll see the helo aiming at a target, but then suddenly it goes into vertical evasion and starts to fly around like a chicken and becomes bazooke until it gets shot... So an mi-28N is able to shoot zero targets with default options... A remedy for this is to give the helicopter a couple of options: You can set the reaction to threat to: -Passive defense. This is recommended when they fly through a threat zone but need to continue. Less good if they are aiming.... You'll see the helicopter dispensing flares but continue its route. - Evade fire. This is recommended when you want to the helicopter to aim to the targets. When a SAM fires a missile, the helicopter will start evading the missile. But otherwise the helicopter will remain stable in the air while shooting targets. I guess this applies to any helicopter that uses radar to determine the location of targets. Using the options in reaction to threat is a good way to influence the behavior of the helicopter when it feels attacked or when it detects targets.
      • 1
      • Like
  19. @Ed or somebody else, can clarity be brought on this question please? Ill also post on another forum. Fc
  20. Well... I had to read your sentence a couple of times ... I think i understand it now, let me rephrase it: 1. You changed the resource plan of an airbase. Only one airplane left. 2. You spawn that airplane, so the resources of the airbase are empty now. 3. You want to destroy that airplane when the airbase is captured... Okay ... First question: how do you spawn the airplane... If you use the MOOSE code: -- Create a SPAWN object, that allows to spawn the airplane. AirplaneSpawn = SPAWN:New( "Airplane" ) -- Spawn the airplane, and store the resulting airplane in a GROUP object. AirplaneGroup = AirplaneSpawn:Spawn() -- Now, AirplaneGroup holds the airplane. .... -- Somewhere further in your logic or trigger (DO SCRIPT), you can code: AirplaneGroup:Destroy() -- This will destroy that AirplaneGroup airplane object from your simulation. Hope it helps, FC
  21. You need the group class to do that. I'll see if I can come up with an example.
  22. Done some homework for you ... Sync your moose repository on GITHUB. The following functions have been added: 2017-02-08 - Reworked some vector functions. -- POINT_VEC3:NewFromVec2( Vec2, LandHeightAdd ) added. -- ZONE_RADIUS:GetRandomPointVec2( inner, outer ) added. -- ZONE_RADIUS:GetRandomPointVec3( inner, outer ) added. -- ZONE_POLYGON_BASE:GetRandomPointVec2() added. -- ZONE_POLYGON_BASE:GetRandomPointVec3() added. I think this should help you forward! The following additional demonstration missions have been created, that demonstrate the use of the above methods for each ZONE class: - ZON-101 - Normal Zone - Random Point - ZON-201 - Group Zone - Random Point - ZON-301 - Unit Zone - Random Point - ZON-401 - Radius Zone - Random Point - ZON-501 - Polygon Zone - Random Point Looking forward of your feedback. Fc
  23. @RedGlyph, Some smiles appeared :-) Not going into details. Lets leave it by this. Just fyi, the LUA predicate thing is since the introduction of 1.5 out of order. About 1,5 years now. Fc
  24. Check these example missions: https://github.com/FlightControl-Master/MOOSE/tree/master/Moose%20Test%20Missions/CAP%20-%20Combat%20Air%20Patrol Cap tutorial videos here: Let me know if this fits with what you were looking for. For more info, look in my signature... Kind regards, Sven
×
×
  • Create New...