Vigil Vindex

I am trying to make a trigger that will only activate if the player has the trigger within their view distance. I think the condition code should simply be: player distance _trigger_variable < viewDistance However this doesn't seem to be working, maybe I am missing some parentheses, does anyone have any advice or experience using this as a condition. I am also aware that this condition will not work on dedicated servers as the "player" is local to the machine the code is executed on, and I am assuming triggers are local too, so that will be an issue, but it should work for local hosting and single player.

All I feel we have the right to expect from BIS with A3 is that it at least meets or exceeds the previous games. I am sure they will make the right decisions to prioritise what is critical for releasing A3. Plenty of time for extra shiny DLC after release.

I tried downloading, but it forces you to register first.

I thought it might be something to do with the new beta codes thing that has popped up in Steam.

My own take on it is that the AI in the engine is out of control. I have been learning to code missions, and my experience is that when you start to use any meaningful number of AI the whole thing just grinds to a halt, where the AI seems to act "dumb" and the game seems to slow while also using less resources. There are all sorts of voodoo you can do to try and use as little AI as possible so you can fake having large numbers of AI over a large area of the map, but it's still a hack and the problem still exists, and adds more complexity to the mission code and design. I fear for when Altis arrives, as it is a much larger map and will require more AI to fill it and make it a believable place to play in. The performance problems with the AI have discouraged me from working as much as I would like to with Arma 3. It just feels like it isn't going to get fixed any time soon. Documentation on how the threading and processes of the game engine and AI is non-existent and I suspect even the devs have trouble navigating how it all fits together. The fact we don't have devs openly discussing the architecture of the process and thread handling for the AI tells a lot. The long and short of my post is, I think the gpu/cpu utilization problem are linked to the AI, as when no AI are present the game is smooth and uses resources fine. I would love to read Dwarden's (or any other dev, preferably the original author) technical and complete description of the code for the AI and how it all fits together within the games other processes.

I think a good step would be for some documentation to be provided by BIS to give some insight into how the AI is actually handled, in terms of architecture, code execution, and code function. Anything really to give a better picture of what is going on and what can be improved, and what should not be changed. I also think, regardless of what BIS is able to do (or not) on its own with the AI, it should be openly documented so the community and editors/moders can improve and contribute to the development of the AI in general. Something like this was a good start but was never finished - http://community.bistudio.com/wiki/Arma_2:_Operation_Arrowhead:_AI_FSM

Where is the documentation on the wiki for this sort of stuff? Stuff mentioned in threads are not easy to find on the forums, they need to be displayed up front so they are accessible to server admins. I also don't understand where the "hole" is that hackers get in to execute their code. Where exactly does the client get allowed to execute their code. Is there some sort of developer console that clients can use to execute code? I come from a web development background and I find it hard to grasp an architecture where there is a server and client, and the server has no say in what the client can or can't do. Seems like there is no scope restriction for clients. I mean the game has two bits of data, the data files that have signatures and are checked, and the mission file. If those two are secure, how is it possible for a hacker to come in and execute arbitrary code on the server? The client must have some way that allows them to execute their own code outwith the code in the mission or data file.

It's annoying but quick and easy? TextView2 does not seem to have the options you would expect when saving as an image, such as compression settings, and I couldn't get it to load up a jpg and save as paa. Without being able to easily access paa files in common image viewers I can understand why some people would prefer jpg. If you have an example of a quick and easy way to work with paa files please share them.

Would it be possible to try and bring the file sizes down for the image files? They seem pretty big.

I've been getting this too. Got it in both a3 and a2oa today.

Is there anything specific that can be done to try and prevent hacking? Anything at all in the server config that is best setup? Are there any mission side scripts that can be used to mitigate any of the possible hacks?

Will there be classnames for the ship wrecks under the water? I can't seem to see any mention of those.

I've not been able to get this to work for me. I'm not sure if it's because I am spawning AI during the mission, but even when I die the ticker doesn't fire. Since the script doesn't use the "ALL" settings anymore, is there any other change that might be needed to ensure this works? Also I noticed you have removed the weapons and distance parts, are you going to add those or are they removed because there is a problem?

For handing over AI to UPSMON making it a task could work too, for example: case "UPSMON": {[(leader _grp),_tsk1,"nowait","noslow","delete:",60,"spawned"] execVM "scripts\upsmon.sqf";};

I am thinking along the lines of, what is the best place to calculate physics? If it is the case that physics is best simulated performance-wise on the GPU then why not use it there. I am thinking in terms of how not to duplicate effort, I don't see the difference in how physics should be applied to anything, be it a bullet hitting a player, or a vehicle hitting a building, or something exploding and moving debris in its area of effect.

What about ballistics? Physics is a major part of any simulation. Physics pervades everything. PS. Please don't take my post as some demand that it must be done in Arma. Or that it is the only way to implement something. I am just talking about general principles and possibilities.

I didn't say you must use the GPU for everything, obviously you would only want to use the GPU wherever the use case benefits from it. My main point is about the ability to use that option. I think it is a fair guess that VBS engine was not designed with these sort of options in mind. Physics for example, I bet there is code in VBS that simulates physics on the CPU. But now we have options like PhysX, that offload that work to the GPU. I guess that significant modification has been done to VBS to allow for the use of PhysX. But if you had designed the engine with these options in mind you wouldn't have to modify it to use it, and you would probably not have put the effort into writing your own physics on the CPU thus allowing you to focus on other problems. As for the wikipedia article, reading through it leads to another article that specifically talks about the benefits that have been discovered from GPU development and that are now being put to traditional CPU programming tasks. It's still a new field and being actively researched. This is the cutting edge in computer programming. Here is the wikipedia article for general purpose computing on graphics processing units: http://en.wikipedia.org/wiki/Graphics_processing_unit ---------- Post added at 21:44 ---------- Previous post was at 21:39 ---------- You never throw away knowledge. Even with iteration, each new attempt is a fresh start, and an opportunity to both improve on the previous attempt, and to achieve new things. Basically, starting from from scratch, is still just an iteration of what you have learned from previous attempts. I bet if you asked the actual team that wrote VBS to sit down, look at what they have learned, and asked them how they would do it from scratch, it would resemble pretty much what they have already done, but with less of the bits that don't work, and more options to replace the bits that don't work. You never really re-invent the wheel, you just make it a tiny bit better for your specific need.

Apologies, but I did read what you wrote, a few times. And I didn't accuse you of not knowing what you are talking about. I do have a background in programming, so I have some understanding of how to achieve things in terms of software design. My argument is simple, you can write something that mainly uses the CPU, and uses the GPU for some simple graphics specific stuff. Or you can write something that mainly uses the cpu, but uses the gpu for more than just graphics, specifically, any code that is better executed there. It is the principal of being able to do what you want and not limiting your options. If your argument is about the fact that the gpu and cpu are separate and having to "sync" them renders all benefits pointless then I think that is more a problem of how you are implementing their use. Also my facts, are from wikipedia, not my ass: 1 - Arma engine was out before x64 was in household pc. References: http://en.wikipedia.org/wiki/Real_Virtuality_(game_engine) http://en.wikipedia.org/wiki/64-bit_computing 2 - GPU is more powerful that CPU References: http://en.wikipedia.org/wiki/Graphics_processing_unit

I think the discussion for wanting better cpu/gpu/x64 support is more about the architecture of the engine. There is no denying the fact the engine was designed at a time when x64 and powerful GPU's didnt exist. We want something that is designed at the top level to be aware of (and use) all that is available. This is not the case just now. People seem to focus on talking down the benefits of x64 and GPU's rather than accepting that these are the improvements that have been made in computing since the engine was created. There is no argument against supporting better technologies. x64 is better than x86, fact. GPU's are now more powerful than CPU's, fact. "GPUs excel in doing lots and lots of parallel calculations". Exactly, in games, there are lots of things happening in "parallel", ideally suited for GPU's. Sure, we won't see any of this stuff in Arma 3, it's based on a revised version of an engine written years ago for a different time. But when talking about how it would be tackled now, then yes, for a new engine, I would be surprised if anyone in their right might wouldn't want to support x64 and GPU power from the start.

I must admit, I would be interested to see BI start from scratch with a genuine new engine, built with the wisdom from what they have learned from the limitations of the current engine. I think Arma 3 is looking great, but straight from the start I can see it has all the same problems of the past games in terms of performance, especially when it comes to AI numbers etc. I also get the feeling that the environment/landscape is pretty static. I would like to see an engine with capabilities for de-formable ground etc, where if a satchel goes off it actually leaves a crater, rather than just some texture plastered over the ground. Again for example, trenches, there is no way we could create our own in the current engine, it would have to be made as part of the level. Stuff like that I feel is not possible in the current engine.

I think there might be some new commands in Arma 3 that could be used to improve the script. I suspect it will either be updated or another option will turn up soon. I see commands for waves, maybe when the wind is strong enough the waves will get more choppy...

This is pretty cool! Thanks! A few things that could be cool to add: an option to activate and deactivate the placed explosive, as well as an option to remove the explosive. And perhaps a duration timer for attaching/removing and activating/deactivating the explosive so it takes a few seconds to do the actions.

I get errors when the script trys to add back the weapons after respawn. Would it be possible to add a config variable to switch the respawn with gear features off? I am still having the problem where after a while the first aid and drag action menu options no longer show up and only respawn shows.

I think you could put this in the OnActivation code block: {_x allowdamage 0;} forEach thislist

Does this mean Arma 3 is making use of DX 11's MT features? If so, what specifically get run through it, just the physics or other stuff like ballistics and ai?