Case

Okay. It also seems it might be too close and would have burnthrough already. One thing that strikes me is that the second R-27R does not appear to track the second F-16A. Regardless, this looks very odd. Can you share this tacview? Also, can you reproduce these events?

Did you check if it may have been a HOJ shot?

On Monday April 19th Space Shuttle Discovery will return to Florida. The reentry path will cross many states over the continental US, and many readers here may be able to see the reentry. More information can be found here: http://www.nasa.gov/mission_pages/shuttle/shuttlemissions/sts131/news/landing.html

Any of the developers know more about this?

Essentially it is the same as if you were making a single player (SP) mission. The only difference is that the planes you want players to fly should be set to 'client'.

What questions would you like to see answered?

Perhaps make a trigger to deactivate them when they have landed.

On a related note, could you perhaps look into reorganizing the logs? They seem to be contain duplicate information or useless information. I am playing with the ServMan code myself but having more trouble with the language itself instead of the code.

So is client.lua called when a player joins a server as a client, and server.lua is called when the player hosts a mission? As for displaying messages to a single coalition only, the net.send_chat(string message, bool all) apparently only has the option of sending the message to all or to the server coalition. Since the server usually is a spectator it won't do much good, unless I am mistaken here and it can be used to send it to either or both coalitions. If I'm not mistaken then perhaps net.set_unit(int id, string unit) could be used to switch the coalition of the server between messages.

Why waste your time policing this when it can be automated? Some clever placement and usage of trigger zones and triggers and any pilot taking off in the wrong direction or from the taxiway will get to see a nice message saying he broke server rules and 5 seconds later the trigger explodes his aircraft. Then he can restart his engines and either follow server rules, or go through the whole exercise again.

Expect to see a bit of that in our missions on the 51st servers.

Ooh, that is a very clever one! I had tried to get random starts myself, but this is a much better solution! :thumbup:

Well, here's a few specific examples. Say you have enemy units guarding a bridge where you want your friendly units to cross. You can make triggers to activate your friendly units to move towards the bridge once strikers have taken out all or part of the enemy units. On a bigger scale, you can make a mission where one side is tasked with taking over an airbase. Should they succeed, you can use a trigger to load the new mission where that airbase is actually owned by the coalition that took it. Finally, you could make something as complex as Grimes did for the 3Sqn server: http://forums.eagle.ru/showpost.php?p=877003&postcount=2 Here a coalition must first have air superiority over a given area for ground units to start their advance, and they must then keep it to protect their units.

Views are working fine now. Thanks for fixing this Crunch!

Just flew a bit in the "Capture Maykop" mission, and it was great! It was incredibly hard to 'capture' the base, as enemies pushed us out of the zone, and in the end we weren't able to hold it for long enough. The amount of triggers in the mission is just insane. Well done Grimes.

From the multiplayer.bat file it appears the FC2 executable simulator.exe can be called with command line arguments for multiplayer. Are there more command line arguments available, say for example to automatically replay a track?

I second this. (Or is it third?) I am not using the TIR zoom but use a button on the joystick to zoom in and out. Hence zooming out at loading in is hardly a nuisance, but having to zoom out each time I reset the zoom is. Furthermore, the snapviews are also overwritten, and I use a few very regularly, so that adds even more. Finally, I dislike the default green HUD and use a yellow one instead which for me personally has better visibility against clouds.

I understand your point, and it is a fair one.

I disagree with this statement. From experience I find that this is not as bad as you describe it to be. One of our squad members routinely has a ping over 300ms due to his and our servers location, but we never encountered the problems you describe. Though I agree your point of making missions 'enjoyable to pilots in other continents', to my knowledge no server has sofar imposed a limit of 300ms pings on their clients, so you should have no problems to fly on the 3Sqn and 104th servers. If you still feel your ping is too high there, I suggest to try other servers. The 4c and 51st servers are located in Europe and online most of the time, as probably are several others that I don't know offhand.

Great, the more the merrier. Also check out the server briefings if the server hosts a dedicated Teamspeak or Ventrilo server for communicating with other pilots on the server.

I see no problem hosting other peoples missions in a closed server or in SP. It is a great way to see how other people make their missions and get familiar with them. However, hosting them in a public server is questionable, as Grimes and others already explained. Many of the server admins use their missions to attract players. Just a side note, is the 300ms ping you describe really such a problem? In FC1.12 300ms pings were perfectly acceptable, and in FC2.0 I have not yet seen any effects of lag due to such pings.

Cannot wait to fly there and try out your missions Grimes! Excellent work!

Basically a flag is used to describe the outcome of a test. A flag can be either true or false. Say you want to use a trigger to see if a unit passed through a trigger zone. You can easily define a trigger like this: ONCE(Unit inside zone) // UNIT INSIDE ZONE(Unit, Trigger zone) // MESSAGE(Unit is inside trigger zone,10) However, as soon as the unit exits the zone, the condition is no longer true. What you can do is use an action to set a flag, like this: ONCE(Unit inside zone) // UNIT INSIDE ZONE(Unit, Trigger zone) // SET FLAG(1) This will set flag 1 to true as soon as the unit enters the zone, and it will remain true for the remainder of the mission or if you reset the flag through some other trigger. Now you can use other triggers to check if the unit passed through the zone: CONTINUOUS ACTION(Unit passed through zone) // FLAG IS TRUE(1) // MESSAGE(Unit passed through the zone,10) CONTINUOUS ACTION(Unit passed through zone) // FLAG IS FALSE(1) // MESSAGE(Unit nas not passed through the zone,10)

Fantastic!

Good stuff Grimes! This will be a post I'll come back to often.