frankfranconi

Reviving an old thread, but only because I found a solution that I think other people searching for this might appreciate. If you look into Arma 3\Addons\functions_f.pbo, you'll find a file paramRevive.inc. It contains all parameters for the revive system and you can simply copy those that you want to have inside your mission and add them to your description.ext. For example, if you only want to select what items are required for a revive, you do something like this: class Params { class ReviveRequiredItems { title = $STR_A3_RequiredItems; isGlobal = 1; values[] = { -100, 0, 1, 2 }; texts[] = { $STR_A3_MissionDefault, $STR_A3_None, $STR_A3_Medikit, $STR_A3_FirstAidKitOrMedikit }; default = -100; function = "bis_fnc_paramReviveRequiredItems"; }; }; Because it uses only strings from the game, it will display them in the player's language, which is nice. I tested this on a dedicated server and it seems to be working well.

@St4hu As far as I know that's because another script already defines these classes for its user interface. Not sure if it's the best way to do it, but I solved that problem once by simply renaming all occurrences of the class name in the script I added to the mission (e.g. RscTitles -> RscTitlesCHSA). Of course you'll likely need to do that for more classes than just the one you mentioned, it's a bit tedious.

That's a +1 right here, it's so well done it's easily my favorite thing about the mission. There's really nothing like it and I've been excited about it ever since it was first shown. I would love to integrate it into a couple of missions and I've already taken a (very short) look under the hood to see if it would be possible to break it out, but in that time I haven't figured out what exactly would be needed to have it work in a separate mission. But since the whole framework is pretty modular and more documentation is coming eventually, I'm confident we're going to see this at some point.

Nice work! Really glad to see this.

@PistFlyBoy Thank you. I did actually see it being partially discussed, including the proposed mod. I brought it up again because oukej has said something about a possible adjustment of the camera position/initial FOV, but we haven't heard anything since. That's what worries me, because the issue is so blatantly gamebreaking and a mod is not a solution.

I personally think that the third person camera is pretty good now and not too hard to get used to. Props to oukej for the quick fix. But what concerns me is the perspective you get when flying in first person. In the XH-9 family of helicopters it's as if the pilot was pressing his face at the windshield. You can't see a single thing on the dashboard, because it's outside of your field of view. Thanks to the generally clear windshield, there's at least still pretty good visibility, but this can't be right, can it? The Orca now has the opposite problem. Here we seem to be almost cowering behind the dashboard, with it taking up the bottom third of what we see. Because you can barely see what's in front of you, it's almost impossible to land nicely without using 3rd person perspective. I would love to get a comment on this, because to me this is the most obvious problem with helicopters and I remember it used to be better.

I tend to agree with you on the DAGRs. While the fact that they are almost equivalent to the Scalpel and Macer in terms of range is offset somewhat by their reduced effectiveness on hard targets, it also makes up for that by the huge amount of DAGRs that you can stuff in a single pod, compared to the 3-4 Scalpels you can carry on one hardpoint. And you're of course right about the view distance. I find that it has become much harder to engage ground targets with IR guided missiles from the air with the sensor overhaul (which is a good thing, don't get me wrong). This is due to the requirement for vehicles to actually be hot and the increased delay until the sensors pick it up. But while it is technically accurate and desirable for sensors to take a while to detect a target signature, I think it's problematic that (with the exception of radar) this is reliant on the player's object view distance. I have my view distance on 10'000 and the object view distance on 2300, which has been a good balance for me. But now, attacking a vehicle with a jet and Macers for example has become almost impossible, even in ideal conditions. The main problem is that the IR sensors only get a chance to see the vehicle once it is within my object view distance of 2300. After that, they take a while to detect the target. But since the jet itself is quite fast (of course I could fly slower, but that's more dangerous), I'm way too close to the target, basically above it, before I can even lock on. In effect, this often forces me to fly circles around targets and do slow and dangerous low passes to lock and fire in time, which is definitely not a good experience. I could probably raise object view distance a bit at an acceptable cost of FPS, but I think we can agree that an object view distance of 6000 is not realistic for most players. But yeah, I'd be interested to hear what others are using.

Couldn't agree more. If there was at least a basic, common codebase that everybody would commit fixes to and that could easily be extended to suit the tastes of different communities without tightly coupling those additional features with the rest of the code, development would be considerably faster. I understand that what Benny currently has on his GitHub is going in that direction, but from what I've heard in this thread it's not ideal because he's had to rip out a lot of OFPS stuff, which has introduced new issues.

I agree, most people would likely be more than happy with this. That being said, I love that we have dynamic loadouts now, even if it's just in the editor.

Since you've already tried both ways, I don't think I can help you much. But what I can tell you, is that the "weird" file structure is certainly wrong. The idea is to have the @Mod folder as the root directory of the mod, containing a folder named addons which has a lot of *.pbo files in it.

Silly me, I figured it out. It really was the -mod parameter. Putting everything into quotations solved it, now all mods are loaded. ./arma3server -name=server -config=server.cfg -mod="@CBA_A3;@cup_weapons;@cup_units;@cup_vehicles"

I just realized that the log only shows the first mod, CBA_A3 in the list of loaded mods. Maybe something's wrong with my startup script that makes only the first mod from my -mod parameter list load. #!/bin/bash cd "Steam/steamapps/common/Arma 3 Server" ./arma3server -name=server -config=server.cfg -mod=@CBA_A3;@cup_weapons;@cup_units;@cup_vehicles Since I've mostly been playing missions only requiring one mod at a time, that's probably why I haven't noticed until now.

Ok, so apparently the Linux server doesn't create RPT files but instead just prints everything to stdout and stderr. So here's what I got: http://pastebin.com/wQMr1SJ1 This is everything from the server starting, to me connecting, logging in, selecting the mission and getting the error.

I know that gaps are best avoided if you want something to run anywhere, so I made sure not to have any and renamed the modfolders. You can see how I named them from the -mod parameter I'm using. -mod=@CBA_A3;@cup_weapons;@cup_units;@cup_vehicles I'll go and grab the RPT quickly.

Yes I am using Linux, but I don't think this limit is the cause. I don't have any mods loaded besides CBA_A3, CUP weapons, units and vehicles. Also I would hope that reaching the PBO limit would at least throw some kind of mildly useful error message, but I haven't seen anything of the sort.