mr.peanut

Question for Silola: in DAC_Waiting_for_End.sqs<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">if(((_rCamp select _rdmcamp) select 5) == 0) then {_temparray1 = _temparray1 - [_rdmcamp];goto {checkid}} Why is it not:<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">if(((_rCamp select _rdmcamp) select 5) == 0) then {_temparray1 = _temparray1 - [_rdmcamp];_temparray2 = _temparray2 - [_rdmcamp];goto {checkid}} Also, if no camps have any respawns left will the script get hung in a loop around #checkid?

When it is time for a group to respawn, a check should be made for the distance between the spawn point(WP or camp) and all player units. If the distance is too small, then try the next spawn point in the pool. Only two options required, one for the minimum spawn distance, and a switch that determines whether to force a respawn at the furthest possible spawn point if all possible points are too close to the players. These two variables should be appended to the DAC_KI_Spawn array in the DAC_Config_Creator. I have enough scripting knowledge to make these changes, however, the DAC code is so compact, with so many variables defined on the fly with call format statements, it is hard to decipher. It is incredible to me what DAC does using the OFP scripting engine, but the code is completely uncommented and undocumented. Edit: Okay, I need one crucial piece of info that I have not been able to glean from the DAC docs. Do global spawns still require spawn camps? Is the global spawn pool a list of all wp + spawncamps?

It does not seem that DAC has any settings to prevent respawning from occurring within view of players (either with global or local respawn). Is this true?

This point has already been debated a million times over. It has been mentioned by many members (myself included) that VME mood’s AI is much more impressive than what we saw in ArmA videos. I am able to run platoon sized engagements with VME CQB soldiers while taking very little hit to the performance on my system, which is just slightly above average by today’s standards. Now don’t get me wrong, VME AI is far from perfect and it is very badly documented (which further limits its utility), yet it is a clear improvement over the core OFP. No one is expecting the ArmA to have human-like AI, but I don’t see why something similar to VME AI can not be implemented at core engine, rather than scripting level. Peace, DreDay VME would be what I meant by what has already been done in the OFP community by scripting to improve AI.

A couple of comments: 1) The AI need not act realistically as much as they need to appear to act realistically. There is a difference. 2) The cost benefit of improving the AI is small. A lot of money and time can be spent researching it without a guarantee of improvement. Graphics tend to impress the plebes more than AI, as long the gameplay is decent. 3) Computationally, the cheapest way to deal with individual AI behaviour is statistically. For example you can calculate every line of sight for a single AI with high precision to see if it spots an enemy (expensive), or you can calculate a probability that an AI will spot an enemy based on various factors such as distance, visibility, terrain, direction AI facing (cheap). For each factor for which you want a single AI to respond, there is a significant increase required in computation. 4) I'm not sure that BIS can improve the ArmedAss AI much beyond what has already been done in the OFP community by scripting, without seriously affecting the minimum system requirements.

EDIT: deleted

I was trying recently to write a simple script to allow players to have a little more control in OPF t10c parachutes, using  addAction.  (Please do not tell me there already exist steerable chute addons, I know this...)  Since a chute is a vehicle, I addActions to the chute after the player is moved into and assigned to the parachute. For some reason the actions do not appear.  It seems you can not add actions to the parachute vehicle. Can someone please confirm this? If it is true I will not waste any more time on it.

It is generally not a good idea to hard code the setTerrainGrid command. Someone with a low end machine might not be able to play your mission. Avoid placing items in buildings that are on slopes?

Chastise you? Never!! If you want a player to have an action while in a vehicle, the addAction is applied to the vehicle. This means, of course, that those outside the vehicle can use the action as well. I know this from adding repair and nitro actions to KLRs. If you want the action to only be available to the driver from inside the vehicle, you use getin getout eventhandlers to add and remove the actions. Use the event handlers in conjunction with the local command e.g.<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> if (local driver _vehicle) then {_vehicle addAction["blah","blah.sqs"]}. For some reason you can not add an action to a parachute... I think. This is what I would like to confirm.

Bee, Another more simple way of doing this. In the on activation for the trigger put: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">{mg1 reveal _x} forEach thisList or: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">{(gunner mg1) reveal _x} forEach thisList Not sure which works better. It should not make a difference. No script required!

I tried adding to the player as well, and it did not work. I think the parachute can not have actions added to it.

Distance to parachute should not matter since the player is in the vehicle.

In my init.sqs I have called a script that randomises a variable on the server and then publicvariables it. The clients wait until they receive the updated variable and then use it to skiptime. What I have noticed, in the transition from debugging locally, to debugging on a dedicated server, is that the script only works if it is removed from the init.sqs and placed in a trigger that fires at game start. Do publicVariables not broadcast properly until the game begins?

CrashDome, By the statement above are you saying to sync time/weather you use the createunit gamelogic trick you posted earlier? Â Is this because you can include it in the init.sqs so it is executed immediately without a slight delay? But what if you are syncing weather many times, hundreds of times? Won't you end up creating hundreds of game logics?

Agreed. PV sucks, especially if you have a lot of clients with laggy connections. ps. thanks for the CoC_NS docs link. I will peruse.

I remember the script was at OFPEC/editors/scripts/air, but do not have it. Surely someone else out there still has a copy?

Yes I know but does it work when said strings (the variable names) are passed to it by forEach and not the script it self? I think that's the problem in the original script. Wouldn't you have to use call and format commands for it to work? Like "call {format ["publicvariable %1",_x]}" foreach ["x1","x2","x3"]; or something like that. Trust me.. it does work. There is nothing wrong with the script itself. As I said, the script works well from a trigger, just not from the init.sqs . Â I have read that by using forEach in this manner all the variables are sent in one packet, which makes it a more efficient use of bandwidth.

Well, call me stupid, but the example provided with CoC_NS is mind-numbing. Although the docs describe in detail the functions, there is no simple example of how to use them. I can see how to broadcast a variable, but can not see how they are received. The docs say the receive function is internal and called by PA/client.sqs, but there are no docs on what the hell this script is.

I wasn't criticizing CoC NS, I just meant I am too lazy too learn to use it for one small problem. Our server has a mission size limit of 800kb and 200kb is a good slice of this. Maybe for my next mission I'll use of it. What is a good example mission that illustrates its uses beyond player to player communication? Is there one on the CoC site?

Very weird. Guess you'll have to break it into two if-then statements instead (edit: or two triggers). Gotta love the kludge...

Thanks everyone for your answers.  They confirm what I suspected.  The comment about the tilda ~ wrt init.sqs is especially interesting. I often call other scripts from the init.sqs to batch initialise units; now I see that these do not actually get executed until the game starts. Furthermore, they prevent the rest of the init.sqs from completing. I can see the advantage of using functions instead as they will have to complete sequentially and will not hang the init (if I understand correctly). As for the CoC Net... For my purposes it is using a sledgehammer to drive a tack. I am making this mission for a server on which the addons are pretty static (LOL server).  A while back I suggested a pbo be made of the CoC Netcode and be made a mandatory addon on the server, but no one listened.  There are a real variety of pings and bandwidths on the server and desync is often an unpleasant reality that creates  unexpected bugs, especially with triggers.

This is exactly my point. If the trigger fires on the server only, you will hear nothing.

This is from memory, so mention if there are errors So even though the logic is created only on the server, the init code is executed on all clients? That is weird. I guess the same approach could be used for sync'ing weather etc. with the advantage that the script need only run on the server. Any suggestions on how to sync a camera?

As I said in my previous post, variables x1,x2,x3 were all defined in my init.sqs. I think this is probably an issue with server lag. If the server lags too much publicVariable commands issued before the game starts are either not properly broadcasted or received. The fact that the exact same code works from a trigger suggests this. My recommendation is not to use the publicVariable command until the mission has started. If you call a script from the init.sqs that uses publicVariable put a @time>0 in it.

Are you certain the trigger is firing on all clients? What is your trigger condition? From your description it sounds like the trigger is only firing on the (dedicated) server.