frederf

I'd like to report the LHD Wasp-class has recently developed an error where light fixture, cargo computer, and possibly some other mission attachments are being placed at wrong positions. The light fixtures seem to be wrong longitudinally and laterally reversed. For example the forward island garage lights are floating rear left instead of forward right over the #1 elevator and are collidable. The computer to access the ship cargo is on the right and facing into the wall. Many objects can only be seen by clipping the free camera into the model. All heights seem to be correct. The pattern shows either lateral mirror error or a 180 heading shift from normal. Ship-based weapons, elevators, and rotating antennas are unaffected. The anchor objects are misaligned with their texture dark marks on the bow. I attempted to repair the scripts to recommend a specific edit but was unable to have an effect.

In case anyone tried, Play With 6 totally screwed up and the 0.6 version there is only a few texture files.

Is there a changelog for 1.0.5 to 1.0.5.1?

NouberNou, you're doing God's work and I love the direction you're going but here's a related but different problem I've been having with the default action... I hate where it's placed on the screen. I hate that I can be aimed down rifle sights and if someone walks within 900m of me with a backpack the WOULD YOU LIKE TO OPEN THIS BACKPACK!@?!?!?!!! comes on dead center in the screen. I see in the demo video your action icons are transitioning from 2D to 3D space and the 2D one is vanishing. That gives me hope that there is some clever way to make the 2D default action icon/text not so devastatingly obtrusive. Some code that requires a key press to show default action or to have your weapon lowered or require staring at for a small length of time or SOMETHING to counter the current disaster that is the default action UI element.

This is a general statement about "big iron" types of vehicles (MLRS, B-52, M1A1): It's too big scale for ArmA! On an island that's a few square miles at most with a small amount of players or AI it is better to have similar scale vehicles. I would be much happier with a C-27J than a C-5 for example. In the future please consider smaller scale equpiment.

This addon changes the class structure of the original BIS items. I highly recommend avoiding it! The addon replaces NVGs with "binoculars" that have NVG properties until you save/reload and you just have plain binoculars meaning no NVGs at all. Completely unusable in any persistent mission framework.

I'm pretty sure the values of min, std, max are a bound with a weighted center at std. So your values are for example 10 22 30 for min, std, max. stdLum is probably the reference value of illumination that gives the output of std for the aperture. Lesser luminations result in apertures higher or lower up to the ultimate aperture limits min and max. It's sort of a bounded auto range with a custom curve which is two gradients above and below a reference keying. I'll have to test it out.

Does this work with ArmA3 or have an ArmA3 version?

addItemToVest for magazines renders those magazines unusable for the primary weapon. This applies to all AddItemTo* commands and all magazines that I can see (hand grenades, etc.).

The FAMAS rifles and possibly others do not have the proper cargo size or mass. You can put many many many rifles into a backpack where a standard MX rifle you can fit 1-2, maybe 3-4 for the larger ones like Carryall. 100 FAMAS in a backpack with zero weight or bulk change. The STANAG wells of the various FAMASs won't accept each others magazines nor compatible magazines from existing BIS magazines. The 40mm and 57mm rifle grenades do not seem to have the proper muzzle velocity 68 and 65 m/s respectively. There exist also strictly AP, smoke, and illumination rounds of the 40mm variety. The rifle grenades appear to disappear if airborne for sufficient time as to travel beyond ~300m and never are seen to explode. The range is too great due to excessive muzzle velocity. The maximum range achievable is 320m at the ~45 degree elevation.

addItemTo* (*Uniform, vest, backpack) for magazines successfully adds magazines to the container, however the magazines are not usable by the weapon (rifle). You can even drag them to the magazine slot of the primary weapon but it reports 0 rounds and 0 magazines.

I see why this is helpful because types = {item1, item2, item3,...} can't be updated because the array is a single value. If they are separate variables then you can update the class tree without having to completely replace the single array in the single variable location.

Looking at the attachment topic from a distance I don't believe that the proposed change fully satisfies the desired behavior of the attachment system. Attachments should perform under the following scenarios: 1. Default weapons with default attachments 2. Addon weapons with default attachments 3. Default weapons with addon attachments 4. Addon weapons with addon attachments Unless I'm missing something none of the proposed or implemented solutions deal with these 4 cases simultaneously. For blind interoperability we cannot use bespoke code. A weapon addon developer and an attachment addon developer must be able to release in complete ignorance of each other and still have the result make sense. In times of complicated problems simulating reality I always ask myself "How did reality conquer the problem?" Ultimately it is overly difficult and counter productive to have an imaginative solution that is separate from reality. Of course in reality items are often produced in a strict before-after pattern where bespoke "this is for that" thinking works. However there exists independent development of items which adhere to a common standard. The previous case is a special example of the latter where the first item unwittingly created a standard for the second. The MIL-STD-1913 (Picatinny) rail is a prime example of this. I can see no practical alternative other than establishing intermediate standards with which both weapons and attachments communicate compatibility. Despite the need for standard attachment point types, there's no reason to explicitly state those standards in a new separate construct. Instead let us utilize the hierarchical class structure to create an assumed standard by example of attachment class. This should lower the variable overhead and leverage the powerful nature of class structures. The attachment point standard is defined by the parent attachment class and referenced by same. For example CfgWeapons{ Rifle { { attachment_point_type = p_rail_item }; }; }; CfgAttachments { NewItem : p_rail_item{ new code }; }; RCO_optic isTypeOf p_rail_optic isTypeOf p_rail_item Thus a new weapon addon can specify that its attachment point accepts p_rail_item and all child classes are already permitted by class structure. New weapon addons and attachment addons can now be made separately and be instantly compatible. I have anticipated a number of questions and issues so I'll pre-respond to as many as possible here: Q1. Doesn't this allow non-nonsensical item-point combinations? A1. Depends but yes. Unless the item classes are branched early into bipod, optic, flashlight, etc. then there's nothing preventing someone putting a bipod on top of their rifle where an optic would normally be. Before you panic and start devising restrictions... relax. Humans (and scripts) are the only ones messing with which item goes in what slot. No one will find an optic not in the sight axis useful so while it's physically possible it's of no real concern and isn't worth creating needless inflexibility to restrict. Q2. What about different size attachment points of the same standard? A2. Then they aren't the same standard. One would use subclasses of the standard to allow small items on a big point but not big items on a small point. p_rail_long isTypeOf p_rail for example. Q3. How does scripting know where to put attachments if they are blindly added to a multi-point weapon? A3. I don't know. There are ways it could do best guess or in a certain order. Q4. How can such permissiveness be balanced? A4. As per reality: applying dexterity penalties within the item to make SMG+sniper scope physically impractical Q5. How are exclusions possible? A5. With a separate definition of excluded attachment(s) type(s) Q6. What if several separate class branches should be permitted but not its single parent? A6. Permitted types would be a list of classes Additionally I think GL subweapons should be an attachment, perhaps with a player lock (or tool requirement?). We need more interactivity with our attachments like zeroing, removing magazines, etc. Items should have a value for attachment time (not instant). Interacting with attachments should be done in a pop up dialog and not the rigid inventory screen as current as this restricts feature growth. Paint should be an attachment. Barrels for MGs (overheating) could be exchanged thus. Jamming could require interaction at the GUI level.

What if the script compares the client vs server userconfig and takes the client values only if they match the server values?

I've just made a small internal config patch so that the bipodded R3F weapons have TMR bipods. It was a complete pain. Can TMR please have a userconfig file where a user can define additional weapons which have this feature? The requirement that the other mod authors know to include this value when making their weapon configs is too much it seems.