Tom Gore

Additional info that I found when fiddling with this. It seems that if you use the removemagazine(s) command to empty a certain weapon in the tank, you cannot rearm that weapon any more, ever. I hate the fact that we have a slider in the unit properties screen where I can adjust the amount of ammunition on the unit but I cannot do the same with a simple command myUnit setAmmo 0-1 Come on. We have setDammage and setFuel. Why can't we have setAmmo? You clearly have the routine already present (the slider). How about giving us the command to do the same?

There is a problem with rearming tanks. If your tank is out of ammo completely, not even a single round and you come up to a rearm truck the rearm action simply does not appear. This applies both starting with an empty ammo load and shooting off all bullets. However, if you are near an ammo truck and already have the action in your menu, you can shoot all away and then rearm. If you have at least one bullet in any weapon, it works just as it should. This one is present at least in 1.46. Haven't tried in 1.60.

Would it be possible to have extra parameters definable to addAction command? These parameters would then be passed to the action script as per normal scripts. For example I would have myVehicle addAction ["My Action", "myAction.sqs", myFirstParam, mySecondParam] Then myUnit would activate this action and parameters passed to myAction.sqs would be [myVehicle, myUnit, myFirstParam, mySecondParam] The first two seem to be passed as it is and that is good. It just would enable more complex action handling if we could add a few parameters ourselves. Please?

Would it be possible to have extra parameters definable to addAction command? These parameters would then be passed to the action script as per normal scripts. For example I would have myVehicle addAction ["My Action", "myAction.sqs", myFirstParam, mySecondParam] Then myUnit would activate this action and parameters passed to myAction.sqs would be [myVehicle, myUnit, myFirstParam, mySecondParam] The first two seem to be passed as it is and that is good. It just would enable more complex action handling if we could add a few parameters ourselves. Please?

It is pretty hard to avoid friendly fire completetly. However, well organized troops rarely get in positions where they might be mistaken as an enemy. It's all about training and playing as a team. When we play as a squad against mixed enemies, they usually get a lot more friendly kills than we do.

Always remember to check your task manager's task list. Often when you drop off the game you will have a "ghost" OFP process still active, keeping your "ghost" player on the server.

There is a way to disable AI players in the mission files. I've seen it used in some missions. Problem is, I cannot seem to find how it is done. Of course, this won't remove the problem if a player disconnects.

Time of day can be easily adjusted. Just use the skiptime command. Anyway I would be very pleased if any from the BIS could comment on this. I cannot see any real problems in implementing this and it would be very nice for the mission designers. No separate mission files for respawn/no respawn, day/night missions etc. etc. The mission parameters are very powerful when used right. Unfortunately for players with dedicated servers they are now useless.

This is a request to the developers: At its current state, only the server can adjust mission parameters on mission startup. No one else can even see them. Could it be changed so (at least as a server option) that the server admin could change the parameters and other could see them. I would love to put a few options in my missions (daytime, respawn, etc.) but as we play on a dedicated server, nobody could adjust them. I can't see this being too hard to code in. Pretty please?

In OFP you do exactly as your group leader tells you to do. If you don't want to follow orders, don't play OFP on public servers. On the other hand, if the group leaders orders constantly get the team killed, you might want to express that perhaps someone else should lead. Or change servers. Soloing players playing "by their own tactics" should stick to single player or go play Quake.

Would it be too hard to add a new scripting command - "synchronize". This command would force all clients and the server running the script pause and wait until all clients and the server would have processed the script to this point. Then all computers would continue executing the script simultaneously. This would be especially helpful when making multiplayer cutscenes and/or randomized functions.

That's what I would suppose aswell. It would be a standard random function then but as we have all noticed a few times, OFP scripting language isn't always that standard

Here's a very simple, but important question: Does the possible range of random X include X or not? For example, can I get 10 from random 10 or is the largest possible returned value 9.999... ? Could be researched by #loop _x = random 1 ? _x != 1 : goto "loop" hint "Found 1!" exit and letting it run for a while but it might take a lot of time to be sure (unless 1 was found, of course). Suma? Anyone?

Here's a very simple, but important question: Does the possible range of random X include X or not? For example can I get 10 from random 10 or is the largest possible returned value 9.999... ? Could be researched by #loop _x = random 1 ? _x != 1 : goto "loop" hint "Found 1!" exit And letting it run for a while but it might take a lot of time to be sure (unless 1 was found, of course). Suma? Anyone?

Umm... what do you mean? You have an end trigger and what... it ends the mission for all players or only the player that triggers it? End triggers are supposed to end the mission for all players.