ajax

I concur with and can confirm everything BadCRC says.

Yep. Switch to any other freq and it works like it always did before.

I couldn't agree more.

BadCRC reports the same bug here http://forums.eagle.ru/showthread.php?t=121142

I just found your post, and I recently posted the same bug. http://forums.eagle.ru/showthread.php?t=125183 Yes, I've seen it. It seems to only work for about five minutes or so using the default frequency of 124.000. If you switch frequencies, it starts working again and keeps on working.

What's not working? I mean there are some known differences between MP and SP. For example, using triggers to cause aircraft failures works in SP but not MP. Some script statements may not work as expected in MP but do for SP. Possibly others.

Yes, I saw your edit after I already posted.:) It definitely is important to realize that the two examples are different

No, I actually didn't. It turns out Unit2 in zone is irrelevant to the "truthness" or "falseness" of the statement as a whole.

If the statement can be expressed in suitable form, then yes it can be done--which was the OP's question. In your example the equivalent form for the ME would be: Unit1 in zone Flag2 ON OR Unit1 in zone Unit2 in zone Flag2 ON The key is to break it down into a series of binary comparisons using the associative and distributive properties of Boolean math. You can always generate a Truth Table to check for equivalency. Edit: I actually stopped too soon: The simplest equivalent form is: Unit1 in zone Flag2 ON

Yes, but it's kind of a pain. By default, the logical operation is AND between each line. Use the OR button to start a new block of AND conditions. This example is not that bad, but you can imagine it can get messy real quick if you add many more conditions. unit 1 in zone flag2 is on OR unit2 in zone flag2 is on Or in plain language: (Unit1 in zone AND flag2 is on) OR (Unit2 in zone AND flag2 is on) -- which is logically equivalent.

For sure, Flagrum, this script has a lot of neat possibilities. You're touching on the same point I was about time-over-target having an effect on recce 'quality' -- we're thinking along the same lines, anyway.

Alright, this is a bit of kludge... down-and-dirty, but it works. Edit: There are now RED and BLUE group lists, which might cause some confusion: The coalition refers to the scout's side. In other words, when you fill out the RED group list, it is comprised of BLUE groups -- targets for the RED side. ScoutReportMulti.zip

Important point there, dooom.:music_whistling:

New Scripting Engine bug to report: Group.getSize() The Group.getSize() function does not do what it's supposed to. It returns the current number of units in a group instead of the initial number of units. Here is the relevant text from the documentation: The attached mission runs a counting script before and after destroying some of the units. As you can see from the log output, getSize() and count of getUnits() return the same thing. [font=Courier New]00466.405 INFO SCRIPTING: getGroupCount() function loaded. 00469.593 INFO SCRIPTING: Initial: getSize() returns 16 00469.593 INFO SCRIPTING: Initial: #units is 16 00480.110 INFO SCRIPTING: Final: getSize() returns 12 00480.110 INFO SCRIPTING: Final: #units is 12 [/font] SSE_getSize_Bug.zip

Modified script and mission attached. I adjusted your timings a bit. I can't believe how long it took to activate the groups -- I had to wait for a full 60 secs before loading the script. ScoutReport.zip

That was you?:thumbup:

Easy to fix. Just have to add an if 'isActive()' check. Edit: Give me a little while, and I'll post a mod. Also, make sure you load the script after the groups have spawned in.

Okay, dOoOm, Here is a very basic script and mission that does what you want. 1. The script needs to be loaded early. In the example it loads after 2 secs. Probably any time within the first minute is fine. 2. Edit the Lua file to define the list of group names that the script is supposed to check. 3. Use a trigger to fire off a very simple, one-liner 'do script' to check the current status. It can be done multiple times. Each time it runs it calculates % strength. 4. Then when you're ready, use another trigger to fire off another one-liner to output the message to coalition. Edit the Lua file to change the message, duration, and coalition. The attached mission has trigger and 'do script' examples. Enjoy! ScoutReportTest.miz ScoutReport.lua

Well, just great... another scripting engine bug!:furious: It appears Group.getSize() doesn't return the initial size of the group as documented. It returns the current number of units. Gonna have to come up with a counting function that runs at mission start.

Okay, that simplifies things quite a bit. Basically, it looks like you can do almost everything with triggers and flags except get enemy strength. Am I correct in assuming you will have a zone defined in ME and you want enemy strength counted in that zone? Or would it be better to have a list of groups you want checked. Will you have multiple scouts or just one? Will the battle zone or target area change with each sortie?

Actually, those errors look like Slmod errors, not Mist errors. I haven't had time to dig around in Slmod yet. Try an experiment: Unload Slmod but keep Mist in and see if things behave better.

Sorry, I missed the responses somehow. I think using a script is unavoidable for this scenario. Off the top of my head, maybe: 1. Define a trigger zone over the battle area. 2. Use a switched condition trigger to fire off a timer script when the scout enters the zone. 3. Use another switched condition trigger to stop the timer script when the scout leaves the zone. 4. The timer script would behave like a stop watch, starting and stopping each time the scout enters and leaves the zone accumulating the total time. 5. Each time the scout leaves the zone, the script: a. Counts all enemy units in the trigger zone. b. Gets their health. 6. Upon landing another trigger fires a calculation script that: a. Retrieves the data from the last time the scout left the zone. b. Calculate the 'result' -- not sure what you want exactly. c. Whatever it is, apply some probability factor based on total time in zone relative to some arbitrary value you supply. d. Maybe apply some randomized 'noise' to the result to simulate fog of war. e. Stores the result in some variable or user flag that can be retrieved in the ME. 7. Output your status report base on that value. Just a broad outline how it could be done. Or, as Silk does, have the script do everything. It really depends on what you want. Do you want the report to go out immediately or only after the scout lands safely?

Going back to a single event handler, you could make things cleaner by subdividing the tasks into logical groups and do something like: [font=Courier New]eventHandler:onEvent(eventdata) if checkBlueShoot(eventdata) then return end if checkRedShoot(eventdata) then return end [/font][font=Courier New][font=Courier New] if checkBlueHit(eventdata) then return end [/font][/font][font=Courier New][font=Courier New][font=Courier New] if checkRedHit(eventdata) then return end -- etc. [/font][/font]end [/font] Each of those functions would return either true or false depending on whether the event applies to it or not. If the event does not apply, the function wouldn't do anything, just return false and the event handler continues to the next check. If true then the function would do your tasks, then return true and the event handler terminates.

I did a search but didn't find anything relevant to this topic. Has anyone else noticed that the default frequency seems to have a bug now? I am not sure when it actually started happening, maybe in 1.2.7? To be specific, in multiplayer using the default frequency of 124.000 other Ka-50s show up on the ABRIS initially, but then the ABRIS quits updating their positions after about 5 minutes? (Mod, if this is a duplicate thread please delete.)

Even though it is technically possible to do what you want to do (see previous post), I have to say that I think you're setting yourself up for some major headaches. If you really want to be able to reference functions programmatically, I think I would try something like this: [font=Courier New]-- define your event-handler functions, the names can be 'dummy' names function dummyFunction1(eventdata) ... end function dummyFunction2(eventdata) ... end, etc. -- then set up a table of functions using meaningful names as table indexes eventFunctions = {} eventFunctions["blueHandler1"] = dummyFunction1 eventFunctions["blueHandler2"] = dummyFunction2, etc. -- then in your code build a function reference string as you indicated you wanted to do -- the end result needs to match one of the function table indexes local functionIndex = 2 local functionCoalition = 'blue' local functionToCall = functionCoalition.."Handler"..functionIndex -- then call the function if needed, not that you would ever do this with an event handler, just showing how it would be done if it were a regular function. eventFunctions[functionToCall](args) -- or assign as eventHandler [/font][font=Courier New]world.addEventHandler(eventFunctions[functionToCall]) [/font]Edit: I think the functions used for event handlers will require a slightly different form, i.e. dummyFunction1:onEvent() but the concept is the same.