CarlGustaffa

I'm still having some mental issues with what I've seen so far in the video and released screenshots. Minor issue I'm sure will be fixed. But in one picture you can see an aircraft instrument panel. It "looks like" every screen is turned off, but it can be an HDR effect. However, the backup attitude indicator is flipped upside down Graphically, it looks generally impressive and better than ArmA. Anyone would expect that. I really don't mind too much that fallen trees have a bad animation, although I agree it could have been made better. I'm more worried if the result will still have viewblock object, or if the AI can still see right through debris? There appear to be mostly woodland fighting to come, and this would be a severe limitation. And how about that ever hauting issue about screening smoke not screening anything from AI? They are promising us supressive fire, but how does it work? Will AI perform supression? Will the react properly while supressed? Or is yet again hit & run tactics again the only thing that will work in this "simulator". Walking with Binoculars would be cool, but to me it is of greater importance that there is builtin support for more binocular types. Each one with its own kind of benefits, i.e. zoomable, builtin nvg, rangefinder, spotterscope (heavy zoome, tripod) etc. Again it "seems like" weapons are premodelled, that is, comes in given configurations. The engine doesn't seem to support configurable weapons. But frankly, I didn't really expect it either. Agree on the explosion effect. Really bad. How about (for simplicity) first a hit effect with scrapnels, then start burning, then a crossfade between normal and black textures while burning? I've been missing bikes since OFP, ArmA only had motorbikes. The mountain bike is a nice addition (but hopefully motorbikes are still in). But how about giving such vehicles some kind of shock absorbers on the view? In real life you don't get disoriented from hitting a small bump. It's like your brain makes up for it or something. Same thing with banking a bike, you tend to counterbank your head while in ArmA the whole view is banked equally. Civilians and animals looks fantastic. Spot on, just what I wanted. But I hope other more important stuff hasn't suffered by including this. The campaign looks great. I belong to the camp where I doen't mind team switching and revive (if done right). But having to resolve to teamswitch to unstuck a character should be avoided at all costs. Character wise, it looks a bit like Queens Gambit, and I hope "general characters" (ground units) other than these are also supported. You probably won't bond as much with character as OFP, but looks better than default ArmA campaign where I still don't remember any of the characters I played. Voicing sounds horrible as ever! I don't mind static sounding voices, but their "type" should vary with combatmode. I mean, if going stealthy, would they shout like that into the mike? Should be one for "normal" and safe behaviour. One for "shouting" behaviour when firefight is intense. And one "quiet" one for stealthy movements. Anims for crossing low fences should be implemented, as should jumping. Sure we carry a heavy BDU and equipment. Sure this is not a jumping game like Unreal Tournament. But jumping and traversing should be included in any decent "realistic" combat sim. And I haven't seen much of hand signals yet, and reactions to them. Will they be magically seen by the guy on the other side of the house? I'm just hoping that I will be able to lead my clan fireteam using handsignals instead of voice, for immersion. The landscape looks completely mindblowingly terrific! It looks realistic. No more 60° sloping "hills" like in ArmA. Hopefully though, I will be able to find cover and concealment in this landscape that is not only based on trees, grass, and bushes. But can we now find any tactical routes of advancements? In ArmA nearly everything is out in the open. Especially what I'm looking for are small ditches and rigdes in the landscape that will provide cover from a known enemy. And what about slots for equipment? Is it still ArmA based? Is it still based on predefined slots? I.e. I would like map, compass, and gps to take up valueable slot space (and have weight that affects endurance). Does the engine now support scripted slot occupants, such as a first aid kit with graphics showing up in the inventory? Many of the issues I point out are "engine" issues, some dating back to OFP. Someone mentioned "engine" being DX10 related, but thats a graphics engine issue, big difference. I am very pleased with most of the graphics I've seen, but to me graphics is less important than gameplay and possibilities allowed in the engine. Scripting wise that is, not addon wise. I guess every game needs to have decent graphics to attract new players, but old flaws should have number one priority or they won't last long. At least I don't think so.

Wanted to do a similar thing a while back. I think I used getIn and getOut eventhandlers to try to fade music up and down in volume. I had a weird bug back then, that the track would actually restart instead of fade, but only on one of the directions (fade up OR fade down, can't remember anymore). I'm not sure if this bug is still present with the engine.

Try windowed mode. Only bug of this sort I have ever had was crashing to desktop with the old famous error. I haven't had that bug with any of the latest patches. Several clan members have problems switching back and forth from ArmA in full screen mode, but in Windowed this never seem to happen. Btw, I'm using windowed since I really can't run the game in full screen highest native resolution. Anyhow, the reason I checked into this thread again: It was mentioned a while back that future patches could use help from the community. Where can I find this info, and where can I upload files and fixes for checking?

I'm no expert, but publicVariable and addPublicVariableEventHandler does seem like logical choices here. The event handler will not fire on the client updating the variable though. Check out the mission Domination how the vars_array are used in this fashion to store variables and mission progress for jip'ing clients.

I haven't found a way to stop a "say" command from playing the sound. To overcome this, I simply moved the object far away [0,0]. I'm not sure what kind of object I used at the time, maybe a game logic. Now I tend to use invisible heli objects to play sound, and they seem to work in multiplayer as long as a addPublicVariableEventHandler is triggered on each client. But for single player missions, stick with "say" for localized sounds (can be a problem with cameras and intros though). If you want to stop the sound, move it to [0,0] i.e for a radio station you turn on and off.

A suggestion that might help server crashes: One of the main problems is the amount of error messages (I believe). One of the reasons this happens is that because of the amount of armor, you usually are forced to take down a whole main target before even attempting the radio tower. Radio tower should be placed using a new random function, that implements a minimum distance from main target center. If radio tower (and some guarding units) were placed 150-300 meters randomly from main target center, it would be possible to take it out before so many reinforcements arrive. Now the usual approach is clearing the target, then the radio. Why wait for a new server update to release a fixed and updated Domination version? "All" servers are 1.14 today, and I guess all versions of Domination is suffering from this problem? Btw, I tried removing the tanks from the check_trigger, but often now I will get a target cleared message before the mission was generated. I have tried now adding setTriggerTimeout to see if it helps. Not been able to test it yet though. Edit - Quick bugreport: setupplayer and setupserver checks against d_subver. This check is left out in x_jip.sqf. Another thing that might help crashes, it to limit number of targets in description.ext to only include 2,3,4,5,6,7,8,9. That way, no editing is needed for Schmalfelden version as well. Does anyone sit through 21 targets in one go?

We only score points in ArmA for fatal kills, not i.e. mobility kills. I'm not a big fan of the scoreboard, and our server has it turned off. But in order to get money (not points I guess), you can add a damage or hit eventhandler to the vehicle your firing at. If ((!canMove _vehicle) || (!canFire _vehicle)) then execute the "givememoney" script. Naturally the one actually destroying it will also recieve money.

I have no idea about AI enabled or disabled, but Domination mission is removing every possible kind of action from a dead player, then adding them back again on respawn. There is a separate script for JIP, but also setupplayer and respawn. I think I understand the concept of the scripts, but trying to explain other peoples scripts I think can lead to more confusion than being helpful. @HeAvY TrAnCe: I think you just have to examine Evo scripts. I don't play Evo and only briefly tried to learn the scripts a while back, but gave up (maybe I would have better chance today with more knowlegde). In Domination though, there are several methods in play. Arrays of positions and directions for newly generated "bonus vehicles", respawn scripts for boats, and respawn scripts for vehicles and choppers. Respawn scripts are typically run on each vehicle and restarts itself when vehicle is destroyed. Only scripts, no description.ext stuff going on.

Played on {GOL} clan server yesterday, public game of Domination going on, and had a weird experience. The server was infested with team killers killing everything they saw near spawnpoints. Server was unfortunately setup with no tags or info or anything, so nobody knew who to kick. We ended up just playing somewhere else. Is it possible to add killed eventhandler that sets off a addPublicVariableEventHandler on all clients that just informs players who the culprit is, and the command used to kick this person? Everyone (well, most) will teamkill once in a while, but usually it is a freak accident or mishap (such as using timed satchels on radio tower when someone is actually on top of it, LOL!, but teamkillers like these are no fun to those who actually wants to have a good time.

I have never used or even seen that createSoundSource command before, so I don't know what its intented use is over the "normal" sound commands such as say or playSound. I suggest you read up on tutorials that utilize these old commands instead. Download a single player mission that uses custom sound files (most does I think), de-pbo it and examine it in the editor and its description.ext. Copy this setup to your own mission using the original sound. Make sure this works. then try replacing the sound with your own. If it still works, the sound file is at least ok for the given command used. If not, you have to try other save settings in your sound editor.

I'm doing my Schmalfelden conversion and I noticed a little something of a bug probably affecting all versions. 1. As far as I can see, the function fn_GridRefCoords is not in anywhere, making two calls to it from scripts\teamstatusdialog\teamstatusdialog.sqf. This makes the team status dialog fail (in all versions?) regarding the pos and command fields. I'm precompiling this from init.sqf since both server and clients in my version is using this also in other scripts now. 2. The function fn_GridRefCoords will not provide the correct readout in Schmalfelden. I will try to fix it by hardcoding it within the function to account for Schmalfelden grids, but I think a better way would be accessing grid data from the addon/island and using these as variables. Dunno. 3. Schmalfelden version unpacks as 3.05 but briefing and intel says 3.03. Also the old intro selection trigger is still present in mission.sqm. If you do a copy&paste, just remember to remove/filter the boats respawn scripts within init.sqf. Awesome to see so many suggestions implemented. Edit: Oh, and while I'm at it, I replaced the IncomingMissileEventHandler in default version to use the graphics system from the Mando version. Reason, the flare system didn't work for me using muzzle name, had to use ammo name (or vice verca), and it just didn't look very good. Mando flares look awesome! x_playerfuncs.sqf: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> if (d_version != "MANDO") then {   XIncomingMissile = {     private ["_vehicle", "_ammo", "_who", "_missile", "_flare", "_flares", "_ran"];     _vehicle = _this select 0;     _ammo = _this select 1;     _who = _this select 2;       _missile = nearestObject [_who,_ammo];       if (isNull _missile) exitWith {};       _vehicle vehicleChat "Dropping Flares...";     [_vehicle] execVM "bat\mando_chaffflaredraw.sqf";       _ran = random 100;     if (_ran >= 40) then {       waitUntil {((_missile distance _vehicle) <= 150)};       deletevehicle _missile;     } else {       waitUntil {((_missile distance _vehicle) <= 100)};       _vehicle vehicleChat "!!! Attention !!! Missile impact...";     };   }; }; My "bat\mando_chaffflaredraw.sqf" (differs from original): <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> /*mando chaffflares mando_chaffflares.sqf v1.2 April 2007 Mandoble Generates a chaff or flares "clouds" able to attract mando_missile missiles aproaching in mode 2 (active mode) DO NOT EXECUTE THIS SCRIPT MANUALLY */ private ["_maxspd", "_mass", "_vol", "_rubb", "_launcher", "_type", "_pos", "_drop1", "_script", "_color", "_size", "_i", "_numdrops", "_angv", "_angh", "_rad", "_radv", "_radh", "_vel", "_vell"]; _maxspd = 10; _mass  = 1.275 + 0.3; _vol  = 1.0; _rubb  = 1; _launcher = objNull; _type = -1; _pos = [0,0,0]; _drop1 = ""; _script = ""; _color = [[1,1,1,1]]; _size = [1.5, 3.5]; _i = 0; _numdrops = 0; _angv = 0; _angh = 0; _rad  = 0; _radv = 0; _radh = 0; _vel = [0,0,0]; _vell = [0,0,0]; _launcher = _this select 0; _launcher say "mando_flares"; _vell = [-(velocity _launcher select 0), -(velocity _launcher select 1),-(velocity _launcher select 2)]; _drop1 = "\ca\data\koulesvetlo"; _script = "bat\mando_flaremove.sqs"; _color = [[1,0.8,0,1]]; _size = [1.5, 3.5]; _numdrops = 10 + random 6; for [{_i = 0},{_i < _numdrops},{_i = _i + 1}] do {  _pos = _launcher modelToWorld [0, -3, -2];  _angv = random -90;  _angh = random 359;  _rad  = 30 + random _maxspd;  _radv = abs(_rad * sin(_angh));  _radh = abs(_rad * cos(_angh));  _vel = [(_vell select 0)+sin(_angh)*_radh, (_vell select 1)+cos(_angh)*_radh, (_vell select 2)+sin(_angv)*_radv];  drop [_drop1, "", "Billboard", 0.1, 5, _pos, _vel, 0.5, _mass, _vol, _rubb/8, _size, _color, [0,1,0], 5, 0.05, _script, "", ""];  Sleep 0.01; }; I'm unsure how drop works regarding multiplayer and I haven't been able to test it fully for multiplayer yet, but I can see preplaced AI (local to server) dropping flares. Maybe you need to set off a addPublicVariableEventHandler to every player so they see the particles, just not sure about this one yet. bat\mandoflaremove.sqs is equal to the original.

If you look at Suma's engine code, it takes both skill (ability) and adds a little randomness to the system. My code doesn't have anything to do with NVGs or scene brightness whatsoever, it is only a way to determine if it is night or day by triognometric means. It is not "accurate" but will fill at least my needs: Use of illumination rounds, and setting up dynamic mission (Domination Main Target missions) as a night or day mission.

Hi Does anyone know how the engine handles daytime? I mean, daytime changes throughout the year, but how does AI know when to use NVGoggles or not? I.e. at January, daytime may start at 0800 while in July in may start at 0500. How can I use a check like this in a script, getting the same results as the engine would use?

Countdown timers in the wait waypoint, landing mechanism, and cycle waypoint near the first waypoint (loop waypoint).

Small bugreport. I've decided to go with your method of limiting ammo per class instead of limiting crate contents per vehicle class. Although the system looks pretty good, I beg you to take a better look at the default contents per crate. Even though you don't use d_limit_weapons by default, the contents of every single players crate is just insane. It doesn't make sense to me that every player gets 10 off each of every single weapon even if being generous, as crate is local to player anyway. Even the amount of ammunition per crate is way high, 50?!? Wouldn't one of each weapon and 8 in ammunition suffice? Naturally even this is extremely much if played for realism, but then the d_limit_weapons should be used and limited even more. Myself, I'm actually using a custom weapons crate loadout only available at base, and with only ammo being possible to get out in the field (with d_limit_weapons enabled naturally). Oh well, in any case, there is a bug in init.sqf where (at least) Smokeshellgreen doesn't have a count.

FDF for armory sounds and ECS for ambient sounds (and system). I tried FROMZ and had mixed feelings about it.

FDF for armory sounds and ECS for ambient sounds (and system). I tried FROMZ and had mixed feelings about it.

InitAngleY, is it possible to set this i.e. as a UH60 driver, so that the the pilot automatically looks a bit downward? With the current zoom level, the attitude indicator is never visible and the autosnap (annoying in y direction, good for x direction) brings it back out of view.

No, I haven't seen SLX or ACE. I'm hacking the Domination mission using ECS bleeding and own produced firstaid kits (no uberkits to fix all damage, making medics more desired). I'm just saying that many like todays revive system, except I think it is a bit too powerful. However, having a built in system allows for ArmA2 based scripted revives to be less flawed (causing desyncs) than today. Most likely these issues will no longer be an issue with ArmA2.

I'm placing searchlights in my Domination version during night mission generation. And I have yet to see that they are turned off unless shot. I think you may have made an error somewhere. Works fine both in singleplayer testing and on dedicated server runs. Sorry, misread. I am only using AI, haven't checked with players entering them.

Maybe it has already been reported, but I'm too lazy to check through all posts in this thread, but - dedicated server bug: A paratrooper, at least AI, who ejects from the parachute when he lands on the ground is causing an error message in the server RPT file, with a possibility to cause an "out of memory" crash on the server. The crash sometimes (always?) doesn't really inform the player of anything, the player will notice server crash only by nothing is happening. No red chain. Also ref this Domination thread in user missions: Xeno's Domination Thread

Roger on the "tanks", and well, hope you come up with a solution on the paratroopers. About the MHQ marker bug. Some mechanism inside the revive scripts (most likely) is causing the marker to jump back and forth between the MHQ original position and its current position. I'm also seing this behaviour online, so I don't believe it's a self inflicted bug (for once). During singleplayer testing, it works fine though. But I can't find any instances of setMarkerPos within that dir. I'm lost... I just joined a revive version and had the problem with a clean no-addon ArmA. Same bug happens.

Does anyone know anything about my original comment about the 90 round magazine for the M4? Anyhow, I've seen episodes one through five (1-4 three times!! ), and I'm amazed about the attention to details and strive to make it look and sound authentic, instead of i.e. replacing "military talk" (lots of abrevations using phonetic alphabet) with something ordinary people just might understand. My guess is that all the "comments" made may come from different situations that were not included in the series (or book?). I can understand the screenwriters desire to have some "talking" going on even if it's not all that realistic. The only thing that annoys me a litte bit is how the commanders are (once again ) made look incompetent. I think it would have been better to have perfectly capable commanders all over, that occasionally makes a bad blunder, instead of having one where even the acting tells it before they start messing things up. But that's just me. The commanding issue also had some really nice touches as well though, i.e. when the viewer is led to hate the guy who denies CAS Evac for the camel boy, but later there comes a few very good explanations of why this was done. The series also explaines in fairly good details parts that are quite misunderstood in the ArmA community (online players typically). Such as the importance of teamplay, scans, and overwatch. How not every single player carries an M136 (so far only saw it brought out once in the show). How communications work and "proper" (end titles rule - nice comms going on here) phrasing; within team, other teams, and command. How night vision goggles aren't as "perfect" as they are in ArmA. I think I want a mod to bring the old ones back now, despite looking a lot worse. Guess I just want them to have less of an advantage than the noisefree uber-NVGs we have now. People complain about washouts in bright light and mod them to not have HDR effects. Sure you have a gain control, but as they show, low batteries may limit the effect, and even if turned way down will not prevent washouts. Character profiling/development and depth is really well played out. Usually in a show such as this you are given the "big plan" at the beginning for the viewer to create a sence of "progress" for himself. But not here (at least I didn't get it). Plans seem to come a bit more ad hoc and slowly reveals themselves by new warning orders and leader meetings. So far, I'll rate it 9.8/10 mostly for authenticity. I have no clue whatsoever about the real military (I conscribed (?) as combat engineer (mines and explosives), but that's it), other than from I've learned in movies. I have however, been reading a lot of field manuals over at www.globalsecurity.org since the dawn of ArmA.

I have seen the RPT log and had out of memory server crash, but wasn't sure that was the reason. Btw, when my version creates main targets in "easy mode" (due to lack of players), I really don't want there to be much armor around, maybe a bmp and a couple of brdms. This because mission is setup for "roleplay"; not everyone runs around with anti armor (not needed) and you're actually supposed to be able to complete a main target without dying if played properly (2 lives per remaining main target, pluss 6 for early joiners due to lack of overwatch). Anything else has a very low probability of appearing (floor random 1.x). However, I am having a problem that the mission doesn't always complete when we have taken out pretty much everything. I noticed in createnexttarget that one trigger created checks against number of type "tanks", and I suspect this can be the bad one for me. Is it safe to remove "tanks" from the condition, or does it serve a purpose which I fail to see? I don't know if this is possible at all, but can you monitor each paratrooper for height, when he is 1 meter above the ground, delete him and create a unit there instead (setDamage 1 if dead)? Really weird concept of doing things, and I don't know if server load will be too high (do while loops, avoid waitUntil), but at least no parachute eject will take place. Edit: I noticed that the "names" (E-4-2:3) is already used on the ejected units. I haven't checked the scripts, but how about adding them to groups (maybe you already did this) or give them proper init names, say format["unit_%1",time] or something. Are you exceeding the 144 group limit perhaps? Reason I ask is that I am running more patrols on the island, and sometimes they just get deleted in front of me while the mission is being generated. Yes, I have a marker generation, setCaptive, and teleport function for debugging purposes. Also, have you been able to figure out what is causing the MHQ markerpos jumping with the Revive version? Edit2: Also, I'm considering removing Shilkas from the island protection completely. I have witnessed so many "bugs" (others seem to report them as being bugs, but I know what is going on after inspecting area further) where you suddenly get shot down out of the sky with no seen incoming fire and nothing red on the radar. In revive version, you don't even get the chance of reviving (which actually suits me just fine, but I consider it a bug in design anyway). In my cases there has always been a Shilka around, but another fault could be lifted MHQ being too close to lift chopper i.e. if it decsends and crashes into the MHQ. Many players have reported this as a "bug" though. Just thought I'd mention it.

Found a small mistake in x_airki.sqf in waypoint generation. The line of the type <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">_pat_pos = [(_current_target_pos select 0) + (_radius / 2) + random _radius, (_current_target_pos select 1) + (_radius / 2) + random _radius,(_current_target_pos select 2)]; should read <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">_pat_pos = [(_current_target_pos select 0) - (_radius / 2) + random _radius, (_current_target_pos select 1) - (_radius / 2) + random _radius,(_current_target_pos select 2)]; May I also suggest a much bigger radius used here. It doesn't make sense (to me) that an airpatrol is performed over such a little airspace. Myself I use -4*_radius + random(8*_radius). It does make the Kamov a lot less predictable. Also, I think the airplane patrol is making players crazy. It just circles the town infinately only making a disturbing noise which (the way most people play) will never go away until it crashes. How about having only a small chance, say 20%, that this is an aircraft, and a bigger chance it is an MG equipped helicopter? Movein gunner works fine for me since I'm only doing a west capable version, but west choppers should have the secondary gunner in when east is played.