PiZZADOX

32bit plugin will definately load. You need to launch the 32bit version of the teamspeak program and make sure its in the plugins folder. It doesn't matter if you have a 64bit system. See edit in above post for new information about server compatibility. updated dropbox link: https://db.tt/W3Hd2T8S

This looks great!

Just advance the date of the mission. Moon phases during the month. ArmA moonphases are *supposed* to be accurate, but really they just follow a simple algorithim. Just advance days until you get to a suitable level. Remember the moonlight is also limited by cloud cover and the time of night.

Alternatively you could make it so the script is executed through a check inserted in the opfor player switch system, so that way only the opfor which get used as players have nightvision. Of course you could always just make sure that the moon phase lets you have enough light for combat at night without nvgs.

just do an addition on each unit spawned, should be in the server functions. Insert a check for the unit having nightvision, a hasweapon check, and then if it fails the check, add nightvision, if it doesnt, don't.

Only the 32bit version works properly

No, the api needs to be updated for both of them. EDIT: no api conflict in MP with different versions. Versions ruled completely compatible. Server only needs 1.4.10 to enable client version 1.4.10 or 1.5

No radiomod IS unacceptable for ACE... it just doesn't fly. I did an update of ACRE 1 so that people could use it with the latest version of teamspeak, because people always complained about some icon pack or something dumb like that. https://www.dropbox.com/s/stn4lstjufyfn1o/ACRE_1.5.rar?dl=0

Couldn't get an error for it, but all the people i play with are reporting a loss of about half of muzzle sounds, players and AI. (headless client or not) You would think it would be a mod conflict, but two things convince me it is simply a netcode problem: a) This never occurs in singleplayer, at all. 2) The same people reporting the error, which is everyone playing on the server, hear the sounds every once and a while. It happens intermittently. Impact and dust effects from the rounds are always counted and played, so I am not sure if it is a cut off from the maximum sound samples setting, which has not changed. Is anyone else getting this error? We switched back to 1.62 and every sound is played as intended.

Great response and points .kju, I'll be lurking in that thread, a very interesting discussion and one that could actually be constructive for BIS. Perhaps the future of BIS could be one akin to Epic or Valve, developing a platform for communities, and prospective developers, to utilize and tailor to their own tastes - be that milsim or wasteland. Concentrating far less on content and more on engine features and optimization.

90% of what I make, which is more scripts and quick addons rather than hard added content, isnt published. I wouldn't say it doesn't meet the mark, but it's so niche, it's honestly really only in house stuff that I do for myself and the people I am playing with, and i really didn't think anyone else would have any interest in it. Nothing near to Ace or any of the biggies, never had the time to dedicate a huge part of my evenings/weekends to these projects. They had top men working on it. I could recognize that from just the simple class defines... It's basically the module for expansions and dlc that we are using to add in content, is it not? As you said just a by-product of how the engine loads it's data. I would say it was a big possibility this was built around VBS contracts with different partner packs or simply a very easy way to load dependent expansions. Quite modular compared to say Cryengine 1's data system. I really haven't delved into A3 modding as I stated before it simply does not interest me, but what I do know about the new systems they have added, it that is just piles up on the old data and adds new structures entirely. The worst sort of thing for backwards compatibility, as those older assets need to be fixed up, as you know very well, and it discourages people from entering at that stage. The more and more they add to an outdated engine the more and more needless complexity builds up into a poorly optimized (and more importantly very hard for the devs to optimize - I believe they are trying) overly complicated mess that frankly needs an overhaul, in my opinion. I hate to be that guy, but as a well known community modder, what would you say the devs could do to try and alleviate these problems? Spend a large amount of time on a fresh new engine? A few months of work on adaptive backwards compatibility for the older assets, or simply convert them themselves?

Referring to optimization/ selective fixing of feedback tracker issues?

Exactly :( I don't think there is anything wrong with Bohemia doing this, but I don't think the "real" :rolleyes: modders are not in it for the money, and to be honest a lot of the most popular voted mods are not going to be the best polished (DayZ's scripting comes to mind) or even the most inventive. I would rather have every cent stay in Bohemia's pockets to put towards allocating time and effort towards platform updates and optimization. A number of fantastic additions and fixes to the engine will motivate people far greater than any amount of money.

Introduction: We are a tactical milsim unit that attempts to emulate the good and fun parts of the military and avoid the bad parts (retarded ranking systems, saluting and officer attitude in general, and online bragging rights) We are dedicated to fun gameplay, emulation of tactics and procedure in a methodical and organized manner. Organization: We model ourselves after 1st Platoon, Bravo Company, 3rd Battalion, 7th Marines. We are a rifle company, complete with the attached platoon corpsmen and HQ teams. Weapons and loadouts are role and mission dependent. Expect little to no optics and long range radios unless you are in a special billet. Available Positions: Within our unit you will have a select role that will give you a preferred role in our missions. You will join a squad and train with your fire team, squad, and platoon in scheduled training sessions. In our missions, we try to keep the same people together to utilize the "train as you fight" system. Infantry Billets are always open and we are currently looking for rotary pilots and air crew. How to join: Visit our teamspeak and speak with any of our members. Mod list: Modlist Requirements: -Must have a working microphone. -Must have a valid copy of Arma 2 and Arma 2 Operation Arrowhead. -Must speak english competently. Contact us: Teamspeak 3 IP: 3rd7th.ts3dns.com Steam: PiZZADOX : http://steamcommunity.com/id/LiveFreeOrPie Steam Group: 3rd Bn 7th Marines [ACE/ACRE] : http://steamcommunity.com/groups/3rd7th Website: http://509thparachuteinfa.wix.com/3-7thmarines

Squad name:- 3rd Battalion 7th Marines Timezone/location : GMT - 8:00 Gamemode preference (eg coop or pvp): CoOp Contact email: 509thparachuteinfrantry@gmail.com Website address: http://509thparachuteinfa.wix.com/3-7thmarines Short description: USMC Milsim unit utilizing ACE + ACRE with a variety of custom modifications. Plays tactically but doesn't enforce stupid rules that don't work in Arma. Language: English

Hey guys, I am trying to amplify sound within the engine for a playsound .ogg file, and discovered that repeating the playsound command will amplify the volume (This speaks to the arma engine's reading of sound files haha) The technique I am using to amplify sound is this: This seems to essentially amplify the sound, as long as they are executed quickly. The problem is, in MP the server will not perfectly synchronize the start of playsound, meaning that there will be a slight echo effect unless you are near to the sound source when it is played. Does anyone have any experience with amplifying sound files and multiplayer synchronization issues? Thanks in advance

There is a maximum volume of a sound file, as well as a maximum volume of sounds played by the engine. You cannot just alter the file to be as loud as you want. Programs that emulate this, such as VLC, create a sound overdrive style amplification through playback past the file's maximum volume via your driver - arma's engine does not allow this natively. This is not volume, but volume over distance. It does not directly alter heard volume but rather extends the distance before the sound starts to fade. haha, of course! It's really bad practice, and its the reason I have a multiplayer sync issue in the first place... but I've explored alternatives are there just doesn't seem to be any. Amplifying the sound via multiple drive seems to be the only way to effectively increase the volume in comparison to other things in game (past the limitation of the file itself)

BTW always good work Goliath, you're doing God's work. :cheers: I'm getting visible markers (debug markers) when I call the BIS locations function, mil dot in citycenter location and a rectangle marker between citycenter and neighbours. Line 22 of fn_locations is activating the debug for many older missions that call it with a false in the third param. lets older missions define true manually just to be safe

Here you go, https://dl.dropboxusercontent.com/u/187563416/weapon_weight_nohint.rar Hmm, weird, I'll let them know, Thanks.

Arma 2 port release, http://www.armaholic.com/forums.php?m=posts&q=30676 :)

Hey mate, two things. Do I have permission to port this to arma 2? Great idea, and a lot of players, especially those aiming for realism, still play arma 2 and we have needs too haha. I'm not entirely familiar with arma 3's changes to the game actions. Does lowering your weapon automatically take you out of the sights? I noticed there is not a check for this currently in your script. If arma 3 doesn't account for this, here is the code to check for and switch view out of the gunner, ie sights, mode.

Here is the older maptools that work as intended. (Dragging with mouse, etc) Just replace the pbo inside your ace folder if need be. Of course this alters your ACE... https://dl.dropboxusercontent.com/u/187563416/ace_sys_maptools.pbo Also - Here is the old weapon resting. I have to disagree with rocko, we are trained to adjust our bodies to the weapon, not the weapon to our bodies. Sights should work as intended in previous versions before the change. (3 point iron sights align with player's eye, not grade of terrain) https://dl.dropboxusercontent.com/u/187563416/ace_sys_weaponrest.pbo

It is a simple error in the script, here is the standalone version with the fixed variable names: https://dl.dropboxusercontent.com/u/187563416/sam_grg_system_standalone.pbo Let me know if there are any script errors. Due to the nature of how the scripts store information on a global variable I could see some issues with a multiplayer framework.

Exactly. It is breaking multiplayer functionality, particularly with player slots and parameters. Every addon that used an undefined variable holder (which we can argue was right or wrong in the first place) is now broken and requires updating. With Arma 2's life cycle, I don't see any reason to do this. Why wasn't this change implemented early in the game's history to allow for modders to compensate? What I'd really like to see is BI come out with a hotfix that no longer has the more strict script interpreter that breaks their own code and nearly every single complex addon, but with the numerous improvements and tweaks they have made.