Jump to content

MOOSE - Mission Object Oriented Scripting Framework


Recommended Posts

Hello, i'm back with my Polygon zone problem.

 

My name group: Polygon A~ZONE_POLYGON

 

My scrypt Polygon:

 

GroupInside = GROUP:FindByName( "Test Inside Polygon" )

GroupOutside = GROUP:FindByName( "Test Outside Polygon" )

 

PolygonZone = ZONE_POLYGON:FindByName( "Polygon A" )

PolygonZone:SmokeZone( SMOKECOLOR.White, 10 )

 

Messager = SCHEDULER:New( nil,

function()

GroupInside:MessageToAll( ( GroupInside:IsCompletelyInZone( PolygonZone ) ) and "Inside Polygon A" or "Outside Polygon A", 1 )

if GroupInside:IsCompletelyInZone( PolygonZone ) then

GroupInside:GetUnit(1):SmokeRed()

end

end,

{}, 0, 1 )

 

My spawn in this zone scrypt:

ZoneTable = { ZONE:New( "Polygon A~ZONE_POLYGON" ), ZONE:New( "Zone2" ) }

 

Spawn_Vehicle_1 = SPAWN:New( "Spawn Vehicle 1" )

:InitLimit( 10, 10 )

:InitRandomizeRoute( 1, 1, 200 )

:InitRandomizeZones( ZoneTable )

:SpawnScheduled( 5, .5 )

 

 

Spawn Vehicle 1 is for test zone.. But Doesn't work. Where is my error?Moose is loaded at 1s

Thank you

Link to comment
Share on other sites

Just now getting started and was trying to download Eclipse. I made the donation and was able to obtain the .exe download, BUT when I opened it, it had several Eclipse options (see attached pic) and I have no idea which one to choose. Or maybe I'm just in the wrong place? A little help would be appreciated!
You need the LDT https://www.eclipse.org/ldt/

 

Sent from my POT-LX1 using Tapatalk

Link to comment
Share on other sites

Hello, i'm back with my Polygon zone problem.

 

My name group: Polygon A~ZONE_POLYGON

 

My scrypt Polygon:

 

GroupInside = GROUP:FindByName( "Test Inside Polygon" )

GroupOutside = GROUP:FindByName( "Test Outside Polygon" )

 

PolygonZone = ZONE_POLYGON:FindByName( "Polygon A" )

PolygonZone:SmokeZone( SMOKECOLOR.White, 10 )

 

Messager = SCHEDULER:New( nil,

function()

GroupInside:MessageToAll( ( GroupInside:IsCompletelyInZone( PolygonZone ) ) and "Inside Polygon A" or "Outside Polygon A", 1 )

if GroupInside:IsCompletelyInZone( PolygonZone ) then

GroupInside:GetUnit(1):SmokeRed()

end

end,

{}, 0, 1 )

 

My spawn in this zone scrypt:

ZoneTable = { ZONE:New( "Polygon A~ZONE_POLYGON" ), ZONE:New( "Zone2" ) }

 

Spawn_Vehicle_1 = SPAWN:New( "Spawn Vehicle 1" )

:InitLimit( 10, 10 )

:InitRandomizeRoute( 1, 1, 200 )

:InitRandomizeZones( ZoneTable )

:SpawnScheduled( 5, .5 )

 

 

Spawn Vehicle 1 is for test zone.. But Doesn't work. Where is my error?Moose is loaded at 1s

Thank you

Don't ask us, ask your logs. Where is your error?

___________________________________________________________________________

SIMPLE SCENERY SAVING * SIMPLE GROUP SAVING * SIMPLE STATIC SAVING *

Link to comment
Share on other sites

Initial findings on DCS version today is that Airbase ID's look healthy. Which now means we are back to

Reversing partial workarounds

Moving onto publish a Release candidate

 

This is only spot checks, drones are busy testing as we speak. I'll post up any Moose progress. I'm trying to be optimistic about this, but I'd hate to speak too early.

___________________________________________________________________________

SIMPLE SCENERY SAVING * SIMPLE GROUP SAVING * SIMPLE STATIC SAVING *

Link to comment
Share on other sites

OK I've tested airbases including the NTTR airport switchups with the moose versions prior to before we had to emmergency hotfix. Here is the advice for MOOSE users:

 

If you were affected on NTTR by airplanes spawning is odd places on DCS World 2.5.6, you can now revert to a moose version released prior to that and everything will be fine. I tested on December 19th moose and all NTTR (and I expect other airports hit less hard) work fine for "SpawnAtAirbase()) Specifically Las Vegas, TTR, Creech, Pahute Mesa would spawn incorrectly because the workaround of guessing patterns didnt work. There's probably others on different maps, this is just an example. However, with the hotfix applied, moose dev version will spawn incorrectly for some airbases and this can affect Dispatchers, RAT and GetId andGetCategory() functions at a deeper level.

 

If you never had any airbase issues because of Franks emmergency hotfix (count yoursleves lucky) then you can wait and expect a moose update to revert the ugly workarounds with the ID's being wrong. There may still be issues with GetCategory() and other Airbase functions, and if you had these, you can also revert to an earlier moose and everything will be fine.

 

For those folks that didnt notice anything, there was a massive panic, a global pandemic, your shops don't have toilet roll and stuff happened, but it will all be ok soon!

___________________________________________________________________________

SIMPLE SCENERY SAVING * SIMPLE GROUP SAVING * SIMPLE STATIC SAVING *

Link to comment
Share on other sites

Frank has removed the airbase ID issue workaround from the DEV branch and we tested and all spawns last night on all airfields on all maps. Happy to report that SpawnAtAirbase() which is heavily used in Dispatcher, RAT and so on is now confusion free.

 

My advice for Moose users is that 2.5.6 current is much safer for scripting from a moose and airbase perspective and you should now use 2.5.6 with the latest DEV version of Moose and have no issues on airbases.

 

That is IF you want to use OB. You certainly don't have to, but that is also looking much better (and it is also imperfect of course with many known issues)

 

With all complex things, there is no such thing as a perfect world so any issues with current DEV moose, please report on Discord or GitHub.

 

 

Hopefully we can move back to getting the DEV to stable now as originally planned.

 

 

List of scripting and server issues that bother me personally (FWIW)

 

Statics, specifically FARPS and Oiligs do not like being handled in SET_STATIC and having certain methods run on them like GetID() which is used in other functions like filters etc. Because Farps are so special (being airbases too) I would recommend people do not try to access them with broad tools like SET's and ensure they and oilrigs are not used as they will eventually error your script.

 

 

I'm not sure of the status of implementations of the new EH's. I think I like the concept of the kill event that was introduced as a smarter way of counting death, which would be difficult for people catching planes and scoring, because events dont work the same for human and AI wrt planes. Will look at this in the coming weeks.

 

 

AI_A2A_Dispatcher has long had some inbuilt stupidity with engaging. This is a problem in code but not an error. It's more to do with when it releases AI to engage and has changed during it's lifetime. The net effect is that BVR is often pretty rubbish with AI. This is a sad side effect of there being no way to stop an AI engaging short of turning off its ROE. Doing this on ED's AI makes them both dumb and reliant on where you placed the CAP. Always create long distances between CAP stations and engagement points like borders. Some people have had good effect with older version of moose for this.

Other than that, we just need to release a main branch :) New airbases and taxiways are in for the Normandy map, airbases are fixed.

 

OK I've tested airbases including the NTTR airport switchups with the moose versions prior to before we had to emmergency hotfix. Here is the advice for MOOSE users:

 

If you were affected on NTTR by airplanes spawning is odd places on DCS World 2.5.6, you can now revert to a moose version released prior to that and everything will be fine. I tested on December 19th moose and all NTTR (and I expect other airports hit less hard) work fine for "SpawnAtAirbase()) Specifically Las Vegas, TTR, Creech, Pahute Mesa would spawn incorrectly because the workaround of guessing patterns didnt work. There's probably others on different maps, this is just an example. However, with the hotfix applied, moose dev version will spawn incorrectly for some airbases and this can affect Dispatchers, RAT and GetId andGetCategory() functions at a deeper level.

 

If you never had any airbase issues because of Franks emmergency hotfix (count yoursleves lucky) then you can wait and expect a moose update to revert the ugly workarounds with the ID's being wrong. There may still be issues with GetCategory() and other Airbase functions, and if you had these, you can also revert to an earlier moose and everything will be fine.

 

For those folks that didnt notice anything, there was a massive panic, a global pandemic, your shops don't have toilet roll and stuff happened, but it will all be ok soon!

___________________________________________________________________________

SIMPLE SCENERY SAVING * SIMPLE GROUP SAVING * SIMPLE STATIC SAVING *

Link to comment
Share on other sites

Referencing schedule from inside

 

How can I refenrence a local schedule id from inside its function?

In this case - schdl_id

schdlr = SCHEDULER:New( nil )

local schdl_id = schdlr:Schedule( nil, function ()
 schdlr:Stop( schdl_id )
end, {}, 0, 1 )

The problem here is that I cannot access schdl_id from within the function since it was not created at this point.


Edited by Scifer
Link to comment
Share on other sites

Hi People,

 

 

How to load the sound files to Mission for ATIS?

(and png for mission?)

 

Ok Just drag n drop sound folder into mission (using 7zip to open miz file)

 

 

 

Still Learning and Searching - Thanks


Edited by Dispatch

~

Link to comment
Share on other sites

Frank has removed the airbase ID issue workaround from the DEV branch and we tested and all spawns last night on all airfields on all maps. Happy to report that SpawnAtAirbase() which is heavily used in Dispatcher, RAT and so on is now confusion free...

 

Hello,

 

Have you seen this change on todays patch?

 

DCS 2.5.6.45915 Open Beta 2020-03-31

DCS World

 

Fixed Scripting Engine bug causing Airports to return random ID's they have been pounded back into submission and will now have the correct id number for their actual position.

 

For work: iMac mid-2010 of 27" - Core i7 870 - 6 GB DDR3 1333 MHz - ATI HD5670 - SSD 256 GB - HDD 2 TB - macOS High Sierra

For Gaming: 34" Monitor - Ryzen 3600X - 32 GB DDR4 2400 - nVidia GTX1070ti - SSD 1.25 TB - HDD 10 TB - Win10 Pro - TM HOTAS Cougar - Oculus Rift CV1

Mobile: iPad Pro 12.9" of 256 GB

Link to comment
Share on other sites

Error when Creating Lua File

 

1st off, I work for a large software company and know how to code, but have never used LUA before. I have had the hardest time just trying to get LDT up & running. I finally got to a point where I have created a Mission folder and a Test Mission folder. When I try to create a 'Lua File' in my Test Missions folder, an error occurs and the attached window pops up. Any suggestions?

Error.JPG.56f5b720bc1980b877352172e030ab1e.JPG

Link to comment
Share on other sites

Hello,

 

Have you seen this change on todays patch?

Yeah, strangely they already fixed that with the last patch and mention it in today's notes. Moose.lua from the develop branch is fixed and working already for some time :)

A warrior's mission is to foster the success of others.

i9-12900K | MSI RTX 3080Ti Suprim X | 128 GB Ram 3200 MHz DDR-4 | MSI MPG Edge Z690 | Samung EVO 980 Pro SSD | Virpil Stick, Throttle and Collective | MFG Crosswind | HP Reverb G2

RAT - On the Range - Rescue Helo - Recovery Tanker - Warehouse - Airboss

Link to comment
Share on other sites

Yeah, strangely they already fixed that with the last patch and mention it in today's notes. Moose.lua from the develop branch is fixed and working already for some time :)

 

Ok :thumbup:

 

For work: iMac mid-2010 of 27" - Core i7 870 - 6 GB DDR3 1333 MHz - ATI HD5670 - SSD 256 GB - HDD 2 TB - macOS High Sierra

For Gaming: 34" Monitor - Ryzen 3600X - 32 GB DDR4 2400 - nVidia GTX1070ti - SSD 1.25 TB - HDD 10 TB - Win10 Pro - TM HOTAS Cougar - Oculus Rift CV1

Mobile: iPad Pro 12.9" of 256 GB

Link to comment
Share on other sites

I don't understand that code. Can I ask what you are trying to do? Can't you just write schdr:Stop()? Or, just have it stop or run x amount of times with the initial arguments at the bottom?

 

The code is just a simplification of something much bigger where I would like to access the id from within the schedule itself.

 

To put it simple. I'm trying to stop a schedule upon a certain condition. If I put schdr:Stop() it wouldn't work from within the schedule since schdr has no value yet.

Link to comment
Share on other sites

I don't understand that code. Can I ask what you are trying to do? Can't you just write schdr:Stop()? Or, just have it stop or run x amount of times with the initial arguments at the bottom?

 

I updated the last line in original post to clarify about my problem.

Link to comment
Share on other sites

1st off, I work for a large software company and know how to code, but have never used LUA before. I have had the hardest time just trying to get LDT up & running. I finally got to a point where I have created a Mission folder and a Test Mission folder. When I try to create a 'Lua File' in my Test Missions folder, an error occurs and the attached window pops up. Any suggestions?

 

 

I have found that error code can be safely ignored, so long as you can go ahead and create a file in LDT.

Link to comment
Share on other sites

To put it simple. I'm trying to stop a schedule upon a certain condition

 

If that's all you want, you can switch to a standard DCS scheduler and simply do this:

 

function Scheduler()
 
  if condition then [color="Blue"]-- if condition is true, the scheduled function will return nil, stopping the scheduler
 [/color]
     return nil
 
  else              [color="blue"]-- Otherwise the scheduler will keep running every 10 seconds[/color]
     return timer.getTime() + 10
  end
end

timer.scheduleFunction(Scheduler, nil , timer.getTime() + 1)

Link to comment
Share on other sites

When I try to create a 'Lua File' in my Test Missions folder, an error occurs

 

That's a strange one, I remember someone else having the same issue several months ago and couldn't find the cause.

 

As a workaround, create your lua files directly under your project, rather than inside custom folders, see if that works.

 

If it works, then try to drag those lua files inside your custom folders afterwards (using the Script Explorer window on the left), see what happens.

 

If you still get the error, make sure that you have full permissions and that the Java build you're using is JRE 1.8.0_241 (remove any other existing Java builds).

 

If you already have all that covered and the problem persists, remove LDT completely (all traces of it, all folders), try VS instead.

 

 

Btw, what OS are you using?

Link to comment
Share on other sites

Hello,

 

Have you seen this change on todays patch?

 

 

Yessir, They were fixed the previous week along with Ammo renaming ( https://forums.eagle.ru/showpost.php?p=4251512&postcount=94 - March 20th) but I didnt want to moan because this week we got the patchnotes in English and better late than never and they did add them after I suggested it so i can hardly moan :)

We had fixed airbases a few hours later than that post :)

___________________________________________________________________________

SIMPLE SCENERY SAVING * SIMPLE GROUP SAVING * SIMPLE STATIC SAVING *

Link to comment
Share on other sites

The code is just a simplification of something much bigger where I would like to access the id from within the schedule itself.

 

To put it simple. I'm trying to stop a schedule upon a certain condition. If I put schdr:Stop() it wouldn't work from within the schedule since schdr has no value yet.

 

 

Inside a second schedule that runs slightly later than the first (variable schdr already declared):

 

 

if x==y then

schdr:Stop()

end

___________________________________________________________________________

SIMPLE SCENERY SAVING * SIMPLE GROUP SAVING * SIMPLE STATIC SAVING *

Link to comment
Share on other sites

Inside a second schedule that runs slightly later than the first

 

Thanks for your help but Hardcard suggested a much more elegant way:

 

If that's all you want, you can switch to a standard DCS scheduler and simply do this:

 

function Scheduler()
 
  if condition then [color="Blue"]-- if condition is true, the scheduled function will return nil, stopping the scheduler
 [/color]
     return nil
 
  else              [color="blue"]-- Otherwise the scheduler will keep running every 10 seconds[/color]
     return timer.getTime() + 10
  end
end

timer.scheduleFunction(Scheduler, nil , timer.getTime() + 1)

 

Can't MOOSE scheduler do the same?


Edited by Scifer
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...