Vixente

Mother of the beautiful love! “¡Madre del amor hermoso!†(Spanish expression of astonishment) What a bunch of BS. Sorry but I had to say it. If I were to live in Finland for say, about 10 years (and that is a lot) in different cities/regions the last thing I would do is get involved in a foreign country politics or history. Because I wouldn't have the right nor the knowledge to form a decent opinion. Even after having been there for years. I’m not a native, I haven’t studied there, didn’t grew there. As a personal motto I often tell to myself: "Don't trust anyone, don't believe all that you read or hear, question everything". I try to apply that to everything, every day. Many things have been and can be said here about this topic. But one thing is true, whether you like it or not, Catalonia is part of Spain, has been and will be. You can't just detach a region of a country because a part of its inhabitants just want to. You can't even accept a normal vote in a region when you know that there are a lot of absent people (a big percentage) that do not go to vote, which is BTW a big problem in this country. Even after that, the just thing to do is a global vote of all the regions in the country to determine whether or not one of them has the right to go independent. In any case, I think this topic should be locked as all topics about politics of any country. I don't think this is the forum to speak about this. These are serious topics that can get people banned, confused or mislead. I will only say one more thing, MistyRonin, I’m sorry but you are very wrong about a lot of things concerning Spain/Catalonia or its inhabitans. Please, stop.

Oxide Games did, at APU13: And AMD said Mantle will be open, so others can make their own drivers. If they're willing. Give it a few months to see more demos/tech related. Or being a developer studio yourselves, contact AMD and see if they can 'lend you' Mantle beta API and documentation. ;)

Actually they set LAA to Arma 2 a while back and that means max of 3GB under 32 bits OS and max of 4GB under 64 bits OS. (And this limitations is just because the executable is 32bits, this has been discussed in many threads btw) I'm using 64bits and i've seen A3 consuming almost 2,2 GB just flying around Altis in SP without setting any -maxmem parameter. (Autodetect ftw)

I don't doubt or deny your words or the facts, i've experiencied them myself with some friends too. But in that case the culprit is, probably, the server's hardware/bandwith, and then the engine performance&netcode (obviously). In those ocassions it would be ideal to ask everyone in that server how much FPS they have, performance, their current settings ingame and also, to the server admin, the server hardware specs including bandwith and its actual use in that moment. (They maybe running some other service in that server) All this to compare and gather all possible technical info. I don't recall any detailed info but from single players in some random servers. Which is not bad info at all, but isolated and insufficient. Although i've been following very closely this and others threads ( contrary to what White insisted i didn't do many months ago :P (Where is he btw?) i don't remember everything and i could be wrong and someone could have wrote a detailed post as i just suggested.

Please, don't generalize that much. It's not 100%. Some people can play pretty well (40 FPS) with high end machines in crowded (and good) servers. Don't conclude that every player is reading or is posting in this thread, many people is playing happily without many worries. And no, most of them are not naive as you are implying about the low FPS aspect. My case? I have 4 year old hardware, i've aknowledged that and turned things mid-down since Alpha. Most of the effects (if not all) are in normal, terrain draw distance 3km, object distance 1,5km. AA off. (yes, off). All of this to be able to achieve almost 40-50 FPS (Altis) in SP, 25-40 in good MP servers and 15 FPS in poor MP servers. Don't get me wrong, i'm not dismissing the problem, i WANT more performance, i know that this game should run better in all computers (including old ones like mine). But many of the people posting in this (and other) threads or forums are not being specific about their hardware, A3 configs or other details like server info. I did vote the issue many months ago, because it's a critical one, but i'm not irritated because i've went through a similar experience in the past. (Arma 2, which i begun having barely 25-30 FPS in the best scenarios to having 46 - 50 now)

I suppose this game is made using C++ and you guys probably know what i'm about to tell you, but anyway: C++11 has some cool new features for concurrency and thread safety. You might wanna check those. - atomic type variables are race-proof. You can write to an atomic variable in one thread and read it from another thread and they'll behave fine automatically. - async keyword will (probably) run the specified function in another thread. You can pass some parameters too. - future and promise are also used to run tasks and get the result, ideally from another thread. - Of course you have thread which is now easy than ever to make new threads. There are a few more, but these are already pretty important and game-changing.

Done. You can find it here: https://www.dropbox.com/s/i6knroqz2j9k05e/FSF_Spanish.pdf I've added Tooltip translation to the tooltips i've seen. Let me know if you need anything else. Also let me know if you want me to do the same for your server launcher, i have no problem with it, it only takes me a few minutes to do it. ;)

Do you need any help with the spanish translation? I offer my help to you if so is the case. ;) Nice job BTW.

Very nice man. Being a hobby developer myself i think i can appreciate more the effort you put into this app. Thank you. ;)

I doubt it. Clientside, A3 running Altis, 2 hours just with me piloting an AH9 around: A3 RAM usage: 2GB Swap file usage: almost 4 GB. VRAM: 1.5 - 1.7 GB I'd say it's ok for a massive map like Altis. (way way bigger than Stratis)

What are you talking about? From the wiki: All it does is generate up to 3 more threads for the texture loading/gemoetry loading / fileops in the CPU to load it from the game data files in parallel. It's the CPU (and not the GPU) who loads that data into the RAM or video memory.

Helicopter Inception. "Me, recording myself flying a chopper, recording myself flying a chopper, recording myself flying a chopper." -rUpqMRE3-A

I've been playing with BIS_fnc_UnitCapture and BIS_fnc_UnitPlay. All was working fine, until i wanted to reuse/replay the path again without restarting the mission. In the second run the vehicles start flickering like if they where following two paths simultaneously. At least that is what i think based upong what i see, because you can see the same helicopter being teleported back and forth. Take a look at this video: FPOJ85VMrmQ Is there a way to stop UnitPlay from doing its job ? I tried to restart everything, even destroying the variables that contain the path, but it didn't work. It kept 'accumulating'. What i've tried: path1=nil; path2=nil; path3=nil; heli1 setPos [1849.212,5.5,5740.4668]; heli1 setVelocity [0,0,0]; heli1 setDir 90; sleep 0.1; heli2 setPos [1821.5199,5.5,5742.1831]; heli2 setVelocity [0,0,0]; heli2 setDir 90; sleep 0.1; heli3 setPos [1794.5629,5.5,5740.7124]; heli3 setVelocity [0,0,0]; heli3 setDir 90; sleep 1; ---------- Post added at 10:43 AM ---------- Previous post was at 09:42 AM ---------- EDIT: Well, i managed to fix it myself. :bounce3: I just gave variables to the script spawns... script1 = [heli1,path1] spawn BIS_fnc_UnitPlay; sleep 0.5; script2 = [heli2,path2] spawn BIS_fnc_UnitPlay; sleep 0.5; script3 = [heli3,path3] spawn BIS_fnc_UnitPlay; sleep 0.5; ... so i could terminate them before spawning them again: heli1 setPos [1849.212,5.5,5740.4668]; heli1 setVelocity [0,0,0]; heli1 setDir 90; heli2 setPos [1821.5199,5.5,5742.1831]; heli2 setVelocity [0,0,0]; heli2 setDir 90; heli3 setPos [1794.5629,5.5,5740.7124]; heli3 setVelocity [0,0,0]; heli3 setDir 90; terminate script1; terminate script2; terminate script3; And everything is working fine and dandy. :) spawn calls the script in parallel while call seems to do it sequentially (i think). But to avoid the problem i was having i just had to terminate the BIS_fnc_UnitPlay script spawn just before doing it again. ;) 46R_nQsa5XU +1000 XP points gained.

+1 This should be stickied. I am looking for good video tutorials to learn to use the editor with a mix of scripting. Do you know of any guys ? Thanks in advance.

Thank you so much, will test it this afternoon. Have a great time. :)

Why would they need this solution if they are very capable of making (and improving) the multithreading capabilities already in the game? As a programmer you can specify the core affinity of one process from the start, but it has no particulary usage in a game as it is, so it's normally left by default (uses all possible cores) or adjustable by parameters like in Arma. Also, as demonstrated before, like many, Arma is a multithreaded application, so it's already using all the cores it can get from the OS. It's the latter who decides which cores to assign to the program in a normal situation (no affinity set). The problem is not using more specific cores, the thing is making those other threads use more CPU or share the load of the main thread to avoid bottlenecks. (if that is really one of the problems) I think the game is complex enough that it's no easy task to modify the multiple thread setup as it is right now.

I got sad when this project stopped back in Arma 2. The day i saw this thread by L etranger i felt like this:

Proof: http://forums.bistudio.com/showthread.php?147533-Low-CPU-utilization-amp-Low-FPS&p=2350877&viewfull=1#post2350877

A parallel thread must not access memory that is being used by another thread. So it's natural for the programmer to put locks and callbacks to operations that need access to certain shared memory. What is retarded is wanting a mission with 1000 AI running at 30 FPS just because you own Intel's top CPU... /facepalm Also i've only seen a few threads about clouds or PhysX stuff... about 4 or 5. I'd say that it is the main thread. How do you prove that the first thread (not core) is bottlenecking? because it's using 70%-90% cpu time? Have you seen what that thread is doing? Do you have the source code? It probably is the main loop and apart from other things i've been capable of seeing that is the one capturing keystrokes and mouse movement using the type of tool you commented. (just for curiosity) Some other threads get about 40% usage and a few ones peak to top sometimes. Yes it should be more because the logical thing to think is that more usage, more FPS. But it may be limited by other factors that we don't know. I'll never deny that this game needs optimization. Or even redesign. What you cannot say or argue about is that this game only uses one core because it's not true. But the one with the 3960 probably it's the same dude that comes to Arma, sets it all quality to the higher extrem (specailly draw distance... 10km) and see 60 FPS. Duh! I've read that, why are you always assuming i don't read this forum or thread? I've said in my last post that they know what the problem is and that they'll fix it, or at least improve it. I know, i've been here about that long. Your words, not mine. I've only meant that it's playable to an extent with a good server (computer & bandwith) on the other side and with common sense. Yes i'll say it again... it's an alpha.

No one is trying to sound intelligent but yourself and a few others. I've only stated that this games are multithreaded (it's a fact) not how they are designed. Thread synchronization comes naturally with multithreading, that's not new or bad. (Only when there is a lot of overhead sync) But the one who decides the balance of the cores it's the SO. There is no sense in doing it other way. The -exthreads parameter is pretty descriptive about all this, also -cpucount (affinity) sets depending how many cores it detects. Both were implemented and automated a lot of (A2) betas ago. Also, i have been reading this thread. But had to post the moment someone started to post and quote BS about the game only using 1 core. TLDR: The problem it's not that bad, people's whining is exaggerated. They will improve the engine as they've been doing it for years.

Stop this BS about Arma 3 or 2 being only 1 core capable. It's a pathetic fallacy. Arma 3 as Arma 2, are multithreaded applications. It's the OS kernel who balances that load of threads of any process between the available cores. I used the Performance Monitor Tool that comes with Windows to check how many threads Arma 3 is using. And it's using a lot of them. Between 30 and 40 at any given time. You can't argue that this game/engine it's not multithreaded. Period. The underlying problem must be other, they know it, they'll fix it. Period. http://img17.imageshack.us/img17/9622/a3threads.jpg (498 kB) PS: Before anyone comes complaining, i was on the desktop the moment i hit 'PrtScr', so arma3 process was barely using CPU because Windows kernel decided so.

This is F. awesome. Thanks a lot man. :bounce3:

Test and try graphical settings :rolleyes:

What does the '-client' parameter do? Does the HC open as a text console (cmd style) and display events like the linux arma server binary?

Use commands, they are good, and Windows has them too :) Since Windows 2000 you have a nice program/command called 'taskkill' and yes, it can kill tasks (AKA: processes). Use is very simple, just pass the .exe name. Like this: taskkill /IM notepad.exe where notepad.exe is an executable program that is running in that example. To be sure that it ends the server process add /T /F keys so it forces the kill. Just make a task to stop when you want, and then after that another one starting it up again. Just as easy. ;)