MOOSE - Mission Object Oriented Scripting Framework - Page 82 - ED Forums
 


Notices

Reply
 
Thread Tools Display Modes
Old 10-07-2017, 11:46 AM   #811
FlightControl
Senior Member
 
FlightControl's Avatar
 
Join Date: Mar 2012
Location: Antwerp, Belgium
Posts: 1,848
Reputation power: 15
FlightControl is just really niceFlightControl is just really niceFlightControl is just really niceFlightControl is just really niceFlightControl is just really niceFlightControl is just really niceFlightControl is just really niceFlightControl is just really niceFlightControl is just really niceFlightControl is just really niceFlightControl is just really nice
Default

Quote:
Originally Posted by Quadrafarian View Post
I late activated an SA-8 set it as red then just spawned a group of Su-25T's (not late activated) as blue. The GRP-100 Returned the value of Blue = true & red = false. Hence my question.
But thanks for fast reply and I've got the Documentation bookmarked and has been my 2nd home for the past week along with the great videos.
I do have a suggestion on the videos when you do more could you add a link to the documentation page in the description of the section the video covers.

Excellent Idea! I'll make work of that!

1. A link to the documentation pages that are relevant!
2. A link to the test missions that are relevant!

You see gents, I know the framework is used. But this thread is always a bit silent.

I don't have a real visibility who is using this framework :-) So great!
FlightControl is offline   Reply With Quote
Old 10-07-2017, 12:46 PM   #812
Quadrafarian
Junior Member
 
Quadrafarian's Avatar
 
Join Date: Sep 2017
Posts: 5
Reputation power: 0
Quadrafarian is on a distinguished road
Default

Sorry for another question, it's to do with late activating units.

KryRed = SET_GROUP:New():FilterCoalitions("red"):FilterPref ixes("DAR","SAM"):FilterStart()
KryRed = SET_GROUP:New():FilterCoalitions("red"):FilterPref ixes("DAR"):FilterStart()

both returns nil, not using both at the same time, but

KryRed = GROUP:FindByName("DAR") or KryRed = GROUP:FindByName("SAM")

works, just wanted to check I'm not missing something. Only spawning two groups to test with at the moment, trying to respawn the groups after they've both been destroyed.

Again I can't thank you enough for the help and the framework.

EDIT:- just to clarify

not GROUP:IsAlive() can't tell me if it's late activated & destroyed only that it's either late activated or destroyed? any other way to determine if it's been late activated and destroyed?

Last edited by Quadrafarian; 10-07-2017 at 01:26 PM. Reason: added another question.
Quadrafarian is offline   Reply With Quote
Old 10-08-2017, 12:33 PM   #813
FlightControl
Senior Member
 
FlightControl's Avatar
 
Join Date: Mar 2012
Location: Antwerp, Belgium
Posts: 1,848
Reputation power: 15
FlightControl is just really niceFlightControl is just really niceFlightControl is just really niceFlightControl is just really niceFlightControl is just really niceFlightControl is just really niceFlightControl is just really niceFlightControl is just really niceFlightControl is just really niceFlightControl is just really niceFlightControl is just really nice
Default

Quote:
Originally Posted by Quadrafarian View Post
Sorry for another question, it's to do with late activating units.

KryRed = SET_GROUP:New():FilterCoalitions("red"):FilterPref ixes("DAR","SAM"):FilterStart()
KryRed = SET_GROUP:New():FilterCoalitions("red"):FilterPref ixes("DAR"):FilterStart()

both returns nil, not using both at the same time, but

KryRed = GROUP:FindByName("DAR") or KryRed = GROUP:FindByName("SAM")

works, just wanted to check I'm not missing something. Only spawning two groups to test with at the moment, trying to respawn the groups after they've both been destroyed.

Code:
KryRed = SET_GROUP:New():FilterCoalitions("red"):FilterPrefixes( { "DAR", "SAM" } ):FilterStart()
Mind the {} !!!

Quote:
Originally Posted by Quadrafarian View Post
not GROUP:IsAlive() can't tell me if it's late activated & destroyed only that it's either late activated or destroyed? any other way to determine if it's been late activated and destroyed?
I am having a bit a difficulty to understand why you are asking this or your question overall.

Why is it important to know if a unit has been late activated and Destroyed?
Can you bring some light on the context for this requirement?

Hope this helps,
Sven
FlightControl is offline   Reply With Quote
Old 10-08-2017, 01:13 PM   #814
Quadrafarian
Junior Member
 
Quadrafarian's Avatar
 
Join Date: Sep 2017
Posts: 5
Reputation power: 0
Quadrafarian is on a distinguished road
Default

Ah I missed the Table {}

Sure it's for an ongoing training mission.
The units are spawned in a zone using 8 templates with random positions.
Then destroyed by clients and when the last unit in the area is killed the area spawns again using the 8 templates & random positions.

That was the reasoning behind my questions.
Quadrafarian is offline   Reply With Quote
Old 10-09-2017, 11:18 AM   #815
FlightControl
Senior Member
 
FlightControl's Avatar
 
Join Date: Mar 2012
Location: Antwerp, Belgium
Posts: 1,848
Reputation power: 15
FlightControl is just really niceFlightControl is just really niceFlightControl is just really niceFlightControl is just really niceFlightControl is just really niceFlightControl is just really niceFlightControl is just really niceFlightControl is just really niceFlightControl is just really niceFlightControl is just really niceFlightControl is just really nice
Default Release 2.2 - Patch 2

Release 2.2 - Patch 2 (LATEST VERSION)

FlightControl-Master released this a minute ago
This patch brings a change on the SCORING class:
  • Disabled the logic of Fratricide until a DCS bug gets fixed by ED. There is no workaround possible. Units containing a player cannot be destroyed using Unit:destroy() API in multi player when the player is seated in a Unit from a Client connected PC to the Server.
  • By default, hit messages are disabled. They can be enabled by using SCORING:SetMessagesHit().
All the available MOOSE classes come delivered in one Moose.lua file. There are two versions of this file that are functional (work), but with different file sizes:
  • Moose.lua (with comments, 2.1MB) ... For mission designers, who are developing missions and want to check upon errors appearing in the dcs.log or have a detailed code reference etc.
  • Moose_.lua (without comments, 0.8MB) ... For runtime environments, to facilitate quicker downloads of mission files and performance.
To use, include the Moose.lua in your .miz file using a DO SCRIPT Trigger. Mission Designers need to read here for a detailed usage description. Consult the MOOSE documentation for further details on the framework.
__________________
FlightControl is offline   Reply With Quote
Old 10-10-2017, 09:57 AM   #816
FlightControl
Senior Member
 
FlightControl's Avatar
 
Join Date: Mar 2012
Location: Antwerp, Belgium
Posts: 1,848
Reputation power: 15
FlightControl is just really niceFlightControl is just really niceFlightControl is just really niceFlightControl is just really niceFlightControl is just really niceFlightControl is just really niceFlightControl is just really niceFlightControl is just really niceFlightControl is just really niceFlightControl is just really niceFlightControl is just really nice
Default Release 2.2 - Patch 3

Release 2.2 - Patch 3 (LATEST VERSION)

FlightControl-Master released this just now
This patch brings a change on the SCORING class:
  • Fixed error in AI_A2A_PATROL due to a stupid error that sneaked into the logic due to a variable rename. Fixed now! (sorry). This problem stopped AI_A2A_DISPATCHER patrolling.
All the available MOOSE classes come delivered in one Moose.lua file. There are two versions of this file that are functional (work), but with different file sizes:
  • Moose.lua (with comments, 2.1MB) ... For mission designers, who are developing missions and want to check upon errors appearing in the dcs.log or have a detailed code reference etc.
  • Moose_.lua (without comments, 0.8MB) ... For runtime environments, to facilitate quicker downloads of mission files and performance.
To use, include the Moose.lua in your .miz file using a DO SCRIPT Trigger. Mission Designers need to read here for a detailed usage description. Consult the MOOSE documentation for further details on the framework.
__________________
FlightControl is offline   Reply With Quote
Old 10-10-2017, 09:59 AM   #817
FlightControl
Senior Member
 
FlightControl's Avatar
 
Join Date: Mar 2012
Location: Antwerp, Belgium
Posts: 1,848
Reputation power: 15
FlightControl is just really niceFlightControl is just really niceFlightControl is just really niceFlightControl is just really niceFlightControl is just really niceFlightControl is just really niceFlightControl is just really niceFlightControl is just really niceFlightControl is just really niceFlightControl is just really niceFlightControl is just really nice
Default Release 2.3 - Alpha for Early Adopters

MOOSE Release 2.3 alpha - (EARLY ADOPTERS VERSION)

FlightControl-Master released this 2 days ago · 21 commits to Release-2.3-alpha since this release
For those who want to use the latest of the latest, use the following Moose.lua files...
Note that this version of MOOSE contain prototype methods, and are bound to change.
However, when methods are changed, I will communicate that, so you can adapt your missions.
I will try to keep the changes to the minimum.
All the available MOOSE classes come delivered in one Moose.lua file. There are two versions of this file that are functional (work), but with different file sizes:
  • Moose.lua (with comments, 2.1MB) ... For mission designers, who are developing missions and want to check upon errors appearing in the dcs.log or have a detailed code reference etc.
  • Moose_.lua (without comments, 0.8MB) ... For runtime environments, to facilitate quicker downloads of mission files and performance.
To use, include the Moose.lua in your .miz file using a DO SCRIPT Trigger. Mission Designers need to read here for a detailed usage description. Consult the MOOSE documentation for further details on the framework.
List of changes:
  • Added GOAL, ZONE_GOAL, ZONE_GOAL_COALITION, ZONE_CAPTURE_COALITION classes to model capturing of Zones by a Coalition.
  • Added on the ZONE class an improved search method to search for SCENERY in a ZONE. Added also methods ZONE:GetScannedScenery() and ZONE:GetScannedSceneryType() methods to inspect which Scenery has been found after a Zone:Scan()...
  • Added USERFLAG class to manage user flags
  • Added USERSOUND class to manage sounds
  • Added SET_BASE:GetSetNames() to return an array of the object names of a Set. (Created dynamic lists based on mission editor groups defined).
  • Added SET_BASE:GetSetObjects()
  • Revised the message naming.
  • Optimized the code for GetScannedCoalition
  • Markings text optimized for ZONE_CAPTURE_COALITION. Now the owning coalition is also shown.
__________________
FlightControl is offline   Reply With Quote
Old 10-12-2017, 09:52 AM   #818
blklobo
Junior Member
 
Join Date: Nov 2014
Posts: 39
Reputation power: 3
blklobo is on a distinguished road
Default How to get coordinates of a building in DCS and its application examples

MOOSE Version : 2.3.0 Alpha (Early Adopters)
Download : https://github.com/FlightControl-Mas.../release-2.3.0

※ I am not good english user, so I use the Google Translator for this thread.

This method is to get the coordinates of the building in DCS 1.5. You can use this method to know the type and coordinates of the building and to enter the kind of building you know so you can get the coordinates of the specific building you want. I can use this method to build various virtual battlefield environments. You can configure the environment below. (Thanks to FC)

1. Build a low-altitude air defense network in a specific city.
2. Build a mission to bomb specific buildings.
3. Infantry or cargo transport to a specific building.
4. Other creative environments are possible.

As you know, the intervention of the air force in the contemporary low-intensity dispute is the responsibility of precisely striking certain goals in the city. I think MOOSE 2.3's new features will make it easier to implement battlefields in the city. As you know, the satellite view in the 1.5 Mission Editor was not very accurate, which made the mission a big challenge. Also, even if the satellite view is accurate, placing the unit manually in a particular building is a very time consuming process. Consider the following example code.

Code:
Zone = ZONE:New( "Identfy" )
Zone:Scan( Object.Category.SCENERY )

for SceneryTypeName, SceneryData in pairs( Zone:GetScannedScenery() ) do
  for SceneryName, SceneryObject in pairs( SceneryData ) do
    local SceneryObject = SceneryObject -- Wrapper.Scenery#SCENERY
    MESSAGE:NewType( "Scenery: " .. SceneryObject:GetTypeName() .. ", Coord: " .. SceneryObject:GetCoordinate():ToStringLLDMS(), MESSAGE.Type.Information ):ToAll()
  end
end
1. I created a 25 meter radius in the Mission Editor named "Identfy". This is to know the name of a specific building.

2. The following for statement prints the name of the particular building. This code is provided by FC as an example. I am not a professional programmer, so I can not understand the exact mechanism. Sorry!

Code:
  for SceneryName, SceneryObject in pairs( Zone:GetScannedSceneryType( "HOME16_TWIN" ) ) do
    local SceneryObject = SceneryObject -- Wrapper.Scenery#SCENERY
    local Vec2 = SceneryObject:GetVec2()
    ZU23:SpawnFromVec2( Vec2 )
    MESSAGE:NewType( "Scenery: " .. SceneryObject:GetTypeName() .. ", Coord LL DMS: " .. SceneryObject:GetCoordinate():ToStringLLDMS(), MESSAGE.Type.Information ):ToAll()
  end
I scanned the type of building with the above script and found the name of the building called HOME16_TWIN. And the coordinates of the HOME16_TWIN buildings in the Zone with a specific radius. Then, ZU-23, which we prepared in advance, is created in the corresponding coordinates.

In my opinion, I think that these functions can be applied indefinitely using the DESIGNATION class and the MENU and TASKING classes. Take note of the MOOSE, which once again gives thanks to FC and is opening a new chapter in the world of mission editing.
Attached Thumbnails
Click image for larger version

Name:	Screen_171012_155100.jpg
Views:	24
Size:	411.5 KB
ID:	170587  
blklobo is offline   Reply With Quote
Old 10-12-2017, 03:15 PM   #819
fargo007
Junior Member
 
Join Date: Jul 2017
Posts: 78
Reputation power: 1
fargo007 is on a distinguished road
Default

I have a question.

I have a radio menu item that calls a function that returns (message) the current coordinates.

When I hardcode my group name in, this works fine but I want it to be dynamic.

So the question is: How could I access the name of the specific client who selects that radio item?

If possible, the client would be passed to the function, which would retrieve that particular clients coords, and message only that particular client via... :ToClient(client)

Thanks!

/Fargo

Last edited by fargo007; 10-12-2017 at 03:29 PM.
fargo007 is offline   Reply With Quote
Old 10-13-2017, 05:07 AM   #820
FlightControl
Senior Member
 
FlightControl's Avatar
 
Join Date: Mar 2012
Location: Antwerp, Belgium
Posts: 1,848
Reputation power: 15
FlightControl is just really niceFlightControl is just really niceFlightControl is just really niceFlightControl is just really niceFlightControl is just really niceFlightControl is just really niceFlightControl is just really niceFlightControl is just really niceFlightControl is just really niceFlightControl is just really niceFlightControl is just really nice
Default

Quote:
Originally Posted by fargo007 View Post
I have a question.

I have a radio menu item that calls a function that returns (message) the current coordinates.

When I hardcode my group name in, this works fine but I want it to be dynamic.

So the question is: How could I access the name of the specific client who selects that radio item?

If possible, the client would be passed to the function, which would retrieve that particular clients coords, and message only that particular client via... :ToClient(client)

Thanks!

/Fargo
Hi,

Within DCS, the design of the API to control the radio menus in the sim could have been better. However, what you want to achieve is possible.
When DCS sets a radio menu for all players or for a coalition, then all players or all players of the coalition will see the menu command. However, once a player selects a menu command, the system does not provide the unit that pressed the menu command, which is a severe flaw in the design of the menu system.

Fortunately, there is a way, but it does not cover what you wanna achieve.

The first point is that within the DCS scripting engine and DCS design, all menu handling and all communication (like messages, sounds) can be done for all players, all players in a coalition or to specific groups. It is the latter that is the most interesting, however, again, communication is to groups, so not to individual units in a group. This may seem like a limitation, but in fact it is not. There are two aspects to know:

1. There is an open error still within the DCS system, that prevents DCS to handle groups within the scripting engine that can have 2 or more players in it (so 2 or more clients). As a result, most groups within the current missions will only have 1 player (client). The method Unit:getGroup() will return nil if there are 2 clients or more in the system.

2. There is an open bug in the sim to handle the event S_EVENT_PLAYER_ENTER_UNIT, which is important to detect which players are entering which units. Right now, in multi player, this event is only fired for planes and helicopters on the server, not for ground units and maybe later ships.

With these two points in our mind, there is a way to handle menus to specific groups, and make groups receive the selected menu items.
MOOSE uses this all the time, it allows to define which groups can have which menu item, and to know which group (player in group) has selected which menu item. It is the only way that I know of that works.

The class to set specific menu commands to specific groups in MOOSE is:

MENU_GROUP_COMMAND:New( PlayerGroup, MenuText, MenuPath, MenuFunction, ... )

There is also a core API within DCS that does the same, but the MOOSE class using this API has made the following improvements:

  1. It prevents menus to be set twice or more times (upon sequent calls). In other words, menus set with the same menu text, will be updated or changed, and not added every time in the menu system. In this way it is possible to update the MenuFunction and parameters of a menu item.
  2. Notice the ... , which allows for a variable amount of parameters to be given. In the core API of DCS, one parameter is only possible, which results in having to use tables etc, but I feel this is too much low level for that is needed. MOOSE hides this complexity for you.
  3. The class has methods that allow to "refresh" menus based on a batch of updates. I won't get into details here, but basically the methods allow to set a timestamp and tags on each menu item. A logic can update the relevant menu items using the new timestamp and relevant tags. And later in one command any menu item that has not received the new timestamp with the related tag, will be removed... So this allows for efficient refreshing of menus.

A concrete example of how a menu for a specific group can be set is as follows:

Code:
PlayerGroup = GROUP:FindByName( "PlayerGroup" )

MENU_GROUP_COMMAND:New( PlayerGroup, "Call in air support MI-28", MenuRoot, CallInAirSupport, PlayerGroup, "MI-28" )

MENU_GROUP_COMMAND:New( PlayerGroup, "Call in air support KA-50", MenuRoot, CallInAirSupport, PlayerGroup, "KA-50" )

....

function CallInAirSupport( PlayerGroup, HelicopterType )
  MESSAGE:NewType( "Calling in Air Support " .. HelicopterType, MESSAGE.Type.Information ):ToGroup( PlayerGroup )
  if HelicopterType == "MI-28" then
    ...
  elseif HelicopterType == "KA-50" then
    ...
  end
end
The example outlines that when a player in the PlayerGroup selects one of the two menu items, the function CallInAirSupport shall be called. A message is sent to the player, and specific actions are executed depending on the HelicopterType... When setting the group menu, notice in the New method the two variable parameters PlayerGroup, "MI-28" or "KA-50" to be set, which are received by the function.

So, to answer your question, it is possible, but this method also has important drawbacks:
  1. The mission designer needs to set for each group that can have specific menu commands for the group, a group menu command. If this is not carefully managed, this may result quickly in a performance drop.
  2. Updating and maintaining different menu items for each group is complex. Especially in case for different contexts (like different missions, tasks etc).

That is why the S_EVENT_PLAYER_ENTER_UNIT is so important, as this will prevent the mission designer to execute excessive loops within the system setting for each possible group a menu command... Instead, if this event would be fired consistently, it would be possible to catch the event, and set the menu command for the group of the unit for which the event was fired and done.

The DCS simulator could really be enriched with two addons that would really ease the simulation experience:

  1. Add a 4th type of API that allows to set menus for a series of Group objects.
  2. Provide a means to pass the group object that has selected the menu command, in case of menus for all players and/or all coalitions.
This would ease the complexity of menu management a lot for specific groups, and would provide a more user friendly interface for mission designers.

I hope this helps,
Sven
__________________
FlightControl is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

All times are GMT. The time now is 02:32 PM. vBulletin Skin by ForumMonkeys. Powered by vBulletin®.
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.