Speed

Yea, but I can't do anything with them right now- still away from DCS, on a trip, and just able to use my crappy laptop. Quite likely, it's been reported already, but if not, I will make sure to do it when I get back.

Sorry if I sounded a little defensive, it's just that that I'm not saying Slmod isn't to blame, I'm just saying this: Slmod is probably 100 to 1000 times less complex than DCS. However, Slmod is a mod that uses parts of DCS that the vanilla game doesn't. So for Slmod to be causing a problem, either it needs to have a bug (and generally, bugs in Lua do not cause things in the game to not work- the Lua simply won't work), or the parts of the game code it depends upon has to have a bug. Since the parts of the game code it depends upon is just a tiny percentage, and the mod is vastly smaller than DCS, it is very unlikely to be the root cause of a DCS problem you are having. Also, in this particular case, since Slmod contains no network code, that makes it even less probable to be the source of the problem. If you were reporting something like, "game is freezing sometimes in missions that use Slmod", then I'd think it more likely that Slmod could be the cause. But excessive network traffic just makes no sense in relation to Slmod, which contains no network code. Anyway, for any bugs you have with DCS itself, it's far more likely to be caused by DCS, or even, something outside of DCS interfering with DCS, than some comparatively small mod. That said, I still recommend uninstalling mods as one of the first steps to trouble-shooting. It's very easy to eliminate mods as a potential source of your problem then. And it also depends on the mod itself- things that significantly fool around with mission editor functionality or add new vehicles, that kind of stuff, are far more likely to cause problems than radio mods or server mods. So anyway, like I said, keep me posted as to what you find. I can think of a few remote possibilities where Slmod could be involved, and of course, there could be something I haven't thought of yet. As far as radio crashes go- one of the testers told me he thought he had found one with the Ka-50 radios. Contacting someone on the radio crashed him I think, at least once. I donno if it was reproduced though, I didn't check- I was getting ready to go on the trip that I am currently on. I hope to be getting back to testing soon so that I can help out to nail that potential bug down (among other things), if it hasn't been already.

Well, nothing in Slmod should be generating that much traffic, so if it is somehow related, it has to be a bug of some sort with DCS and Lua. I find this unlikely. I need this error report, and I need dcs.log. dcs.log is at C:\Users\<Your Account Name>\Saved Games\DCS\Logs\dcs.log. I just can't see how Slmod could be generating that much net traffic. It doesn't work over the net! Personally, I think it's another case of Slmod being in the wrong place at the wrong time and getting blamed for something it has nothing to do with. People always point fingers at the mod first before they suspect the game. That has probably happened about 10 times in this thread already, and Slmod hasn't been to blame yet. However, I won't wholly discount the possibility that there is a problem of some kind. Slmod has been running on other dedicated servers just fine, with no issues logging in to them with team viewer. What do you mean by "some kind of freeze"? An infinite loop in Lua will result in an infinite loop in the game (because they are on the same thread), but you will still be able to log into the server with remote desktop software. The game is stuck in an infinite loop, but to windows, it's still working. You should be able to log in to the server using whatever remote desktop software you use, see DCS frozen, and be able to kill it with the task manager. It should not lock you out. Anyway, yea, run your server without Slmod a few days, see if the problem comes back- if it doesn't, reinstall Slmod, and see if the problem returns. If it does, then upload a dcs.log here. Hopefully, by that point, I will be back home, and I will be able to investigate stuff myself. Keep me posted how it goes!

Yea, I think though, didn't they calculate that the interstellar ram scoop wouldn't work? Not a high enough matter density? I think it was either that or the ram scoop would have to be hundreds of km across.

Personally, I do not think that warp drives will ever be practical. Warp drives would violate causality, I believe, and I think the universe has a hidden "no cheating" law. :D But that's just my belief based off of the "trends" we see in the physical laws where it appears that the universe tries to prohibit, or at least make exheedingly difficult, any kinds of casaulity violations/faster than light travel. So, I think a full "theory of everything" would probably show that causality violations cannot occur. But, the universe has shown many times that it doesn't have to play by the rules that we think make sense. I don't think ion drives are feasible for interstellar flight. The acceleration is far, far, too low. Laser (or maser) boosted light sails are a good possibility, however, especially if we one day construct space-based microwave power stations for beaming power down to Earth. One of them could be taken off the power grid and used to propel a sail. Actually, you missed perhaps the most promising potential technology for interstellar travel- nuclear pulse propulsion. A fission pulse propelled spacecraft is possible right now. Basically, we would take a significant fraction of today's nuclear stockpile and break it down into tens of thousands of mini nuclear bombs. These are ejected behind the spacecraft and then detonated. There is a shock absorbing pusher plate behind the spacecraft that absorbs the shock, and transfers some of the explosions momentum to the spacecraft. One of these spacecraft could potentially reach 0.05c or so- so a trip to Alpha Centauri would take ~100 years. See "project Orion" for more info. A fusion pulse propulsion spacecraft ignites nuclear fusion in small pellets of deuterium-tritium fuel user laser confinement fusion, a technology under development right now at the National Ignition Facility (NIF). Anyway, the fusion explosion plasma is supposedly channeled and directed using some kind of magnetic nozzle. See "project Daedalus" for more info. With velocities possibly exceeding 0.1c, you could conceivably use such a spacecraft for a manned flight to Alpha Centauri, but it would be a long ride (~50 years).

You mean, beyond their dreams in terms of being able to visit personally? Yes, but we have several good ideas that should work on how we could build an interstellar spacecraft. Our grand kids could be the ones to build the first unmanned interstellar probe.

No, deactivate erases a group from existence.

Well, he wanted to get you a cake with an accurate candle count, but he couldn't get approval for it from the local fire department. However, I was able to find a cake with a more accurate candle count for you: Only 3 or 4 orders of magnitude too low.

http://www.space.com/18089-earth-size-alien-planet-alpha-centauri.html Summary: As you probably know, the Alpha Centauri system is the closest star system to the Earth (4.3 ish light-years) Alpha Centauri system consists of two sun-like stars and a distant red dwarf star The planet orbits one of the sun-like stars (Alpha Centauri B) Planet characteristics: ~ 1.1 earth masses, which is, AFAIK, the smallest planet ever found using radial velocity method (where they measure the Doppler shifts of the host star's light as the planet's gravity tugs on the star) The "bad" news: Orbital period: 3.2 days Oribtal radius: 6e6 km Expected surface temperature: 1200 degrees C Expected composition: "rocky" ("lava" may be more like it) The "good" news: They say that the habitable zones around Alpha Centauri A & B are stable, and where there's one planet, there are very likely to be more. However, detecting any such planets and determining if they might support life will be highly difficult, at least until some government finally approves funding for a planet-imaging space mission :music_whistling:

No, there is no network code in it- that would require that the clients have Slmod code on their machines too to send that data- and then it wouldn't be Slmod anymore ;). The net commands refer to the "net" Lua environment (namespace). Except for net.send_chat, net.pause, net.resume, net.load_mission, these functions probably send no data over the network at all. Some of the other functions used should send data (such as a_out_text_delay) but the amount of data sent by all these functions should be FAR, FAR less than 128 kbps. And there is certainly no process in Slmod that should be continously sending data over the network. And as you point out, this network traffic you're noticing is incoming, not outgoing. While very unlikely, I suppose it's within the realm of possibility that one of ED's C functions I am using has a bug that is causing the server to request excessive incoming traffic from clients. If you want to establish a causative relation, try uninstalling Slmod, running the server for a while, see if the traffic is gone, then reinstall it, see if the traffic comes back, then uninstall it again, see if it's gone, and reinstall it again and see if it's back. I'd say three times would be enough to warrant an investigation as to what could be going on. I've never seen anything like this, but then again, I've never compared network traffic with and without Slmod because Slmod should only cause a very slight, and intermittent, increase in outgoing traffic (as it sends chat messages/text messages to clients). Edit: I need to ask- why would your switch recognize data being sent from localhost- localhost is the machine itself, right? The computer sending data to itself over one of its own ports, right? Why would your switch/router see that?

Correct. Last I checked, you can make this bug go away by changing line 155 of ./MissionEditor/modules/me_misoptions.lua from Widget.setEnabled(self,b) to this: widget.setEnabled(self,b) Unforunately, I am on a trip right now and do not have access to DCS, so I have no idea if this temporary fix still works.

And cost more money, and not be an improvement in performance.

next_wypnt is just a variable name in the stop condition. I called it "next_wypnt" because it signifies to the ground group that it should move on to the next waypoint. No, the AI of ground groups cannot possibly do switch waypoint. Switch waypoint only exists for aircraft AI, that you can even select it in the ME for a ground group is a bug. Also, you have to assign the action with the Controller.pushTask function.

You might be trying to bite off more than you can chew at first. It might be easier to make something smaller first, to learn the ropes and give the members of your team experience and confidence- for example, a UAV. You could just do some kind of generic UAV interface, sort of a FC fidelity predator. You could even potentially work to integrate it with Combined Arms- the ground commander could get live video from the Predator, for example. Once everyone understands how the modding works by having a simple project under their belt, then they move on to something more complex. A full AH-1 or F-100 sim is ridiculously complex, and I think your chance of success, if that is your VERY FIRST project, isn't very good.

Yup. I guess the point is, it could be said that another ED project is that they are continually trying to make it easier for 3rd party devs to incorporate their work. They are working on making the game more modular.

with the correct triggers ofcrouse and with no Switch WP obviously. :huh: What? What's this "WP 1-1", "WP 2-1", "is user (1), 2" (bolded parts I don't understand). So if you want a ground group to hold at a waypoint, then move to the next on a trigger, you use Hold action on waypoint 1, stop condition: IS USER (1) Hold action on waypoint 2, stop condition: IS USER (2) Hold action on waypoint 3, stop condition: IS USER (3) You CAN reuse the same flag for these stop conditions, but only if you reset the flag to false before the ground group reaches the next waypoint- otherwise, they'll just sail right on through the waypoint without stopping because the stop condition is true. That is easy to do, for example, if you flag you are using to end the hold is flag 1, then SWITCHED -> TIME SINCE FLAG (1, 10) -> FLAG OFF (1) However, the problem is, in most situations, it will be possible for this flag to become true before the ground group reaches the waypoint, and that will probably not be what you desire. You can best handle this situation with a LUA CONDITION stop condition on your hold condition instead of a IS USER stop condition: if next_wypnt then next_wypnt = false return true end Now, instead of a FLAG ON (X) trigger action to stop your hold, you use a DO SCRIPT: DO SCRIPT ( next_wypnt = true )

You forgot EDGE/Nevada. Also, CA has yet to be officially released. Oh and, of course, continued support for Ka-50 and A-10C. The project doesn't end after it's released :) UH-1, while it's not an ED project, they still have to interact with Belsimtek at some level.

No, that's faulty logic. What you have is: IF (previous evaluation of trigger conditions was false) AND (condtion1 OR condition2 OR condition3 OR condition4) THEN (Do trigger actions) The problem is, your condition1, group alive less than 95%, once it becomes true it will always be true. So your trigger will only execute once, ever, because of the switched condition requirement. Logically, a switched condition adds the bolded part below to your trigger: IF (previous evaluation of trigger conditions was false) AND (trigger conditions) THEN (trigger actions) So basically, what you need to do to make that logic work the way you want it to work is to split it up into four separate triggers: Switched->Group Alive Less than 95% -> (actions) Switched->Group Alive Less than 65% -> (actions) Switched->Group Alive Less than 45% -> (actions) Switched->Group Alive Less than 25% -> (actions)

Yea, definitely a bug- switch waypoint is not supposed to be available to ground units. They cannot do it.

Well, keep in mind, I don't have access to the actual game right now, but I'm a little confused here- how do you have both hold and switch waypoint actions on the same group?! Last I checked, switch waypoint is only available to air groups, and hold position is only available to ground groups. So are you using a airplane, helo, ship, or ground group? Makes a big difference, and you don't mention. I had thought you were using an plane or helicopter group until you mentioned the hold position task. The rough equivalent of the hold position task for air groups is orbit. Anyway, still need more info, but based off your description for your first part of the question, it seems like you might not understand that triggered actions are triggered actions- the only way a triggered action ever runs is by telling it to run with the AI TASK trigger action. The conditions part of a triggered action specifies any additional conditions you place on the triggered action- so basically, when the AI TASK trigger action is called on the triggered action, these additional extra conditions must be true for the triggered action to run. So the condition on triggered actions is only rarely useful. However the stop conditions for triggered actions/waypoint actions are frequently useful. They work just like you think they should- when the triggered action begins running, then the stop conditions are continuously evaluated, and, if they become true, the triggered action ends immediately.

1- Use a "switch waypoint" waypoint action on the last waypoint in the loop to make them go back to the first waypoint in the loop. Alternatively, use the "Switch Waypoint" triggered action. I think it's under Commands-> Switch Waypoint. When you want this action to occur, you run it with the AI TASK trigger action. 2- Tell them to orbit at the waypoint you want them to hold at with a orbit waypoint action. Set a stop condition on the orbit waypoint action of either a flag going true ("IS USER") or a Lua condition (return <lua condition>). Now, when you want them to continue with their waypoints, you just set the flag equal to true or make the Lua condition not nil or false. 3- Start a group unactivated at mission start. When you want them to appear, use the group activate trigger action 4- not possible Please study the GUI manual, it covers all of this and more.

No, not for at least a week. I have created it here on my laptop, but I can't test it because I'm away from my flying machine.

Why didn't you enable multiple choices? Not voting till I get multiple choices :)

I imagine the sling itself isn't hard compared to the effect on the aircraft. Then again... I guess the effect on the aircraft simply comes down to a force applied to one point on the air frame. That force varies according to the weight, motion, and drag of the sling. So maybe the sling is the harder problem.

No, that does nothing, other than spit out a useless message if someone types "/mybad" in chat. It was probably just left in there as example code.