Speed

coalition.addGroup has the ability to spawn unit groups dynamically, anywhere, anytime, with any properties. It is perfect for UH-1 insertion missions. I had a code example somewhere where I tested it. When I get done with what I need to do for Slmod, I'll post it.

Attached are the Slmod version 6.3 files which should be fully compatible with 1.2.4. First post in this thread updated too. Slmod 7.0.056 completed and undergoing testing; should testing be successful, I'll upload it to Dropbox for those who have access either tonight or tomorrow. Considering all the scripting changes in 1.2.4 this is far from guaranteed, however. This should be the last testing version before I publicly upload Slmod version 7. (No Servman) Slmod Version 6.3 for 124.zip (Servman) Slmod Version 6.3 for 124.zip

This actually sounds a bit more like a game related issue, as Slmod can't cause clients to crash (not directly). However, do keep in mind that the version of Slmod you are using was not intended to be used with 1.2.4. Check the Slmod thread, as I will soon have a version created for 1.2.4, and also, Slmodv7 will be out soon. Please upload the mission and provide detailed instructions on how to replicate the issue so that we can report this one to the devs and get it fixed.

Hmm... sounds just like a general Lua error. Maybe you should just wait till I release v6.3 for 1.2.4 and v7.0.056 (you're one of those with access to the Slmod dropbox folder, right?). They both should be ready shortly.

The default display mode for admin menu was changed to trigger text in v056. So if you are in an aircraft slot, you will see trigger text rather than chat. Only if you are in a combined arms slot or spectator slot will you see chat. Note that you don't actually have to be IN an aircraft to get the trigger text, at least, last I tested. You merely have to be in an aircraft multiplayer slot. I believe this is still applicable, but things change. If there are enough players or missions though, even as trigger text, it will overflow the trigger text box if there is enough text to be displayed. How many lines that is... I donno. It will depend on your screen resolution though, I'm pretty sure. I doubt public servers will be able to handle enough players for such a problem to occur, at least in the short term. Eventually, a multiple pages kind of thing could be necessary, but the above change will probably be sufficient for the short term.

It's a bug in the scripting engine introduced with 1.2.4. If you are refering to Slmod v055, then if you look in the SlmodUnits.lua file and change the slmod.create_getUnitXYZ from function slmod.create_getUnitXYZ() -- function to return unit x,y,z data. local getUnitXYZ_string = [[slmod = slmod or {} slmod.getUnitXYZ = function(rtId) local unit = {id_ = rtId} if Unit.isExist(unit) and Unit.isActive(unit) then local pos = Unit.getPosition(unit).p return table.concat({pos.x, ' ', pos.y, ' ', pos.z}) end end]] net.dostring_in('server', getUnitXYZ_string) end to function slmod.create_getUnitXYZ() -- function to return unit x,y,z data. local getUnitXYZ_string = [[slmod = slmod or {} slmod.getUnitXYZ = function(rtId) if timer.getTime() > 0 then local unit = {id_ = rtId} if Unit.isExist(unit) and Unit.isActive(unit) then local pos = Unit.getPosition(unit).p return table.concat({pos.x, ' ', pos.y, ' ', pos.z}) end end end]] net.dostring_in('server', getUnitXYZ_string) end I THINK that will fix it. I'm going off of memory here... I am using a better fix than this crude bandaid in the code I'm currently using, but the above change should work. Otherwise, you could just wait for Slmod v056.

OK, the plan is to release Slmod 6.3 for 1.2.4 tonight. That assumes I hit no further snags. In my internal work-in-progress version of Slmod v7, the ban by id is now working- you can simply type in "-admin id ban" and get a list of all players in the mission, indexed by an ID number. So say you wanted to ban player #13 on this list, you would then just type in "-admin id ban 13". I will copy this functionality over to kicking as well, so you can kick players by id too. Once that's done, (and I address another annoying little bug that's popped back up), I will be uploading Slmodv056 to the Slmod testing dropbox folder. That will probably happen between tonight and Sunday. Looking through the todo list for Slmod v7, I realize that I really NEED to do the following before Slmod v7 is publicly released: 1) New autoban/autokick feature based off of SlmodStats. 2) Stats- filter out kills by ramming your aircraft into enemies. If you kill an enemy by colliding into them, it gets added to a "kamikaze" category. If you kill/injure a friendly by colliding with them, it gets added to a friendly collisions category. This filtering will help make a more intelligent autokick/autoban feature, because without it, you could get auto-banned for some idiot colliding with you while he was doing an illegal taxiway takeoff or something. The kamikaze category will also be a fun category to try to build up kills in :D

OK, I tracked the issue of internal versions of Slmod v7 causing the game to crash on loading to a change in the way DCS was loaded. Now, calling a certain script at a certain time will cause the game to crash. I added protections to keep that script from calling before the game has started. I have fixed the problem on my work-in-progress version of Slmod v7. To help with problems like this one, I'm thinking that I will change a bit the way that Slmod runs. I need to make sure that the main part of Slmod only runs after the mission has fully loaded, and it does not run any time after the game begins to shut down. DCS has been getting increasingly finicky about having Lua scripts running during these time periods. Anyway, I think I will be releasing an updated version of Slmod 6.3 for 1.2.4 shortly, despite what I said earlier. This will allow me more time to properly test Slmod v7. I will have the newest Slmod v7 test build uploaded to the private Slmod testing folder shortly after (or before) that.

Hey guys, I'm aware of the issues with 1.2.4 and Slmod and they should be fixed in a couple days. Sorry for the inconvenience! What I'll probably do is makle a pre-release Slmod v7 version available rather than go back and fix 6.3 too.

The most exciting addition, IMO, is the ability to dynamically spawn groups not included in the mission file, see here: http://en.wiki.eagle.ru/wiki/Part_1#coalition Scroll down to coalition.addGroup

Hopefully eventually. Ideally, the game passes the actual weapon object to Lua for each weapon shot event, so that Lua is able to query that object and determine what type of weapon it is. However, last I checked before I had to go away, there were issues with client-fired weapons- the event was giving the incorrect game object for the weapon sometimes, making it impossible to do anything other than detect that the client is firing some weapon. I reported it, but I don't know yet if it was ever fixed.

You can make things that look kinda like nukes, at least at night, but the frame rate is really bad. vGzUKRoTII0

RIP Jim. :cry:

OK sorry for my extended absence. I had a lot of stuff going on, and not enough left over free time to do anything useful. But my time is becoming more plentiful now, so I should be able to start work back on Slmod again. This ability was already in testing when I had to stop work on DCS stuff (due to lack of free time) about a month ago. I didn't want to make a big fuss about it because I didn't want people to realize that they could bypass the kick ban system like that. Indeed, the solution I came up with almost exactly as you describe, when you type in, "-admin id ban", a submenu is displayed showing id numbers and what command you type to ban them, something like "-ban 10" will then ban the tenth player on the list. The same will exist for kicking, too. Additionally, I plan to add an optional variable for kick, the duration (in minutes) you wanted them kicked for. For example, "-admin 30 kick <player name>" will kick a player for 30 minutes. I know that "-admin kick 30 <playername>" is more logical, but due to the way that the entry system works, it's not possible. I want the kick time variable to be optional; so what if someone's name is like "55 Pnut"? It would try to kick a non-existent player named "Pnut" for 55 minutes. Thus, the optional time variable must come before the required keyword "kick". I plan to make this optional kick time variable available for the new kick-by-id menu too.

I learned triggers in 2009 by reading the BS GUI manual section on the mission editor, then testing some of the logical rules/situations not covered in the manual.

There were a couple problems. Try the attached code and see if it works. do local runwayHits = { [1] = {}, [2] = {}, } -- Runway segment polygon zones local segmentPolys = {} segmentPolys[1] = mist.getGroupPoints('segment1') segmentPolys[2] = mist.getGroupPoints('segment2') local tracked_wpns = {} local shotHandler = function(event) if event.id == world.event.S_EVENT_SHOT then if event.weapon then local wpn = LuaClass.createFor(Unit, event.weapon.id_) if wpn:isExist() then local wpnName = wpn:getTypeName() if wpnName and type(wpnName) == 'string' and ((wpnName:find('BetAB_500') or wpnName:find('BetAB_500ShP') or wpnName:find('Mk_82') or wpnName:find('Mk_84') or wpnName:find('Mk_82AIR') or wpnName:find('GBU_31') or wpnName:find('GBU_38') or wpnName:find('GBU_10') or wpnName:find('GBU_12') or wpnName:find('FAB_500') or wpnName:find('FAB_250') or wpnName:find('FAB_500P') or wpnName:find('FAB_250P') or wpnName:find('FAB_500_3'))) then local init = LuaClass.createFor(Unit, event.initiator.id_) local init_name = '' if init:isExist() then init_name = init:getName() end tracked_wpns[event.weapon.id_] = { wpn = wpn, init = init_name, pos = wpn:getPosition().p, dir = wpn:getPosition().x } end end end end end mist.addEventHandler(shotHandler) local function track_wpns() mist.scheduleFunction(track_wpns, {}, timer.getTime() + 0.05) -- reschedule first for wpn_id_, wpnData in pairs(tracked_wpns) do if wpnData.wpn:isExist() then -- just update position and direction. wpnData.pos = wpnData.wpn:getPosition().p wpnData.dir = wpnData.wpn:getPosition().x else -- wpn no longer exists, must be dead. tracked_wpns[wpn_id_] = nil -- remove from tracked weapons first. local ip = land.getIP(wpnData.pos, wpnData.dir, 20) -- terrain intersection point with weapon's nose. Only search out 20 meters though. local impactPoint if not ip then -- use last position impactPoint = wpnData.pos else -- use intersection point impactPoint = ip end for i = 1, #segmentPolys do if mist.pointInPolygon(impactPoint, segmentPolys[i]) then -- weapon impacted in West runway segment! runwayHits[i][#runwayHits[i] + 1] = wpnData.init end end end end end track_wpns() function scoreMission() -- for testing right now local hitBonus = 50 local reqPoints = 150 local scoreTotal = 0 local scoreWest = 0 local scoreEast = 0 local westEndFlag = 2000 local eastEndFlag = 2001 local runwayHitsWest = runwayHits[1] local runwayHitsEast = runwayHits[2] for i = 1, #runwayHitsWest do local hitScoreWest = 0 for i = 1, #runwayHitsWest[i] do hitScoreWest = hitScoreWest + hitBonus end scoreWest = scoreWest + hitScoreWest end for i = 1, #runwayHitsEast do local hitScoreEast = 0 for i = 1, #runwayHitsEast[i] do hitScoreEast = hitScoreEast + hitBonus end scoreEast = scoreEast + hitScoreEast end if scoreWest >= reqPoints then trigger.action.setUserFlag(westEndFlag, true) end if scoreEast >= reqPoints then trigger.action.setUserFlag(eastEndFlag, true) end end end

Everyone I've talk to in my squad, the VTAG, a lot of whom spend a lot of time on your server. Everyone not affliated with the 104th who I saw posting in this thread. Several other community members I have talked to. It is probably at least a dozen people. To be honest, I still haven't talked to anyone who prefers the traditional 104th mission model who is not in the 104th or 51st, but that could be because I usually fly with DCS pilots, not FC pilots. I could also be getting a biased sample due to the effect that people who are happy rarely say so, it is only those that are dissatisfied that speak up. Of my DCS time, 3/4 of it is spent modding/testing. Of my remaining 1/4 time, I would rather not fly on a mission I do not enjoy, so why should you expect me to play on a server that only hosts missions I do not like? When I go online, and the VTAG is flying on the 104th, I just go back to modding/testing, or I hop onto another server and see what is going on. I didn't want to just openly say I do not like the missions that the 104th traditionally hosts, but I can see no way around saying it, because you asked why I never fly on the 104th. I'm sorry if that upsets you- that I don't like the missions the 104th traditionally hosts- but let me ask you- when has anyone ever created anything that EVERYONE likes? It has not happened in the history of the human race. The best movies in the world still get negative reviews. All the missions I've made- I get a significant fraction of players who do not like them at all. I try not to take their criticism as a personal slight unless it's clearly in a disrespectful manner. I have also tasted dozens of beers over the years, light, dark, cheap, expensive, etc, and I find the taste of every single one of them terrible. That does not mean beer is bad, that just means that I do not like it. So if you feel affronted that I don't like the missions the 104th hosts, and that others might like the missions you host but wish for something to be improved... then maybe just think of the 104th missions as something like beer :D So having western aircraft only on one side, and eastern aircraft only on the other side is "hardcore" realism? Even HAWX probably had aircraft types segregated according to national origin. I am not an advocate for hardcore realism, at least for a public server mission, because hardcore realism is probably incompatible with a public server mission. Actually, from the way you are reacting, challenging my experience and implying I am being less than honest about the other people I have talked to about the 104th air-to-air mission style, it seems apparent that you don't appreciate my feedback. Maybe I'm reading you wrong, but that's the way it seems to me. I do appreciate what you and the 104th provides for the community. If at any point I let my frustration through that I do not enjoy the 104th missions that a lot of other people do, I apologize. As I have said repeatedlyin this thread, I think that the 104th's symmetrical mission formula is a good one and it should not go away. It is clear from the number of players that participate, from common-sense arguments I agree with, and from valid points raised by Frostie and Riptide, that the traditional, symmetrical 104th/(51st?) style mission has a place and shouldn't go away, at least not anytime soon. But it is not for me, and that is why you never see me on the 104th server, and lots of other people, many of which are in fact regular 104th flyers, would prefer an alternative as well. If the 104th only had one server available, then I could understand the reason to stick to the old tried-and-true formula, but since there are TWO servers, then why not try something new? Maybe, on one of your air to ground server missions, just add some red slots, maybe add a bit of blue AI fighters that only spawn if no blue human fighters exist, and see what, if anything, happens. I guess my point/ideas could also be summarized as this- for some reason, when it comes to incorporating PvP into missions, we ONLY ever see people creating missions that are either "all in" or "all out". The mission editor is fully capable of creating "halfway" missions- and the asymmetrical mission model I propose is one such "haflway" mission. Anyway, whenever I get time, I will probably eventually try creating this asymmetrical mission... I have two servers with fairly high bandwidth that I could try hosting it on. Maybe we can find out if it works.

That may in fact be a lot of their motivation. But it goes beyond that too. I remember flying in the 104th as a Ka-50 pilot. Several times, I got buzzed by a "friendly" aircraft that was just trying to show off. I can clearly VID the aircraft as like a F-15. Because all aircraft are on all sides, and I am a Ka-50 pilot, I have no idea if this is some guy trying to show off, or some guy hunting Ka-50s at low altitude. So I go into panic mode and try to hide... The fact is, besides the non-realistic nature of it, target identification both by TEWS AND by VID, which is the only method the air to ground strikers have, is completely broken when you have an aircraft type on both sides. If I am in an A-10, and I visually spot a MiG-29, I have NO IDEA (unless he gets close enough for me to see the actual markings) if I should shoot him down, or if I should ask him to form up with me. AWACS can give me an idea, but it is not 100% reliable. That is a valid point. Maybe the asymmetrical mission would not work so well during times when you have a lot of eastern pilots. It might be a good idea to have two of them- one for eastern times, and one for western times. And again, let me stress, as I said earlier, I do not favor the entire elimination of symmetrical air-to-air missions. I see the merit in them. I just favor the addition of the asymmetrical mission into the fold.

Symmetrical forces, at least with large numbers of air to ground attack aircraft, is a unrealistic scenario. First of all, the number of operational aircraft the USAF could throw into a theater far exceeds what the Russian air force has. Secondly, the USAF simply does not send the A-10 on suicide missions into airspace filled with enemy fighters. I don't think you see the difference between when I say asymmetrical and what is meant by unbalanced. I would give the side with fewer fighters certain advantages (already mentioned) that would balance the scenario out considerably- or at least, ensure that the outnumbered side is not overwhelmed in unfair fights. The point is about making a mission that is fun. That would be YOUR idea of what a scenario would be. I have a completely different one (read previous posts). Secondly, you're getting hung too much up on realism. My idea of improved realism is to move away from these meticulously symmetrical missions that are so symmetrical that the exact same aircraft fly on both sides. A significant portion of the community... well, to be honest, everyone I have talked to apart from 104th members- does not like this. We want F-15s on one side, and Su-27s on the other. No backstabbing Israelis :D Basically- improved realism = just a more realistic force balance (force balance ~= mission balance) and keeping east and west segregated as much as is practical. (It may not be practical, for example, to deny the blue side Su-25Ts- they might need player-based SEAD assets.) You're not addressing anything I proposed as a mission design- you've invented a concept that no one is in favor of, and is not related to anything that I previously stated. For example, where on Earth do you get this idea that I would make a mission that does not include F-15s and A-10Cs? :huh: Secondly, again, I think you're vastly overestimating the current state of the Russian air force. RuAF: ~300-400 Su-27 ~200-300 MiG-29 USAF: ~1200 F-16 ~700 F-15 And while probably the vast majority of those numbers for the USAF are in fact operating aircraft, I wouldn't be surprised if significant numbers of those Russian aircraft were in fact not operational- either in need of repair, waiting for parts, or cannibalized for parts. And finally, as far as realism goes, extreme realism is not the point. Making a scenario that could possibly happen in real life is not the point. Enhanced realism is the point. It doesn't even matter what the real life force balance is between the RuAF and the USAF, the mission I would build does not take place in real life.

Your talk about fuel is completely senseless. The Patriot, and almost all missiles, are SOLID FUEL rockets. There is no throttling them down or changing their fuel consumption rate. The rate at which they consume "fuel" (I prefer propellant instead- as "fuel" has a slight association with liquid) is fixed. Thus, the Patriots, in the 3 seconds it takes to make this turn, consume NO LESS or NO MORE propellant than they would if they had just flown straight. So, it makes no sense to talk about "fuel" because "fuel" is a fixed thing that will be consumed regardless. All that matters is that you talk about lower speed/lower max range/etc. Really, you should read up more on how missiles work. They don't need "fuel" to hit you, they only need velocity.

The only way a FLOT can work, and still have the gameplay fun, is to have an asymmetrical mission, which I spoke about earlier in this thread. Only ONE side should be doing air to ground, and that side should also have a significant advantage in air to air aircraft. The defending side needs to have some advantages, maybe good GCI, strongly defended airbases, and maybe they will win by default if the attacking side does not accomplish certain objectives within a certain time frame. Otherwise, if you throw the perfectly symmetrical air to air and air to ground forces against each other on the SAME FLOT, not only will it be unrealistic, but air to ground aircraft will have a half-life shorter than element 118.

Be careful what you wish for. They might need to improve/optimize their contrail/smoke trail effects first... last I looked, if I turned my head towards a bunch of contrails, it turned my game into DCS: PowerPoint. But I'm not big into graphics- so I haven't checked in a long time. Anyone know how the current smoke/contrail effects are on frame rates? Are they any better?

1) Get elected president, or 2) Use them under ground attack, with the bombing task (like in attached mission), or maybe 3) Use the scripting engine (you can't assign them an attack group in the ME, but maybe they will attack the group if you assign it to them via the scripting engine... it might also crash the game) predator.miz

In Saved Games/DCS/Config/network.cfg disable_events = true Disables the event notification cheat messages from server- now no clients will see any event message cheats (let's be honest- they are a cheat). To disable the message cheats locally, in Scripts/net/events.lua, Comment out all calls to the "report" function in the "on_kill" function. I don't know if the "on_player_kill" function does anything, but if you want to be safe, you can comment out all the calls to the "report" function in that function too.

Chameleon, all the fighting aside, you would probably do well to change the name of the missions. I was avoiding this thread until now simply because I thought that any mission going under the header WANKERCRAFT couldn't possibly be good. I'm not from the UK, and I don't even know what a wanker is (though I have some guesses, we *never* use that word in the US, and I've never bothered to look it up), all I knew was, from reading some British literature, it meant something dirty. And people who give their missions dirty names probably do not have good missions. So I'm a little surprised that, from the people who played the missions, they have something good to say. Maybe it's worth my time checking out the missions then. Chameleon, just understand that, whether or not you think the name is offensive is irrelevant. The fact is, people are avoiding these missions because of how you have named them. A perfect example would be me- I am not offended by the name, and yet I almost completely ignored this thread simply because of the negative connotation I have of the word "wanker" from the few times I've read or heard British people using it. I instantly judged the book by its cover and made some negative assumptions about the quality of the missions.