Grimes

The screenshots of the maps on this page have the bullseye icon located at 0,0 for each map. https://wiki.hoggitworld.com/view/Category:Terrain_Information You can also use alt+y to toggle the coordinate type and see the x/y coords directly in the editor or F10 map.

In my quick test the AI that engaged only did so with its missiles. Once it ran out of missiles it returned to base. It appears that the source of the problem was the targets and the A-10 itself. The AI simply don't want to engage using guided or unguided bombs with air defenses present. If you change their reaction to threat to "evade fire" or less reaction then the AI will engage just fine. The A-10 was a factor in that due to its parameters it knows its not fast and therefor is more threatened by the mere presence of certain sams or other defenses. What was weird was that it flew over the target to get to the end of its route anyway rather than just RTBing.

If a route was assigned via mist.goRoute or defined when spawning the group via mist.dynAdd it would be possible to save it and then look up for later use. Unfortunately there is no function to get a route that was assigned by another script or CA. Also cannot get any information about or from targeting pods. The best alternative for recon would be to use mark panels, track where smoke rockets land, or do something with custom F10 menues.

Its just the description.lua for any given livery. However that would be more used for "use Y texture instead of X" and not changing the animation argument of a sub-object attached to the aircraft. So it might not be possible just yet.

Updated fix to the develop branch on github. The PvP stats had some mismatched entries for adding their stats, so it errored out. While investigating this bug it made me realize how old/out of date some of the PvP code is. It was originally made when the game was just the A-10, Ka-50, and FC3 aircraft. It conditionally adds the PvP stat based on the types of objects killed, for instance if you shoot down an A-10 or a helicopter in a fighter it wouldn't give you +1 on the kills, meanwhile if one of them killed a fighter it'd count +1 on their kills. I'm halfway tempted to ditch the rules aspects of it in terms of counting things and only use it for the PvP message. As it stands its just a fixed list of unit types which I don't want to have to keep manually updating for relevant aircraft types, which is something I'd prefer to avoid to say the least. So if anyone has thoughts on the matter I'd appreciate it.

Gotta do what all of the persistence scripts use by modifying your missionScripting.lua file so you have access to the io and lfs libraries. Using lfs you can get data about different drives. Typically I just use it to get the saved games location to save a file in logs, scripts, or wherever else. local defaultDrive= lfs.writedir() .. [[Scripts\]] Then you can use io.open, dofile, or there are probably others to be able to load the contents of a given file. To save it the easiest way is to just write the whole file in one go. That typically looks like local myTable = {['player1Stats'] = {['kills'] = 5, ['RIOsKilledDueToFlatspins'] = 1}} local wFile = io.open(defaultDrive .. fileName, 'w') wFile:write(mist.utils.serialize('myTable', myTable)) wFile:close() wFile = nil Depending on how you load it or wanna write to the file then things can get pretty complicated quickly. For instance I tend to use something copied out of slmod where it is closer to "streaming" where it writes line by line as things happen. After a while you end up with the lua file filled with the same entry listed multiple times, except for the value was changed. When the table gets loaded by DCS it just reads the last written value as the actual one. But as long as you aren't writing stupidly massive files extremely often it doesn't do a ton of harm to periodically write the whole file in one go.

I suppose it depends on if the index each entry is at matters or if it is simply checking to see if it exists. From your example I'm gonna guess its the latter. In essence "I have the table aircraftClientBlueCAPTypes and I wanna see if anything in here is in aircraftClientBlueCAPTTypesLibrary". To brute force it you can do something like this: local totMatches = 0 for i = 1, #aircraftClientBlueCAPTypes do for j = 1, #aircraftClientBlueCAPTypesLibrary do if aircraftClientBlueCAPTypes[i] == aircraftClientBlueCAPTypesLibrary[j] then totMatches = totMatches + 1 break -- this breaks back to iterate the next i index. end end end Typically for anything I do that is looking to see if a string or number exists in another table I make sure to have that item listed as a key rather than a value. For example: aircraftClientBlueCAPTypesLibrary = {['F-15C'] = true, ['FA-18C_hornet'] = true, ['F-14B'] = true, ['F-16C_50'] = true} local totMatches = 0 for i = 1, #aircraftClientBlueCAPTypes do if aircraftClientBlueCAPTypesLibrary[aircraftClientBlueCAPTypes[i]] then totMatches = totMatches + 1 end end In a practical example I'll usually have other data stored there that is useful for whatever I need. I use this table in On Station to choose which format is needed to display coordinates to different aircraft types. local coordsUsed = { ['A-10C'] = {{def = 'DMS', p = 3}}, ['AV8BNA'] = {{def = 'DMTS', p = 3}}, ['FA-18C_hornet'] = {{def = 'DMS', p = 4}}, ['F-14B'] = {{def = 'DMTS', p = 1}}, ['F-16C_50'] = {{def = 'DMS', p = 3}}, }

Took a quick gander through some of the PvP code and I think I might have found a problem. Its way to late for me to test this tonight, so will have to check tomorrow. In the mean time setting pvp_as_own_stat = 0 in the config file could eliminate the errors as a temporary solution.

I'm sure there is a schedule I just don't know if it was posted publicly or not. In terms of slmod the 7.6 dev branch is working for multiple servers on the most recent open beta patch. Which is why having the logs could have been helpful in diagnosing why it isn't working for you.

http://lua-users.org/wiki/TutorialDirectory and http://lua-users.org/wiki/SampleCode are pretty helpful for learning the basics of lua. https://wiki.hoggitworld.com/view/Simulator_Scripting_Engine_Documentation is more specific to DCS but a lot of the principles remain the same.

If you could post the DCS.log anyway it could help to pinpoint the cause.

Just checking Group.getByName() is a very simple test to see whether something is returned. For a while any group that was dead failed to return, but at somepoint that was changed. So it is best to check for other values. I like to use something like this. if (Group.getByName('whatever') and Group.getByName('whatever'):getSize() == 0) or not Group.getByName('whatever') then -- do code end Basically if the group object is returned, but it has no units alive or the group object isn't returned then respawn the group or whatever else you want to do. I also do this check which also covers the bases. local function groupIsDead(groupName) -- a certain bug hasnt been fixed, so I have to use this instead. if (Group.getByName(groupName) and ( Group.getByName(groupName):isExist() == false or #Group.getByName(groupName):getUnits() < 1)) or not Group.getByName(groupName) then return true end return false end Difference being it checks isExist() or can fall back to checking the size of the getUnits() table.

Those task architypes have never had any enroute tasks available to them. It is mostly due to what the actual task is for. This wiki article might help explain: https://wiki.hoggitworld.com/view/DCS_editor_AITasking#Perform_Task_vs_Enroute_Task But here is a quick explanation. Basically enroute tasks are permissions for AI to go do something where-as perform task is more like an order to do it. Bombing, pinpoint strike, etc are mostly meant for attacking points on the map, perhaps a building on the map. Normally the AI has no reason to want to attack some random building, its one of thousands in a given area and most buildings that are part of the map have thousands of copies throughout it. There is nothing to make that specific building special to the AI. On the other hand when you have a sam site or static object that belongs to a coalition then the AI automatically know they would be allowed to attack it. In a more direct example with something like CAS: Perform Task> Attack Group: - > Tells the AI to go directly to that target and attack it. Will ignore anything in their way until that task is complete Enroute Task> Search And Engage Group: - > Tells the AI they are allowed to attack that group. However the AI will fly their route normally, but will attack that group once it becomes detected.

Pushed a minor update. Added some clarity to that note in the config with your suggestion. Also fixed the issue with slmod having an error on first load when it created the config file.

The difference between a single player and MP/co-op mission is the addition of "client" skilled aircraft. Its always been relatively easy to go into the editor modify a mission to add those client slots to existing missions. However you still have the limitations of MP where logbook stats aren't tracked, you can play individual missions from a campaign but its done outside of the campaign UI and you don't get "credit" for it, and certain triggers will only work on the host and not any of the clients. There is also the fact that triggers for single player missions are typically made to check only the "player" aircraft, so if not modified there is always a chance that the slot goes un-occupied or things trigger at incorrect times. For example in SP the player is expected to go to a trigger zone in order to progress in the mission and the trigger isn't modified to look for any of the aircraft in MP, then only one aircraft slot is capable of tripping that trigger.

--[[ ------------------ -- Note due to a formatting issue I don't want to deal with, for the example directly below replace each { with [ and } with ] ----------------- admin_tools_mission_folder = {{C:\Users\John\Dropbox\Dedicated Servers\Slmod\Missions\}} LEAVE THIS VARIABLE AS nil IF YOU WANT TO USE THE DEFAULT FOLDER!]] admin_tools_mission_folder = nil I know, there is a note there directly above it. Initially did it that way as a workaround to when I updated how slmod loads the config file. Basically a multiline string in lua is contained within double brackets [[ to ]], but lua requires a different formatting if you wanted to have multiple sets within each other. --[[ [[This will error]] ]] So I changed it to {{}} and left a note to change it. Big difference is with [[C:\folder1\folder2\]] is you don't need to use double \\ to escape out of the \. So either should work. Since I gotta upload a fix to the config file anyway for one of the bugs you reported on the discord I'll see about fixing that.

It would take substantial changes to all of the message to support multiple languages. Most of the messages are not written as a single block of text but assembled based on different conditions. By no means impossible just a bit of work and also need to think of a way to do it that makes adding other languages easy to add. For example this is how part of message of the day is written: titleTbl[#titleTbl + 1] = '\nThis server is running Slmod version ' titleTbl[#titleTbl + 1] = slmod.mainVersion titleTbl[#titleTbl + 1] = ', build ' titleTbl[#titleTbl + 1] = slmod.buildVersion titleTbl[#titleTbl + 1] = '. To see the Slmod help menu, say "-help" in chat.\n' To support other languages I'd either do it how DCS does it with something that looks to see if there is a translation of each phrase and replaces it if found or write as much of the text as a big block but search for key phrases to replace values as needed. The first would work better with how most of the messages in slmod are written, but would probably have some translation oddities. The 2nd would be better for any syntax differences between languages but would require extensive changes to every message. It is certainly something that should take input from people that speak other languages for what would work best for them.

Delete DCS World\Scripts\MissionScripting.lua and run repair again.

That is the miz format pre DCS 1.5. The new format is similar, the only difference is there is a l10n folder with two sub folders that contain embedded files and a lookup dictionary for localization. The way of running the script is the same, just gotta make sure the trigger condition executes in order for the script to run. I usually use Once> Time Less 10> Do Script File or Mission Start> Time Less 10> Do Script File.

There are a few complications regarding pilot_dead, eject, and pilot_landed events that make completely accurate stats difficult. 1. Pilot landed event is missing some data with the scripting engine depending on when it occurs. Its actually kind of annoying since the entry exists in the event table but an error occurs if you try to use it. 2. Pilot dead event is called instead if the pilot lands in the water. This event also is missing which pilot it is if the aircraft they ejected from is destroyed before the pilot dead event is called, which is likely to happen. 3. Timing. Essentially it has to keep track of ejected players and then when a pilot landing event occurs again it goes back and changes the stat to reflect it. Timing comes into play because the time it takes can create issues, namely if you eject at 30000ft it takes roughly 19 minutes for the pilot to land. So it is possible to spawn in again, do whatever, and even land before the previously ejected pilot reaches the ground. This also means that if you eject in the closing minutes of a server then however the stat would be changed wouldn't occur because the event didn't happen. Its important to keep in mind that slmod treats eject and pilot dead events independently. Eject doesn't mean a successful ejection, it just means the player commanded an eject. A possible solution is for me to add another stat entry of "killedWhileEjecting" and use something similar to what I've used for other stats. Basically it logs when a player ejected and if a pilot dead event occurs within a short time then it'll add to the killedWhileEjecting event. It might miss some due to the aforementioned issues with pilot dead events. Otherwise it'll have to make a guess in some instances, say a pilot dead event occurred but has no initiator, then assume it was the guy who just crashed. But that could result in not accurate stats.

BTW there appears to be issues with the JSON export. The way it was written originally always did the JSON conversion, the setting just dictated whether or not to save it. Coupled with an error occurring if data was formatted in a certain way it would prevent slmod from fully loading. The hotfix changed when it does the JSON export so the error will only occur if json export is enabled. So please disable it for the time being. It is more of a DCS bug, but aspects of it are created via slmod for how it saves penalties on multicrew aircraft.

Yes, but its a round about way of doing it. The unban admin command is used for the manual bans. The auto-bans are handled, well, automatically, and based on how you have it setup they will eventually be re-allowed in. Since I don't have a reallow exemption feature in slmod at the moment you will have to forgive specific offenses. Either editing the file or forgiving via command works. However editing the lua file won't immediately "take" and I wouldn't be shocked if it gets annoyed when you save it if the server is running and has that file open. To edit you have to add a ['forgiven'] = true, entry for each penalty you want to forgive. Easiest way is with the admin command though, which you can use on the remote server control or while connected to a server. Just gotta forgive until their points will below the ban threshold, at which point they will be allowed to reconnect. The two relevant commands are: -admin score statID <id> -admin forgive <id> <type> <index> id being the id associated with them, find their name in the main stats file and they will have an id = X value. type is a two letter word th, tk, ch, ck for teamhit, teamKill, collisionHit, collisionKill. index is whatever entry index that offense is under.

Build 143 pushed to develop branch. Added: option for json stats export - It is a simple boolean setting in the config that when enabled will save a copy in json format of the main, penalty, campaign, and mission stats whenever one of this is opened. Added: Stats writing buffer. This will reduce the amount of writes to the stats file, but will have a slight delay from when the event occurred to when it is written. Fixed: Dakka in Huey and Mi-8 naming for multicrew seats Fixed: Multicrew defs and auto generation of multicrew seats for unit types not pre-defined in slmod. Fixed: crash stat not counting when AI stats are disabled and when the player was killed by AI. Fixed: issue of stats not displaying due to an added stat value for losses being present. Added: pilotError and crashLanding stat to stats display. Added: WIP feature of best and current life. This is disabled at the moment but code is present and config options exist for it.

A score of exactly 50 means you stay on the same stage. Anything below 50 it moves backward a stage and above 50 forward a stage. The score is determined by "Mission Goals" which you have not setup in your missions. Thus no matter what happens the score is always 0 when you end it. Mission goals are accessible via the icon directly below triggers. It looks like a square with lines forming a target of sorts. Mission goals behave much like triggers but are evaluated constantly. 2. It needs to have a mission within the range of 0-100. It can't have an empty spot because this score is what is uses to determine which missions it is allowed to load on the stage it is moving to. If you had 2 missions with a range of 20-40 and the other with 60-80 then if the score was 0-19, 41 to 59, or 81+ then there would be no mission it is allowed to load. Just to give an example of how it'd work, assume you setup the mission goals and then basically copied that one stage so there are 3 stages with the same rules, but changed the names of the missions slightly. You start on stage 1, TBH I'm not sure which mission it would select on campaign start, but say you win the mission and the score was 70. It would move to the next stage, but due to how the missions are setup in terms of the score then you'd get Flak-2-4.miz. If you got 70 or more points again then you'd be playing flak 3-4. Now on flak 3-4 you lost and only got 10 points then you'd go backward a stage and would play flak 2-1. You played that mission won, but barely via 55 points, then you'd be playing flak 3-2. If you changed the goals to be flak 1 and 2 are 0-50 and flak 3 and 4 are 50-100 then when it moves to a stage it has a chance of picking any mission within the range at random.

There are several different fuses on the updated 3d model thats been in the game for a good year or two now. I'm not really sure why it was added but not implemented yet other than they actually want the fuse to be functional. As far as I know you might be able to get it to be changed via code in the livery file, but I seem to recall something about the model of the the bomb reverting to its default state the moment it is dropped.