Related tickets:

• https://feedback.bistudio.com/T124907
• https://feedback.bistudio.com/T75961 (resolved?)
• https://feedback.bistudio.com/T79523
• https://feedback.bistudio.com/T79458

I noticed the same issue, still present in v1.98 and v2.00

Can confirm in 2.00.146773

/up-voted

Adding a fast-rope functionality shouldn't be a big problem; just attach a rope to a helicopter, attach an unit to the rope and let it slide down with a nice animation.

The same has been done before with ArmA2 + ACE.

I don't think we need fancy animations and complex systems in and around the helicopters to make it work and have fun with it.

"weird thing that should be removed, yes, but the question is why you would want more than 144 groups?"

I've played several huge Joint-Ops' where the amount of AI was too low due this bug. Most of the time 144 AI groups should be enough, but with the use of AI Improvements (like UPSMON, Headless Client, Alive Mod) you often see small groups which can work together, instead of large groups which always stay together.

Also, as gdscei noted; it also limits the amount of players to 144, when all are in seperate groups (like DayZ).

It would be nice if this number could be highered or even removed (unlimited), so the server (or HC) will determen the limit it can handle.

/up-voted

I agree that the sooner we can test this feature, the better it will be the moment A3 will hit the final release.
However I rather have a finished game without Java support, then a broken game with Java support.

The current workflow, with dev and stable versions, does allow the developers to add new content and features before releasing it. So even when A3 is final, we'll still be able to use the dev version and test new features (like Java support).

I up-voted this ticket since I fully agree with coati, however it's a minor thing and COULD-HAVE feature to see before the final release.

Confirmed.

Any idea when this is going to be fixed, since right now the DEV branch is unplayable due this bug.

I guess it's related to implementing TrackIR/OculusRift/Controller support, but I guess (until fixed) the best solution is to revert to an older version of the freelook script.

The hardware is good enough for good performance, so nothing is wrong there (I even played A3 with a 9800GT and it was perfect!)

You do might want to play with the graphical settings until it's stable (40 FPS in SP) where several smoke grenades only drop 5 FPS.

It's true that A3 still needs optimalisation, but currently all you can do is lower the settings and play smooth instead of beautiful.

The idea is that you can set the SpectatorMaxClients equal to the maximum amount of slots your server has (for rented servers that is), dedicated servers should indeed take note of the amount players connecting and the amount of bandwidth used.

At rented servers you could have a 40 slot server, but only have a 10 slot mission; so 30 slots are unused and might be used for spectating and/or administrating.

Especially for admins it might be useful to lower the mission slots by eg 5, and use them as "admin slots" (set SpectatorAdminOnly = true).

To be honest; I don't know what impact it has to the server if non-players are connected, but it should be less then playing clients.

As for the helicopter itself it shouldn't be shaking (a lot) when firing any weapon system, however the gunner camera should; especially at higher zoom levels.

This could be fixed by adding a shake effect to the camera feed with the addCamShake function (http://community.bistudio.com/wiki/addCamShake) or similar.

It's no problem for performance, but does increase realism and fun.

Please note that CLS and CMT are 2 different functions:

CLS = Combat Life Saver, an infantry team/squad member which provides first aid. Just a regular soldier with simple medical training.

CMT = Charge Medical Technician, a team member which provides medical support. Useally found at MEDEVAC vehicles (eg. helicopters). A specialized unit with medical training based on the vehicle he/she is working on.

Medic = ... just an easy name for any medical personel.

/downvoted since A3 is correct with the naming.

Not sure if Javascript is 'better' than Java, however I do agree that it's an easier and more common programming language.

I'm currently working with the JS addon and it works great, even with the current limitations and missing native support (so can't access core variables).

Native support and/or an improvement in the callExtension interface would be great !

It's indeed a bug which should be fixed; however I don't think your solution is the 'right' one.

It would be nice for missionmakers to give players the option to choose their gear based on their role, however there are already enough scripts available which can do this.

Yes the MP is stationed abroad and their task is to keep the peace at base, just like regular police does on the streets.

However I don't think ArmA 3, or at least not the core game, should have MP's walking around.

I understand it's more a "[map name here] Life" or real base simulation thing, instead of increased gameplay, so therefor I'll downvote this feature request.

I'm certain you'll find more luck with the modmakers to create this kind of stuff.

I fully support this; however please make sure the system supports versioning.

Especially for clans/communities who use custom mods/missions which are not updated instantly or are different from the original version.

Also; the clients must always have the same version as the client, which means that (especially when the server isn't updated regulary) always means that the client needs to download from the game server, instead of an older version from the external services.

Synq is already going to support this (subversioning), however the current ArmA engine doesn't (just checks if hash is correct, if not redownload, no matter which version).

As dismemberment goes with full respect to SLX mod which have great features gore part wasn't quite realistic.
We not talk about pre made model when BIS stated that dismemberment will be possible in A3 - did they said something obvious as pre made body model for it? We don't know. We know that ArmA engine
seems to doesn't like shape changing materials. What we need is dynamic body for dismemberment. While I try to think realistic that gore won't make it into final build BIS should at least laid the
foundations for it in engine to help modders with implementing it - the same to various animations.

As matter of fact, I know that BIS already has working dismemberment models (or at least a working method) on the engine since it's already a feature on VBS 2. I agree it's not 100% accurate, but it does work without any problems (compaired to the SLX mod, which by the way did a great job to simulate it).

However I still agree to add a little bit more gore and more realistic blood patterns on both the units themselfs and their surroundings.

I personally prefer dismemberment over bloodspatters (50cal headshot and only a small pool blood?) ;)

I do like the suggestion, but I can imagine it's not easy to determen the correct amount and location of the blood splatter to make it realistic enough, even though it's more realistic without it.

One note though; if added it MUST be possible to enable/disable this option at the client settings for obvious reasons.

It would be great to have a feature which can do all of the above, but the more I think about the solution, the more I feel it becomes impossible to do...

Scripting the AI won't be a big issue, as long as the buildings are "breach ready".

The way I would build this would be the following:

1. all enterable buildings will get 2 arrays (in config) with unit positions: a) 'stack locations' = left and/or right of entry point and b) 'clear locations' = locations (eg corners of rooms) where AI needs to go and clear before calling out "all clear".

2. all enterable buildings with windows or other openings will need an array with 'danger zones', so the units won't stand in front of a window with the possibility to get shot before entering.

3. the buildings will need a prefered stack side (left or right of the entry point), depending on how the door opens.

4. the buildings will need a prefered stack formation (eg. 2 left, 2 right or 4 left/right), depending on the size and space outside the structure.

5. if the building has multiple rooms and/or floors, it also needs the above information for each entry point in-door.

With all these variables added to the configs, it will be relatively easy to script the AI behavior since all they have to do is "start at point X, open door, move to point Y, clear, start at point Z, etc..."

The problem is that object makers will need to add all these variables too, and without testing it's almost impossible to see if everything works flawless.

Ofcourse, if the BIS devs or anyone else has a better/easier solution, it would be even better :D

"@Grezvany13: Not "the paper map itself", but it would simulate having a GPS with a moving map, which would be used instead of paper one, when having a GPS."

If you mean the GPS map (RCTRL + M) and not the normal map (M), then I'm fine with the suggestion.

Although in that case I suggest to make the GPS map zoomable:

• 100x100 mtr : 10-digit grid
• 1000x1000 mrt : 8-digit grid
• 10000x10000 mtr : 6-digit grid

In all cases you, the player, are at the center op the map. No direction is given (like compass) and no other interactions are available (like placing markers).
Your grid location should be placed underneath the map.

And ofcourse the GPS still has a small UI compared to the full-screen map.

I don't see how your map (a piece of paper) could have more gridlines when you pickup a GPS.

I do agree that the GPS should be able to give a 8- or even 10-digit position, but should be configurable by the mission maker.

And when you're looking at your map you can also check your GPS for an accurate position, it just requires some comon sense to figure out when your position is at the map.

I understand the code lock system, but that's a bit too much for players which do trust eachother and do ask for permission before taking something from a backpack.

The last thing I want is having my teammate die, since he has no more ammo and forgot my code...

Personally I prefer the ACE2 method:

Ruck Sharing - From the interaction menu, you can access the ruck of other
players and AI while it's still on their back. Players have to set their
sharing level (Locked, Squad, Team) using the lock button in the gear dialog
first. Squad leaders can use the Cycle Unit feature to set it for AI.

In case it's locked by default, you'll get a message that someone wants to access your ruck and you can grant or deny access. It's simple to use by both casual and hardcore players and, since it already exists, should be easy to script it in-game.

For those who play serious with friends won't need this since they can trust eachother.

However, for the sake of public players who only want to mess around; please add this simple function so that you'll need permission to access the backpack of another unit.
This, ofcourse, does not apply for dead or unconscious players.

The editor itself is very simple to use (and the A3 editor is even simpler then the A2 editor), however since it's still an alpha not all the buttons have their names and descriptions.

As for a guide; the wiki has all the information you'll need about scripting, including usage examples (which can be found at the editor too). This will be improved after the alpha.

And there are 2 huge websites (both BIS forum and Armaholic) where you can find lots of information and scripts to use and learn from.

Scripting and mission making in ArmA is easy to learn but hard to master, but some people just prefer pre-essambled IKEA furnature...

Duplicate of #369

I do agree that mission makers should use a standard format for mission naming, however what should be the standard?

For example we use:
[TAG]_HC_@40CO_Mission_name.island.pbo

This way it's easier for server admins to see:

• who made the mission?
• does it has Headless Client support? (currently in A2)
• does it require mods? (however, still unknown which one(s))
• max amount of players
• gamemode
• mission name
• island

However; still an upvote, so at least the devs (and hopefully with the community) can find a nice solution for this!

@Drekk: the issue you're refering too is not related to this feature, since this is for mission makers, not for the server browser.

According to #6799 it has been fixed in 0.54 (which isn't released yet), so that's why it's still present ;)

I think the biggest problem is that the AI are all single instances and therfor lack teamwork. The only "teamwork" you'll see is following the team/squad leader, but the moment the fire fight starts they all act solo.

Currently this can be fixed with external scripts like UPSMON, but for a perfect result you'll need either a NASA server, or make use of the Headless Client functionality.

As far as I can see now; the AI scripting is similar to ArmA2, so hopefully this will change towards the final release.

//upvoted

PS. not sure if it's a major bug with high priority...

Not sure how this is a bug, since it's normal that you lower your weapon when you check your map.

This was already a feature in ArmA2 (not sure about ArmA/OPF) and it even forced you to crouch (unless prone).

The bug about walking + reasing weapon is already addressed at issue #0000739 and is not related at all.

A simple solution would be using CTRL+R which gives a simple hint with 'empty' (0-3), 'used' (3-27) or 'full' (28-30), depending on the amount of rounds left (examples based on 30 rounds mag).

Currently the Alpha has only one 'skin' for the AH/MH-9, which is without any markings. However the final version (even even now as hidden parts) will have multiple camo's and markings for each vehicle.

sidenote: US = NATO, NATO != US

TBH I don't think, just like Lt Lyko noted, having an array with all the objects which should be deleted (which could be endless) will help mission makers to easily remove those objects.

Since the objects do have an ID and/or name, it should be possible to remove by either scripts or the following solution:

A simple variable which can be added at description.ext, eg. 'excludeObjects' with a value which defines which objects should be removed from the core island.

Possible values:

• 'all' = remove ALL objects from the island
• 'nature' = remove all trees, bushes, grass objects
• 'static' = remove all static objects (eg. buildings)
• 'ambiance' = remove all ambiance objects (eg. non static containers, litter)

... and probably more

Instead of naming the values using numbers (1, 2, 4, 8, 16, etc) to flag the group of objects would be a better idea.

This feature, even when it's a good idea, would be terrible for server hosters.

However, since we already have a global addon supplier (SixUpdater / Play with Six), this could be integrated. And since the current serverbowser can already see which mods are required, optional and available (either by server and by mission), this shouldn't be too hard to do.

Example:

• client joins a server with mods enabled
• client recieves message about missing mods (both required and optional)
• client selects the mods to download/install or cancels
• when ready, client automaticly rejoins the server

The downloads are provided by a thirdparty to offload the gameserver. In case of private mods, the files must be available and linked at a special config file (eg. server-addons.cfg)

/upvoted

However; a chopper should be able to carry a couple of units without noticing any differences in handling.

With heavy cargo (eg. Chinook with small vehicle or container) inside or under it, should change the handling.
If I'm correct this is already present at the TKOH flight model, so should apply to ArmA3 at a certain point anyway.

I now understand it but it's explained in a way that's too hard to understand.

Problem: missing animations for IDLE + Tactical Pace

Solution: add new/extra animation IDLE + Tactical Pace (both standing and crouching)

I've been reading your idea a couple of times now, and I still don't get it... or actually, I don't understand how you wrote it down.

As I would like to see it, there are 3 weapon modes:

• combat: horizontal (weapon is aiming and ready to fire)
• tactical: diagonal (weapon is ready to fire)
• rest: vertical (weapon is lowered)

and 4 movement modes:

• walking (rest + tactical + combat)
• jogging (rest + tactical + combat)
• running (rest + tactical)
• sprint (rest only)

However, as far as I know, this is already in ArmA3 and more then enough.
If I understand your images, you just want another weapon mode which is between (my) tactical and rest mode. This doesn't seem to add much to the game, except for another stance we have to remember.

// not voted, until clear how and what...

Duplicate: #0004326
Related: #0004176, #0003706, #0005875

(found by keyword 'ACRE')

The solution is perfect for required mods (eg. CBA, ACE, ACRE, etc.), however unuseable for optional mods.

At another issue (duplicate?) I gave my idea about a workable solution:

Example:

• client joins a server with mods enabled
• client recieves message about missing mods (both required and optional)
• client selects the mods to download/install or cancels
• when ready, client automaticly rejoins the server The downloads are provided by a thirdparty to offload the gameserver. In case of private mods, the files must be available and linked at a special config file (eg. server-addons.cfg)

http://feedback.arma3.com/view.php?id=6740#c18550

I downvoted this feature request, since most weapon system are fixed and need to be aimed by moving the whole helicopter (or airplane for that matter).

Some attack helicopters do have turnable weapon systems, but those are manned by a gunner or co-pilot.

If I recall correctly this was already confirmed; the helmet will have multiple attachment slots and several items to place there (camera, flashlight, etc.)

In case this is/was rejected in the meantime.. add it again ;)

@Fuse; currently it's not a feature, but a bug...

See this issue: http://feedback.arma3.com/view.php?id=6010

The biggest problem is when you rebind your keys for flying with LCTRL (in most cases to 'decrease collective') which is also the Stance key, you won't be able fly normally anymore...

I do support this feature, but does require some other fixes/changes before it works. (eg. ability to rebind ALL keys, no more input locks, etc.)

To be honest; I don't think people are waiting for a car simulator and just want to drive away with their automatic.

However, to solve the 'steep hill' problem, why not add a high/low-ratio gearbox?

This will give the driver the choice to drive at high speeds (high ratio), or climb steep hills without dropping dead (low ratio). With a simple button or key-combination this could be changed by the driver, but only when the speed is below 20km/h (otherwise it would break the gearbox).

At the high-ratio setting you'll have a top-speed of (eg.) 100km/h, but can't climb steep hills unless you have a momentum already.

At the low-ratio setting you'll have a top-speed of (eg.) 60km/h, but you'll be able to climb steep hills even from a stand still.

// not voted, since I don't support the OP solution. However it's a feature that could be addressed.

The problem is that the hitboxes of rocks aren't exactly the same as how they look. Therfor you can have a clear shot (from the barrel), but since the hitbox is bigger you will still hit the rocks.

It's a problem that already existed in ArmA2 and hopefully they manage to fix it in ArmA3.
Not sure if it's a major and urgent issue, but it would be nice if fixed.

"I would like a feature where I could compile mission files into a .PBO with an 'Addons' folder inside of it."

This would be nice for small addons (like custom items), but will be terrible if players need to download a mission file of 1GB because you included a lot of stuff.

"Another solution would be a way for ArmA 3 to connect to an addon-hosting website, where the game asks 'This mod requires addons, would you like to download?'"

It's a nice solution, however it should be by default anyway ;) When you want to join a server it should check the required mods and download them if accepted.
However, this does require another change: set required and option mods (for server, mods and missions).

Our best solution now will be Play withSIX, which checks the server before joining and notifies you if you're missing mods.

@nsKb; my solution doesn't only add more hitpoints, but balances it by lowering the amount of hitpoints at the base unit.

Even VBS uses hitpoints, just like any other game or simulator, so how should ArmA3 do it different?

The only solution possible in a game/simulator, and possible in ArmA, is by defining hitpoints to sections of a unit and it's armor.

To make it more realistic (like the VBS video) it also should have a variable which states the amount of damage (= lowering hitpoints) done by certain projectiles (bullets, explosives, shrapnel, etc).
However, this is a 'COULD HAVE' instead of a 'MUST HAVE'.

The current hitmodel in ArmA3 is based on ArmA2; there are several hitboxes with a fixed amount of hitpoints, based on the unit (eg. medic has less hitpoints then grenadier).

This should stay the same, however the extra gear (clothing, armor, etc.) should add more hitpoints to a certain area.

The current damage model of the weapons already uses this hitmodel to define the amount of damage inflicted to the target. Besides that, it's already aware of the velocity of the round, so no changes are needed here.

Solution: lower the amount of hitpoints at the base unit, add hitpoints to the several clothing and armor pieces and balance the inflicted damage done by the weapons.

@Zonr_0; actually, the AI knows exactly where to walk, since the boundingbox around the chopper is big enough to not walk past the tail rotor.

In A2 + ACE I've never seen an AI get killed by a tail rotor, unless I was flying backwards into them (and even then they try to go prone or run away).

I suggest to wait till the new flight model is implemented.

/not voted, but monitoring

I'm personaly a big fan of ST_HUD, since it gives you the missing surrounding awareness you would have in real life. Eg. when you have 10 people walking around you, you have no idea who's friendly, who's in your squad and who's in your team.

Especially when you play without nametags and without third person, it's impossible to track every movement of your team/squad.

However I do think that it's not the job of BIS to implement this and it should be done by modmakers (like dslyecxi), unless BIS manages to implement this in a more realistic way.

Its "minor" bugs like theese that ruin the simulator experience, especially considdering how much effort is being put into RS weapon simulation, bullet trajectories and ballistics calcualtions.
What is the point if the hit-zones are off?

It's an Alpha/Beta like this so we can detect and report bugs like these, so the devs can fix them before the final game releases ;)

I'm with LoneWulf here and patient enough to wait till the full game before really start complaining.

@octavian: keep up the good work of posting these bugs, it will help the devs making a better game :D

You do know that we already get Altis, which is 10x bigger then Stratis ;)

Not to mention all the community build islands which certainly will be created.

Related issue: 2189

However; this is only about the effects of wind (and other weather effects), while the other request was more about ACE features in general. (And closed due the general description)

I'm not going to upvote this because we will have ACE(3) with all the nice features including more realistic balistics.

ArmA3 should be fun for both hardcore and casual players, and I think that having these features would scare off the casual players even more.

just my 2 cents...

Sorry to say; but how is this urgent and related to game crashes?

And if I recall correctly these glitches have been reported already, so I suggest you search the tracker and upvote the issues which are the same...

Already upvoted, but just to show the devs that I care ;)

I love the screens since it really will make camo useful. Currently enemies (and friendlies) are spotted too easy since the background is too dull. With this implemented you really need to look twice to identify a camouflaged unit from the surface he's walking on.

Hopefully we'll able to see this at the Beta!

/upvoted so the devs will notice :D

I really love the idea and the method is simple enough to build in without any major engine changes.

I agree it would help mission makers to have a wider choice of objectives, however I don't think this should be a part of the Alpha.

The Alpha is mainly to find, identify and fix game breaking bugs and give feedback on the current content available.

As for the items themselfs; I think these should be added at the Beta release, while mission makers now can either use the currently available items or create a simple mod which include the items required.

I'm not voting since I'm not against the request, but neither think it's an important issue which should be addressed before the Beta release.

It's not the recoil (or actually muzzle climb); which feels O.K.

The problem, which I share with the OP, is that it feels like it's impossible to compensate by moving down your mouse.

We all agree that the current muzzle climb is correct (except for some CoD kids), and we all know you will never be able to return to the exact same state as before a shot. However, at this time it's nearly impossible to compensate the muzzle drift since since the mouse seems unresponsive during firing a weapon.

eg. I played a lot of Battlefield 3 and learned how to compensate for the muzzle climb, which resulted in almost perfect aim. This is can be done with Muscle Memory [http://en.wikipedia.org/wiki/Muscle_memory] training.

I think the real issue is that the muzzle climb (aka recoil) blocks the mouse movement for a couple of ms.
Haven't really tested it yet, but at this time this seems to be the problem, at least at my side.

The solution is actually very simple and it works exactly the same way as the current system in ArmA2.

1. create a unit/vehicle model
2. add (named?) hiddenTextures to the model to position the patches

3a) core; apply textures and show it ingame (from squad.xml)
3b) script; apply textures and show it ingame (with setObjectTexture)

4. share texture(s) with all clients

Both the client and server impact are minimal. It only requires you to download all the images (unless it's part of a mod / inside mission file).
By limiting the filesize (.paa files are already small) it's possible to do this without any problems, even with slower internet connections.

Should be combined with squad.xml instead of in-game settings, to make it more dynamic for clan usage (like rank patch etc.)

See #0003882 for squad.xml improvement.

ArmA3 (and other games based on the VR engine) are designed to be as open as possible so people like you and me can modify the game at our likings.

This has never been a problem and in all the years I played these games I've never any script-kiddies (since they're not hackers...) until the great success of DayZ, which introduced the engine to arcade players (and therfor script-kiddies).

If you want a "hack-free" game, buy something less open, without mod-support and without community created content, since that's the only way to slow down the so-called hackers...

/up-voted

Adding a fast-rope functionality shouldn't be a big problem; just attach a rope to a helicopter, attach an unit to the rope and let it slide down with a nice animation.

The same has been done before with ArmA2 + ACE.

I don't think we need fancy animations and complex systems in and around the helicopters to make it work and have fun with it.

I agree, both for the lefthanded players and for realism where soldiers are required to shoot with their other hand in cases of an emergency or for tactical advantages.

I'm not sure how the current hitboxes are working and if it can detect if your left or right arm is hit, but it might be usefull to switch to your left hand in case your right hand is wounded.

As for the logos; the units could have multiple hidden textures, which enables us to either add textures ourselfs, or automaticly by the engine. Same applies for nickname (like nametag on chest) and clan/squad rank images.

Please not that if you had PiP at vehicles when not inside it; the game would need to render (at least) 2 different images per vehicle at the map!!!

So when you walk by a car park with 10 cars, your computer needs to render (10 * 2) + 1 different views. And based on the current impact that some people get due PiP, it would crash most computers unless they're build by NASA...

Even though you won't be executed if you use wrong radio communications, it would be nice if it's as realistic as possible for a game / mil-sim like ArmA.

I support this idea! If you messed something up, you should be able to start the game with default settings (eg. graphical settings LOW, all expansions/mods disabled and -showScriptErrors enabled).

It should also have a -safeMode parameter to do it manually.

@SGTIce; it's about a safe mode for the application itself, just like you can run Windows in safe mode so it doesn't load all the extra drivers, doesn't start the autostart applications and enables you to enable/disable settings which normally are locked.

Not that I have the problem; but it also applies to other 'non-US' layouts.

And although it's not really a bug, I do think it would be a nice gesture to have several presets for different keyboard layouts.

/upvoted

In yesterday's DEV build release this issue has been solved.

Now you can shoot while running (non-tactical pace!!) but you don't hit where
you are aiming, you basically fire to the ground (where your weapon is facing
while running / jogging).

I think it's a good solution

I would prefer another solution; when you're running or sprinting and press the fire button, you character should fall back to the tactical pace and stay there until you start running again. This also works for crouching, so should be easy to code.

The bug actually was that you could fire your weapon, but it would stop the run/sprint animation and when you stopped firing it would (try to) continue to run/sprint again which looked ackward.

Snakes should show up at thermal, since they can get hot enough.

The fact that they are cold blooded only indicates that they can't regulate their temperature by itself and need external heat sources to warm up.

The last time I checked was Stratis is south of Greece and relatively warm, therfor the snakes (even in-game) should be warm unless it's night or very clouded (colder temperatures) and at that time they shouldn't be crawling around.

sources: http://en.wikipedia.org/wiki/Snake & http://en.wikipedia.org/wiki/Ectotherm

Please note that this problem is related to UDP flooding, which in most cases can't be disabled at ISP provided modems (which are usually Thomsom routers...)

My testcase:

• I have a Thomson tg789vn (from KPN, a Dutch ISP), and can't modify UDP flooding or other security settings
• I do not have an additional firewall (is disabled to test)
• checked with both UPnP on and off
• checked with both portforwarding enabled and disabled

When I host a server; nobody can join. Either with 'ping 2500', or just 'Connection Failed'.

When somebody else hosts the server (even dedicated); I can join when their firewall is disabled and UDP flooding is disabled, otherwise I can't join even when others can.

This problem is also present in ArmA2 (and I've seen the same problem with OPF, ArmA and TOH).

It's not an VR bug, but a case of crappy routers and their security measures...

To be honest I'm not sure if I should vote up or down... So I won't vote at all...

This because I don't think that you should be able to customize units from within the editor. The reason is that if you use addons which change the Gear UI (like ACE did in ArmA2) you'll get problems when in-game due the differences.

Also, like in the past, not all mods follow the "rules" for adding new content, which might cause problems in your mission.
It would require to much coding rules and extra lines of code to even create a simple addon, while currently it's a little bit more forgiving.

I therefor suggest to stick with the current methods with loadout scripts, which never failed before and are usually more versatile then the default scripts. Not to mention; it's not that hard too use ;)

Actually, I played the missions last night (after the latest update) and it still applies.

According to the scripts the PiP screens (including mirrors, monitors and LiveFeed) are fixed at 30FPS, or actually 0.3 frames per tick.

However if your graphical settings are too high, or your hardware not up to par, you won't hit the 0.3 f/t and it will slow down badly; resulting in extreme low FPS and laggy images.

It does seem that the PiP scripting is good enough to not slow down your overall FPS (just a little), so it might need some tweaking to fix this issue for specific hardware configurations.
For example; I have no problems at all with PiP, even with a medium setup.

Indeed minor, but a MUST HAVE for the final release ;)