wamingo

I think you're overcomplicating it. The direct answer: I don't think markers activate triggers. So you'll probably need to determine manually if the position of the marker is inside the zone. If it's a circle then you can do: getMarkerPos "mymarker" distance getpos mytrigger < _trigger_size If it's another shape, then you need more complex math. Search. The proper answer, however, is probably that you don't need to do any of that. If you set a bool for each trigger, and each trigger tests the previous triggers bool, then you can fix the order in which the triggers execute: trigger 1 condition: this acivate: trg1_west = true trigger 2 condition: this && trg1_west activate: trg2_west = true trigger 3 condition: this && trg2_west activate: trg3_west = true etc. If you have opposing sides you could do this: EAST trigger 1... trg1_east = true; trg1_west = false Hope it helps. edit: just know that with several triggers you may have to turn on/off multiple bools. Perhaps keeping a count is an easier system? I guess it depends on what you want.

What you describe as a problem is what TARGET exists for. There's no reason to split up MOVE. MOVE serves a purpose too, perhaps during cinematics, scripted moves or so. But yes, they've clearly been misinterpreted. It's a bit like the GUARD waypoint type. Sounds simple, but actually quite complicated, and has to be used carefully.

carl, "TARGET" == Rotation. I think the problem is they're just easily misunderstood. wiki on disableAI TARGET: "stop the unit to watch the assigned target" Emphasis mine. Assigned targets makes them engage, ie move about. At least that's how I now interpret it.

An issue is that AI stick to formation quite strictly. Team units aren't very independent. Changing this could make AI a lot more interesting, very quickly.

Gnarly_rider there's probably a better script for that sort of thing, maybe Urban Patrol Script (UPSmon) ? My script above uses setPos, which teleports the units into the buildings, which of course might look a bit silly in real time. Basicly it was only made to work at mission startup. However, this code should make them move again, eg in a wp-switch trigger: {_x enableAI "TARGET"} foreach units mygroup; units mygroup commandFollow leader mygroup; I think that should work. Some quick speculation on making it polished: - doMove or commandMove instead of setPos - can't doStop/disableAI units immediately, you'll have to run a loop to check once they've found their positions, individually... maybe when unitReady ? - need an sqf file. assuming the unitReady thing is easy it's probably not that hard, really. But I'm not bothered right now. Good luck. ;)

I know everyone wants a full on simulation thing, but I'm not sure BIS does. So to be realistic I think you'll have to compromise. The lock-tone was a request from the community and I think that, in principle, it was a good step forward to remove the tab-fire problem. Unfortunately the vehicle lock tone is so fast that it almost doesn't matter (the javelin one is quite long by comparison, and with obstacles can be quite hard to use, at times). Increasing it, and perhaps adding in some factors like distance and speed wouldn't hurt - eg flying faster means longer lock time. If that isn't enough however, one could dabble in adding a "semi-mini-game" to complement the lock tone. This could be done in a variety of ways, some more arcady than others. But it could remove the "automaticness" of tab-lock.

It would be preferable to let the server config hold links, of course. The mod list on the mp screen should be more expressive and interactive, I think. Coloring the mods depending on whether you have them and if they're disabled. And click the mod form to get the download links provided by the server. Though, I think the problem might be a little overrated. Perhaps it would be simpler to just have better filters for non-official mods. And get all the filters onto the main mp screen too while we're at it. stuff like that.

Might be I'm just odd but if I had an SSD I'd probably leave my windows Users folder on a regular drive. I don't think the Users folder, documents, game saves and all that, benefit much from ssd, in general. I could be wrong.

And what would you suggest they did?

I don't know how bad it would be performance wise, but the code needed to test every object against especially concave polygons is quite heavy compared to simple rectangles/ellipsis. You can solve your problem with multiple triggers by using shared variables, like a bool, seudo example for every trigger: code && NOT anyZoneOn code; anyZoneOn = true Might have to initialize the bool? can't remember. can't hurt though.

I'd like to see the previous islands/maps be compatible. Chernarus/Takistan etc. It's a bit of a shame to lose the previous environments every time a new full sequel is out. A great benefit of OA being a standalone expansion, was that we didn't lose the content of arma2.

There's clearly a difference between giving people ready tools and requiring people create their own. And wanting to do more in less time does not equate to being lazy. Finally, the editor is an advertised and important feature of arma, so yes, they most certainly do have to.

Big Dawg, Your definition of majority is mad. With all due respect to the creative community, the real majority doesn't pay good money for games that promises only "extensibility". In your own signature you encourage everyone to use the sandbox features of the game, yet you're not willing to lend the very people you speak to, the tools that would allow them to do just that. You simply demand everyone become more advanced users, instead. But you know full well that's a tall order. DMarkwick gets it: That is what people will pay money for. The flattening of the learning curve and reduction of workload.

Nearly a year later, same discussion, same argument. I agree that the Apple syndrome of reducing functionality, for the sake of the masses is bad. But do You write your mission.sqm in notepad, too? No, You do not, because You, like everyone else, appreciates gui, click, select, drag and drop type stuff when it means your workload is reduced. And I think You'll find that many think exactly that, about a lot of what You call "basic stuff".

Today I was looking for a way to make whole groups take positions inside buildings. Searching the forum, everyone suggests using disableAI "MOVE", but that's clearly only good if you want them to face only in one direction. Instead using "TARGET"... eg: {doStop _x; _x disableAI "TARGET"} foreach units group this; With this, it seems Leader won't issue target/engage commands, while units turn/target/shoot freely, but still remain in place - unless you throw a doMove, of course. Here's the whole jazz to move whole groups into buildings that they're placed near, at a random building-position, and not move -- but still target and shoot freely. This code does it for the whole group, so you only need to put it in one unit's init for instance (eg the leader): if (isServer) then { { doStop _x; _pos=0; _house = nearestBuilding _x; while { format ["%1", _house buildingPos _pos] != "[0,0,0]" } do {_pos = _pos + 1}; _pos=_pos-1; _x setPos (_house buildingPos (random _pos)) } foreach units group this }; {_x disableAI "TARGET"} foreach units group this; If you set units not-in-formation then you can scatter them across any number of buildings, while remaining grouped. Seems to work pretty good?

I'd recommend not posting tonnes of stuff that isn't essential to the question. No one has any clue what you do with all those variable outside the scripts, and most won't care to read it. I don't know if the script runs another loop before the end with some null objects or something... That might've subtracted 500 points. You can exit the script before the ending screen in a number of ways though. For instance: while { ! theend } do ... Also I'd suggest not broadcasting stuff too often. Especially a meager pointscore. And finally, endMission is not broadcast I think.

B00tsy, read about the waypoints here: biki waypoints Guard can be switched out of, but doesn't time out automatically.

I don't think the 2d editor is being replaced. As fancy as a 3d version sounds, they're typically very inefficient without some orthographic companions. You spend 100x as long controlling the camera, alone. We'll just get a button to switch to/from 3d I'm sure.

What do you propose? MP is a completely different ballgame to SP. It's like parallel programming vs sequential. It isn't simple and probably never will be. Indirect solutions may help a fair bit (eg templates/examples), but in the end locality is probably here to stay.

<br> is just linefeed. You can probably add/remove them as you want, though it seems pointless to me to add them after a </p> or before <hr> - as you have.

you have two End2's

Among many other things, I for one am greatly impressed by how good the water looks in the e3 video. Arma3 screenshots will be used for travel ads, me thinks.

not already possible? create an empty vehicle and use _man moveInDriver _car etc

I'd like to see modules be 1. consolidated so they are more powerful but fewer, and 2. given appropriate UI's in the editor so that you don't need to use the init lines as much. More buttons, sliders and number boxes -- less code writing.

I have only guesses left because your briefing.html + the tags I mentioned works for me in a clean mission. - you added my tags in the wrong place (should be after ...</title> - bug in mission (start from clean) - Addons (remove them) - using an html editor that adds/removes tags (use notepad or notepad++) - wrong folders or file name/extensions if all fails, post mission