fasad

G'day, I've got some time on my hands now, and am trying to work on some V3 scripts, but can't find any language reference documents. Does anyone know of any such document or can BI please release something? As far as I can see it is not the same as the O2 language or ArmA scripts, since the example scripts use unfamiliar commands such as getObjectsWithTemplate, getLandHeight, etc. The Visitor 3 Manual states :

I think a great addition to the engine would be the addition of infrared (thermal) vision. Active(?) IR (using a IR floodlight as seen on many old tanks) could be easily simulated by creating an alternate light "world" for IR lights. Switching to IR vision would result in the game world illuminated by IR lightsources. In rendering the normal visual spectrum these light sources would do nothing. Modern passive IR might be accomplished using a new "heatmap" texture that is only visible when in IR mode. Tanks and aircraft have had this technology for decades.

So this list is for a program other than Visitor?

I'm reasonably sure ArmA can display the stars for any location on earth, it just depends on the island/terrain in use. Sahrani is in the northern hemisphere. I assume the stars are displayed correctly for that location, because it looks unfamiliar to me as a southerner. OT: In the southern hemisphere, south can be found using the southern cross and the pointers. South is the point on the horizon directly below the intersection of two lines: - one through the top and bottom points of the cross - the other is the perpendicular bisector of a line between the two pointers. It probably sounds a lot harder than it is, especially in real life because they are some of the brightest and most recognizable stars in the sky. Google is your friend

If your AI get too far away (i think it was ~800m), they become genuinely lost and will stop moving towards your position, even if told to return to formation. In this case, select the lost units (using the function keys), then tell them to move to a nearby point (click mouse cursor on the ground). When they get back within a couple of hundred metres, tell them to return to formation and they will be able to find their way back. If they don't move towards you, they are probably stuck on/in something or can't find a path.

if what I had put in the wiki was correct, AI will automatically turn on/off lights depending on daylight (if allowed by current behaviour mode). I'll do a quick test... edit : still holds true

ArmA uses a grid to define the surface type, where all terrain types (no matter if it is grass/rock/dirt/mud) within one grid square use a single surface config (ambient and walking sounds, terrain roughness, dust, etc). If I remember correctly, it uses is first surface type defined within the config? I don't know how this surface type grid is related to the satmask and heightmap grids. Here is a thread containing some info about the surface grid.

Try running a couple of RAM/CPU stability testing programs, such as MemTest86+ and Orthos. If either of these fail, the problem is either CPU, motherboard or RAM. It is possible for your motherboard to apply incorrect voltages and timings if left on automatic.

Try the enableAttack command. I have not tested it, but I suspect it disables the "engage this, engage that" group behaviour.

... Sorry, I don't have time to follow the entire thread, but it is relatively simple to create a grid in a photoshop type program of your choice. However, it is not a single grid, but two grids offset by the segment overlap. The grid lines should be part of the graphics program, therefore they have no thickness (they lie between pixels). When considering how many terrain types you have in a single segment, use the outermost of the two grid lines around that segment. Example: Sahrani Lite (south Sahrani). Each segment (piece of the satellite mask) is 256 pixels, and each overlaps each of it's neighbours by 16 pixels. That means you will need to create one grid of 256x256, then another offset by 16 pixels in both x and y dimensions. Unfortunately I never found out what happens at the edge of the satellite mask, nor do I know where the origin of the grids should be. A bit of experimenting in V3 would answer these questions (import a simple sat mask, then look at the segment paa's that ArmA creates to figure out where the overlaps lay). I would expect that one of the tutorials for V3 that has been written would cover this.

Try: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> Â myLocation = createLocation ["NameVillage", getPos player, 100, 100]; Â myLocation setText "Without defining this text, the location will not be visible on the map."; etc. All the location commands should be grouped in the location command group. AFAIK you can't without creating a custom config (addon). I am not familiar with any script command that can create a new class definition or overwrite an existing class. I would assume the default ones are read only anyway (and they are also used to display the locations defined in the current terrain's class). However, Kronzky changed my text in the wiki from "...[location type class properties] cannot be changed using script commands" to "...[location type class properties] can be changed using script commands"

Dren, that is what it does. You execute some script code somewhere within a mission, and you have a new location (including text on the in game map). From memory, unfortunately you cannot manipulate the default locations that are defined within Sahrani's config file.

I had the same issue a couple of weeks ago. You can still MP test on one PC, you just need to add another line to your server config. Solved: MP testing on a single computer in 1.14 (OFPEC.com)

there is something wrong with your script, unrelated to the useWeapon line, maybe ?_Shots >= 3:exit this script works as expected for me in a test mission : <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">unit2 switchmove "ActsPpneMstpSnonWnonDnon_AmovPercMstpSnonWnonDnon_Injured3"; unit1 playmove "ActsPercMstpSnonWrflDnon_ArrestingSoldier"; sleep 5; unit2 switchmove "AdthPsitMstpSlowWrflDnon"; gameLogic action ["useWeapon", unit1, unit1,12]; sleep 0.2; gameLogic action ["useWeapon", unit1, unit1,12]; sleep 0.2; gameLogic action ["useWeapon", unit1, unit1,12];

They are stored in the main stringtable (csv format, open it with any text editor) \operationFlashpoint\bin\stringTable.csv

use countEnemy to see if a unit considers other units to be enemy. If you want to test it during the mission to establish if the sides are enemy to each other, you could create a unit from each side on a small remote island somewhere, then check if they consider each other to be enemy (this way there is no chance of the test returning incorrect results due to team killing)

There is no set date!

A seized by Blufor detected by Opfor trigger does not imply the trigger must be empty of opfor in order to activate. Opfor only need to think that within the trigger area, Blufor forces (they know about) are superior to their own. I do not know the exact method ArmA uses to equate the capability of various units/vehicles, nor what exact balance of power is required by each of the timers. However, I do know aircraft are highly visible and considered quite powerful. Â I think the easiest way to ensure that aircraft don't trip the seized by counter would be to ensure the aircraft doesn't stay within the trigger. Make the trigger small and keep the aircraft moving. If the aircraft is landing, make it land outside the trigger area. Â Otherwise maybe using something like the following in the condition : <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">this and (("air" countType thislist) < 1) although that won't stop an aircraft starting the domination, and won't while an aircraft remains in the trigger. Another method would to use two triggers. The first would activate when blufor "land" units are present, while the seized by trigger would require that trigger to activate... Also note the timers are in seconds. That is not correct for triggers. A trigger countdown timer works in the manner you describe, but a trigger timeout timer does require the condition to be true for the entire time period in order to activate. However, last time I checked waypoint timeout timers do act like trigger countdown timers.

Thanks for the info Master85, I've updated the BI wiki description and added some notes. This command seems only to be of use on AI led groups. The AI leader assigns his group to vehicles (which gives values to assignedVehicle & assignedVehicleRole).

I've been testing use of this command without seeing any apparent effects. The above description by Skaven certainly doesn't work in 1.14. Does anybody got any idea what this command actually does?

Hmm, it's looking quite promising

the wilbur homepage has a tutorial on creating eroded terrain - Fun with Wilbur Volume 1 (using fill basins and incise flow to make eroded terrain)

I get the same, for both empty vehicles and those occupied by enemy.

AFAIK, hyper transport is AMD's memory controller (on the CPU). You may want to do some general RAM + system stability testing, especially if you are overclocking.

When I was working on the mission editor wiki article, I seem to remember finding that ~500m was the min proximity for AI in aircraft to complete a move to waypoint. Assuming the proximity check is done in 3d, and the waypoint is on the z=0 plane or at ground level, it could it be that the vehicle isn't getting close enough to the waypoint to ever satisfy the condition of arriving at it? I'll do a quick test... edit: nope, wp proximity is in 2d. AI in cobra at 800m seems to get scared of heights and just flys around in circles.