Speed

What would be a good alternate forum structure?

By request... here's the latest version of Ridiculous Air Defense Mission. Disclaimer: I am not to be held responsible if your GPU spontaneously combusts while playing this mission. RIDICULOUS AIR DEFENSE MISSION 4.miz

Delete C:\Users\<Your Account>\Saved Games\DCS\Config\Input\ground_unit\keyboard\Keyboard.lua. Now you will have access to the turret stabilization command (the "v" key). It makes things better, but still not as stable as it should be.

Try hitting alt-tab to bring up the windows task bar on the bottom of the screen, and then click on the DCS tab. Somehow DCS is not the active window.

With just Slmod, you could use the msg_LL or msg_MGRS functions in combination with the chat-based coordinate conversion utility. That's a bit of extra legwork on the part of the pilots, and chromium is right- there is a better way using the new scripting engine. Unfortunately, somehow, in some recent update the trigger.action.outTextForCoalition function was broken, so you can only output for all. However, if you use Slmod (slmod.msg_out function) in combination with the scripting engine, you can work around the bug in the scripting engine and output the message for only one coalition: do --Script that sends a bullseye location of a unit to coalition. Created by "Speed". local unitName = 'C-17 #1' -- change to the name of the unit local coa = coalition.side.BLUE -- change to coalition.side.RED if you want red coalition local msg = 'Enfield1, this is Crystal Palace, the friendly transport is now at bullseye %s' --change to the desired message, %s is where the bullseye coords will go. local displayTime = 20 --time the message will be displayed local metric = false -- if metric == false, then bullseye distance is in nautical miles; change to true to put bullseye distance in kilometers. -- change nothing below this line. --------------------------------------------------------------- local unit = Unit.getByName(unitName) if unit then local function round(num, idp) local mult = 10^(idp or 0) return math.floor(num * mult + 0.5) / mult end local function getNorthCorrection(point) --gets the correction needed for true north, errases error from gnomonic projection. if not point.z then --Vec2; convert to Vec3 point.z = point.y point.y = 0 end local lat, lon = coord.LOtoLL(point) local north_posit = coord.LLtoLO(lat + 1, lon) return math.atan2(north_posit.z - point.z, north_posit.x - point.x) end local bull = coalition.getMainRefPoint(coa) local unitPos = unit:getPosition().p local heading = math.atan2(unitPos.z - bull.z, unitPos.x - bull.x) heading = heading + getNorthCorrection(unitPos) if heading < 0 then heading = heading + 2*math.pi -- put heading in range of 0 to 2*pi end heading = round(heading, 0) local dist = ((unitPos.z - bull.z)^2 + (unitPos.x - bull.x)^2)^0.5 if metric then dist = round(dist/1000, 0) else dist = round(dist/1853, 0) end local bullMsg = string.format(msg, heading .. ' for ' .. dist) local coaString if coa == coalition.side.BLUE then coaString = 'blue' elseif coa == coalition.side.RED then coaString = 'red' else coaString = 'all' end slmod.msg_out(bullMsg, displayTime, 'text', coaString) end end The crap with coaString and the slmod function call are where trigger.action.outTextForCoalition would normally be if this were a pure scripting engine script.

Welcome back! That Zeus looks to be in remarkably good shape.

This will not work, each UCID and IP MUST have a name associated with it. In fact, the above is not correct Lua, and will cause a Lua error when it tries to load. Slmod will catch this error and try to give you an error message telling you what's wrong, but you might have to go to dcs.log to see it. Maybe I need to come up with a better way of displaying error messages.

Previously, there was a bug where UCIDs were not constant and would change. That was fixed around the beginning of November. There was a small format change in UCIDs as well- the "dcs" part at the beginning was removed, and now UCIDs are only a long string of hex digits. For those reasons, all your old ban tables by UCID are probably useless now. :cry: However, if Servman banned by IP, you can add those. Slmod bans by both IP and UCID. The Slmod ban tables are stored in Saved Games/DCS/Slmod/BannedClients.lua, and look something like this: slmod_banned_ips = { ["95.162.42.66"] = "Dbag", ["122.170.10.141"] = "Jerkwad", ["76.110.61.12"] = "Old banned IP from Servman", ["82.10.167.109"] = "Old banned IP from Servman", } -- end of slmod_banned_ips slmod_banned_ucids = { ["072c21f98f02aa91ac14efd583c6fff2"] = "Dbag", ["af701c68d3501b450124adf510529501"] = "Jerkwad", } -- end of slmod_banned_ucids In the above example, I "simulated" adding a bunch of banned IPs manually. The name associated with each banned IP/UCID does not have to be unique, it's just to help you identify who is who, and also is used in the unban feature. If you are manually adding a UCID and/or IP, you can make the name for it be anything, but it MUST be a string (simplified explanation: string = set of characters inside quotes). I would rather not have to support Servman compatibility on this- that could add a lot of extra code, and the old UCIDs are probably useless now anyway. While some people have a static IP for years, for other people, their IP is something that can change on a daily basis.

Well, I also didn't get repaired the other night even though the ground crews said they would. Something is up, but I donno what, or if it is known or not. It's worth checking in to.

http://forums.eagle.ru/showpost.php?p=1560523&postcount=298 ^^ Not "officially" released yet, but it does work. I hope to officially release it, with a few more features, shortly.

Uploaded a new version of my ridiculous air defense mission today: FcgJkqWHSJk

Yes, hidden on map should over-ride fog of war visibility. However, 1.2.2 brings a vast change for the better: if you are a ground commander, hidden on map does not over-ride the visibility of units you might potentially command on the F10 map. So hidden on map will only over-ride the visibility of units on the F10 map if you are an aircraft flyer/spectator. Your mistake is that you are using red and blue GAME MASTERs. Game masters as just what their name implies- they can control everything. Hence, they can see everything, enemy and friendly, regardless of whether or not those units are hidden. This is as it should be. If you want to have a blue/red forces commander that can only see their own coalition's forces (when all units are hidden), use the GROUND FORCE CM. slot.

You are talking about scripts that are run as part of the RUN SCRIPT AI action? You want to have the script automatically know the group that it's run in? I'm afraid that this is not possible. I actually had thought that there was a way to do this, but I looked for the relevant variable and I could not find it. It is not a bad idea though- maybe I could suggest it to the developer in charge of the scripting engine. The idea: there could be a local variable, named something like "currentGroup", that is only accessible to scripts run via a Run Script AI action, and it contains the group object that is running the script. Edit: Actually, I think I know of a way to make Slmod implement something like this behavior, but it's probably best left to the devs. Yes. See the new unit table shortcuts: Prefixes: "[-u]<unit name>" - subtract this unit if its in the table "[g]<group name>" - add this group to the table "[-g]<group name>" - subtract this group from the table "[c]<country name>" - add this country's units "[-c]<country name>" - subtract this country's units if any are in the table Stand-alone identifiers "[all]" - add all units "[-all]" - subtract all units (not very useful by itself) "[blue]" - add all blue units "[-blue]" - subtract all blue units "[red]" - add all red coalition units "[-red]" - subtract all red units Compound Identifiers: "[c][helicopter]<country name>" - add all of this country's helicopters "[-c][helicopter]<country name>" - subtract all of this country's helicopters "[c][plane]<country name>" - add all of this country's planes "[-c][plane]<country name>" - subtract all of this country's planes "[c][ship]<country name>" - add all of this country's ships "[-c][ship]<country name>" - subtract all of this country's ships "[c][vehicle]<country name>" - add all of this country's vehicles "[-c][vehicle]<country name>" - subtract all of this country's vehicles "[all][helicopter]" - add all helicopters "[-all][helicopter]" - subtract all helicopters "[all][plane]" - add all planes "[-all][plane]" - subtract all planes "[all][ship]" - add all ships "[-all][ship]" - subtract all ships "[all][vehicle]" - add all vehicles "[-all][vehicle]" - subtract all vehicles "[blue][helicopter]" - add all blue coalition helicopters "[-blue][helicopter]" - subtract all blue coalition helicopters "[blue][plane]" - add all blue coalition planes "[-blue][plane]" - subtract all blue coalition planes "[blue][ship]" - add all blue coalition ships "[-blue][ship]" - subtract all blue coalition ships "[blue][vehicle]" - add all blue coalition vehicles "[-blue][vehicle]" - subtract all blue coalition vehicles "[red][helicopter]" - add all red coalition helicopters "[-red][helicopter]" - subtract all red coalition helicopters "[red][plane]" - add all red coalition planes "[-red][plane]" - subtract all red coalition planes "[red][ship]" - add all red coalition ships "[-red][ship]" - subtract all red coalition ships "[red][vehicle]" - add all red coalition vehicles "[-red][vehicle]" - subtract all red coalition vehicles Country names to be used in [c] and [-c] short-cuts: "Turkey" "Norway" "The Netherlands" "Spain" "UK" "Denmark" "USA" "Georgia" "Germany" "Belgium" "Canada" "France" "Israel" "Ukraine" "Russia" "South Osetia" "Abkhazia" "Italy" BTW, ships don't work currently in Slmod due to a bug in the Export Lua environment, but they do get added to the unit tables. So, for example, if you want to detect LOS on all blue coalition planes and helicopters to another unit named "EWR1", with 0 meters altitude offset on the aircraft and +8 meters altitude offset on the unit named "EWR1", out to a max radius of 175km, with 500 terrain checks, checking every 5 seconds, and setting flag 501 when LOS conditions are met, then run this script: if slmod then slmod.units_LOS{ unitset1 = {'[blue][plane]', '[blue][helicopter]'}, altoffset1 = 0, unitset2 = {'EWR1'}, altoffset2 = 8, flag = 501, interval = 5, checks = 500, radius = 175000 } else trigger.action.outText('Game host, please install Slmod to make this mission work correctly!', 60) end Also, notice that I encapsulated the Slmod function call inside an if slmod then statement so that if the game host does not have Slmod installed, there is no Lua error generated, and he is prompted to install Slmod if he wants the mission to work :)

With Slmod, no. However, I'm planning on having a little "fun" today by working on Mist (Mission Scripting Tools). It includes the function you are talking about. I donno when it will be ready to be released thoguh. First, I gotta get my DCS all caught up to current versions though... see my sig, I've been rather busy doing real life CRAP instead :( Slmod only works in multiplayer. I won't cause any errors or anything in single player, it simply won't function.

mapobj_destroyed only works on map objects. Currently, there is no method of checking the health of mission-specific static objects in Slmod. The reason is there is no easy way to check static object health through Lua. There will probably be a method to check mission-specific static object health in the scripting library that Grimes and I are working on. I could probably port the code into Slmod too. The method I created to do this is to correlate the location of the destroyed object to the known locations of the static objects at mission start. If an object that was destroyed is at the same location that a static object was, and the object that was destroyed was not a unit of some sort, then the object that was destroyed was almost certainly the static object.

Sorry for the late response. See my signature, I updated it so I don't have to keep telling folks :) The slmod.units_LOS works with all ground units and air units, be they human controlled or not.

I've been meaning to look into it. Part of the issue is that the weapon type name in the main simulation environment can be different than the type name in the events list. Anyway, you can specify "all" if you want Slmod to detect ALL weapons, and not discriminate.

To make flag 101 go true (so that an audio message could be played) whenever someone fires a maverick, then a few secs after start of the mission (assuming blue coalition): if slmod then slmod.units_firing{ init_units = {"[blue]"}, flag = 101, weapons = { "AGM-65D Maverick", "AGM-65H Maverick", "AGM-65G Maverick", "AGM-65K Maverick" } } end Additionally, if you want a chat message displayed that identifies the shooter, use this instead: if slmod then slmod.units_firing{ init_units = {"[blue]"}, flag = 101, weapons = { "AGM-65D Maverick", "AGM-65H Maverick", "AGM-65G Maverick", "AGM-65K Maverick" }, msg = "%s: RIFLE!", display_units = "i", display_time = 5, display_mode = "chat", coa = "blue" } end If this doesn't work, it could be that the names of the Mavericks have changed. To check that they are still the same names as the ones in the scripts above, fire a Maverick, then look in C:\Users\<Your Account Name>\Saved Games\DCS\Logs\debrief.log.

Yes. When a map object dies, it generates a unit dead event. You can query the location of the map object with Object.getPosition (even AFTER it dies), and compare its run time id with the run time ids of the other active objects in the mission, as well as compare its position with the positions of static objects harvested from env.mission. Thus, you are able to determine if a map object died, and where it died at. It's rather complicated, but the scripting library Grimes and I are working on has this functionality already created for you. An easier way to do it exists though- at least across the same patch, it appears that map object run time ids do not change. If you're looking for a specific map object to die, you can always harvest its run time id by killing it and then looking in debrief.log- debrief.log lists the run time id of destroyed objects. Now, in your mission, you can just make an event handler that does some action when that specific run time id is killed.

Yes, you're right, the documentation was never fixed for this. I'll get around to it when I get a chance. The reason Saint (Святой) or I never fixed the documentation on this was because I had mentioned the awkward implementation and he had mentioned he would change how event handlers worked. So there was no point to fixing it until the final implementation, but I guess Saint was never able to get around to it. He is incredibly busy :) Though Saint doesn't like it :D, an alternate method for handling events is like this: do local old_onEvent = world.onEvent world.onEvent = function(event) <your new code> return old_onEvent(event) end end

Yes. I've been porting Slmod code over to the mission scripting environment so that some of the Slmod functionalities carry over there. This is one of them. Grimes and I are working on this together, in fact, it's been a bit on hold since I had to take this trip (I am in the process of moving out of Austin, so you know how it goes...), but we hope to get back to it soon. Basically, here's the way you do it: Use env.mission to make a database of units. env.mission contains all the data you need- such as unit name, unit type, etc. Use Unit.getByName to get the Unit objects of these units. Use Object.getPosition to get their position, and use the .p component to get their map position. Anyway, once we're done with the scripting library, it will have this functionality.

The reason the function works as it is- it leaves the flag on rather than turn it back false- is that it is more logically complete. If the function automatically turned it back off, then your trigger logic might miss momentary "in zone" events that you would actually want to detect (the documentation might not say so, but the interval variable, that determines how often you check for "in zone" status, can actually be set to a number less than 1- so you could use this to detect fast moving objects very quickly passing through a small zone). Furthermore, if you were trying to do this same thing through triggers, you'd have to have extra trigger logic to turn off the flag when the units were outside of zone as well. "Momentary" triggers do not exist by themselves, you have to build them. For these two reasons, I decided to make the behavior that the flag turned on and stayed on. Additionally, the point of Slmod, in this function's case, is to simply trigger logic, which it does- if you had 10 "zone units" and 10 units, you'd need at least 100 triggers. Three is a HELL of a lot better than 100. So Slmod succeeds in this, and I considered the functionality "good enough". You are correct though- it could be made even more simple for some cases. What I need to do is provide a further optional variable to some functions that, if set true, makes it so flags turn off if the conditions that function detects are no longer being met. You don't need three triggers to make the flag that Slmod modifies constantly reflect the condition the function detects. When the conditions are being met, the flag is being set true every interval seconds (interval is an optional input variable of several Slmod functions, including units_in_moving_zones). Remember that the interval variable defaults to 1 if not specified. So if you need a flag to continuously reflect the in zone/out of zone condition, and interval is 1, then do this: Switched -> Time Since Flag (X, 2 seconds) -> Flag off (X) Remember that the game's internal "time since flag" timer is reset to zero every time the flag is set true, even if it was already true. If you specify the interval variable of the slmod.units_in_moving_zones function to a time less than 1 second, then you could even reduce the time since flag number from 2 to 1. Finally, avoid Time Since Flag (X, Y seconds), where Y is some number equal to, or very close to, the value of interval- the behavior of this is likely not deterministic. That's why I used Time Since Flag(X, 2)- interval was 1. If interval had been 10, then I would have used Time Since Flag (X, 11).

It would be possible to modify it to turn off the flag, but I'm not sure that's a good idea. It could be added as an additional input variable, I suppose. I don't quite understand why you need 30 triggers. Can't you just do this? slmod.units_in_moving_zones{ units = { '[g]EnemyTanks1', '[g]EnemyTanks2', '[g]EnemyTanks3', '[g]EnemyTanks4', '[g]EnemyTanks5', '[g]EnemyTanks6', '[g]EnemyTanks7', '[g]EnemyTanks8', '[g]EnemyTanks9', '[g]EnemyTanks10' }, zone_units = { '[g]FriendlyTanks' }, radius = 6000, flag = 101 } ****Note that Lua is not white space or carriage return sensitive, unlike crappy competing scripting languages **cough** Python **cough**. So the above code works just as well as if it had been all placed on a single line, but is VASTLY more readable.**** Flag 101 will be set true when any of the units within the groups "EnemyTanks1" through "EnemyTanks10" comes within 6000 meters of any of the units within the group "FriendlyTanks".

Which is what? I had heard that someone was going to try to send actual data back in time a few years ago, that they were still trying to set up the experiment (of course :D). Is that not "this" experiment? I'd like if I could get a link to whatever this is :)

Monotwix, it's important to understand that there is no such thing of simultaneity between two spatially separated points. So the problem is, if "instantaneous" communication is possible, it will violate causality. It will be possible to send information into the past. One observer will see information transmitted simultaneously, and other observer in a different frame of reference will see it go back in time; yet another observer in a different frame of reference could see it go forward in time. So we don't know if the causality is a fundamental law of the universe, but I'd say it's a good bet :) In this case the overwhelming majority of quantum physicists agree that you cannot send information back in time with quantum entanglement. It's also important to understand- just because some random, nobody university professor somewhere is doing some kind of experiment- that doesn't mean that the experiment is legitimate science. Once you get tenure, you can do all sorts of stupid crap. I've heard of folks working on anti gravity/perpetual motion machines, which is pretty much the same level of whackiness as instantaneous communication using quantum entanglement :no_sad: You talk about unpredictability and how we should bet on the unknown, and then you make broad assumptions and statements that say it's unlikely that a government would fund interstellar travel. How can you know this? How can you know what society will be like in 200 or 300 years? Maybe we'll have robotic space factories mass producing space equipment from resources mined out of the asteroids, and fusion pulse rockets that cruise folks around the solar system from Mars to Earth in a few weeks rather than months or years. Maybe it will be a simple matter to "uprate" one of these fusion pulse engines and so that it can deliver a small scientific payload to a nearby star system. Personally, I think you're concerning yourself too much with fringe ideas and slight possibilities, and not fully considering the implications of the known and proven physical laws. We don't need unlikely fringe physics to visit the stars, and given the unknowns of how society will develop, in this case towards the utilization of space, it's a little premature to make judgements about whether or not it will be one day affordable to send out nuclear propelled spacecraft to the stars.