strango

Inside SightAdjustmentOnKeyDown.sqf Here's an example as to how to limit the max up: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> case 200: { if (SightAdjustmentElevation < MaxElevation) then { SightAdjustmentElevation = SightAdjustmentElevation + _adj; }; _handled = true; }; You would need to set the value of MaxElevation inside SightAdjustmentInit.sqf You can do the same for Min Elevation, Max Windage and Min Windage.

You should try 158.18 or 158.22 (released on May 2nd) depending on which O/S you running. I'm running XP (158.22 drivers) and saw an improvement.

First grab the ArmA Demo and give it a whirl. You'll see that it's a huge improvement over v1.05. Once we finially get 1.07 you'll be able to see this level of performance in the full game. Next grab the latest nVidia driver. They actually just released another one yesterday. That one and the one before it was a pretty decent increase in performance for the 8800 cards. Now all that said, it's still not perfect and I'd expect more from our setups, but you'll at least be getting high FPS with "High and Very High" settings in the game (based on my machines performance which is a quad-core and SLI 8800s running the ArmA Demo).

How about executing a script when someone gets in the pilot seat and exiting when they get out. The condition checks would be the crew count of the helicopter being greater than 1 (meaning more than just the pilot) and the speed of the helicopter being above speed 20 (or some other number). While these conditions are met you can have a temp number increment at some set rate. The rate will be based on how high the crew count is. When the temp number reaches certain thresholds award the pilot points to his overall score. EDIT: I can see where this can be abused with people just flying around and not landing. Perhaps only award the points when the crew count goes back to a lower number.

Beware of people dying at the same time (i.e. from the same hand grenade). They will both run the script at the same time on their local PCs and perform the same calculation and publicvariable. What you end up with is only 1 death showing up.

Based on the change log the grass is tied to Terrain Grid, so it will be the missions that force if grass is used and not the server. Use the setTerrainGrid command in the mission to set the level. Here is the wiki link: SetTerrainGrid

Documents and Settings\User Name\Local Settings\Application Data\ArmA\MPMissionsCache

ArmA Comref

After reading the announcement I'm curious if the 505 release will even have the next patch. 1.05 might be for everyone to run. If the 505 release is gold then the patch would have to already be ready for them. It's unclear if it is or not. I suspect they may ship with something like 1.03 or 1.04 that is an internal release and 1.05 will come up to get everyone in sync.

I'm having a similar issue using the fire command to get AI to throw a smoke shell. I'm guessing the fire command still needs some tweaks.

I've been trying to work around this. The best I've come up with so far is to have a script run at the start for a player and check the status of the time variable. If it's say greater than 60 then you know it's more than a minute into the game and you should do a setpos on the player to some specific area that works for that mission. If it's less than 60 then they either weren't JIP or just barely missed the start and can still be put in their intended position.

If you're wanting to run the script for the new unit I would do: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">[_name_B] exec "Do_Move_B.sqs"; Using it's specific name to run the script will be more reliable than this. I'm not totally certain what Do_Move_B.sqs looks like, so I can't be certain which data you're passing as a parameter.

Because you're doing everything with triggers and not limiting their execution to just the server, you don't need to perform publicvariables. It's possible for the clients to get out of time sync a bit and they will run the triggers at slightly different times from each other. When you do a publicvariable you're having everyone update to the new variable value. Since your triggers are setup to check the variable that means the clients who execute last won't actually run your trigger command that has the marker movement. Try removing the publicvariables and try again on a dedicated server.

I can confirm that a dedicated OFP server would allow missions to be deleted as long as it was not the currently loaded mission.

The only reason I suggested an integer was so you only had one status variable to maintain instead of one for each objective. The boolean way still works and if you've got it working then you should be all set.

Change from your system of several boolean variables to a single integer variable and have the variable hold the value of the current stage being fought over. Use the value of this variable to set the respawn points. This way you can move back and forth with ease.

You might want to add some delays in there because that's going to be constantly cycling. However a better way to re-do it is to have the place where you set the: stageone, stagetwo, stagethree variables also move the markers for you when those variables are updated. That way it's just a one time deal and no need for looping. Be sure it's in an area run by all clients though because markers are one of those things that are client side.

Did you test this on a dedicated server? I was under the impression that skiptime is a command that has to be run locally on clients. This script appears to just run the commands on the server and not on the clients. For JIP I would guess a 1-time skip would need to be performed to catch up with the server and other clients and then get in sync with everyone else.

I glanced at the script it isn't MP compatiable. The weather will be inconsistent between clients and the time accel will eventually get out of sync between clients. In the weather you need to setup a section for the server to run the random numbers and publicvariable the results to the clients. For the time accel you need to have the server broadcast when the time skips are performed so all the clients do it at the same time. Due to network lag you would need to keep the updates further apart as well.

Put something like this in init.sqs Do NOT do a publicvariable as you want the clients to maintain the values they get for a result. <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> ?(side Player == West): MySide = 1 ?(side Player == East): MySide = 2 Then change the array set to: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> DeathCamArray=[] ?(MySide==1): DeathCamArray=[W1,W2,W3,W4] ?(MySide==2): DeathCamArray=[E1,E2,E3,E4]

When I use the spectator script I have been modifying it to run from an action instead of seagull mode. When I run it from an action those commands work. Perhaps when in seagull mode it strips you of your side. If this is the case you may want to set an integer variable at the start of the mission based on the side of that client and then use that variable to determine which array to use.

it's a simple modification of this script: Remove the current line that sets the DeathCamArray and replace it with these two lines (assuming you have East Vs West). Fill out each of the arrays with players you want that side to spectate. <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> ?(Side Player == West): DeathCamArray=[W1,W2,W3,W4] ?(Side PLayer == East): DeathCamArray=[E1,E2,E3,E4]

First place two Gamelogics. One named NWL in the NW corner of the AO. The other named SEL in the SE corner of the AO. This code will come up with random coordinates inside the AO. <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">_HorizontalMin = getpos NWL select 0 _HorizontalMax = getpos SEL select 0 _HorizontalRange = _HorizontalMax - _HorizontalMin _VerticalMin = getpos SEL select 1 _VerticalMax = getpos NWL select 1 _VerticalRange = _VerticalMax - _VerticalMin _Hori = (random _HorizontalRange) + _HorizontalMin _Vert = (random _VerticalRange) + _VerticalMin _Location = [_Hori,_Vert,0] Use the _Location array to place any object you like.

Well if it was in DF2 then it must be real.

Most ACOG scopes don't have external elevation adjustments, you have to special order it. Since the ACOG has built in hold over points for elevations I'm not sure why you would want it anyway. If you're shooting at something beyond the hold over points then you might as well be using another rifle anyway because your stretching the limits of the rifle at that point. Let's also not forget that we're talking about a 3.5x or 4x scope and if you're making 500+meter shots and looking for percision you should be using another scope as well.