fasad

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!