S!fkaIaC

Because BIS f... it up. If I got it right, they made mistakes so that the virtual mass of one tank was much higher then the other. But dunno if I got it right since I do not know the workaround BIS used to simulate mass. So speaking, BMP2 had an excellent takeoff weight in early versions of ArmA 1 :D

We need a movie to comment the LAV thingy. Not just pictures. If you gimme a demo I can do that for you :D

I was reading through a lot of posts in this thread, it is obvious that we all have different understanding what PvP is about. What are the characteristics? Once this is common, we could finally start to struggle. PvP missions must have IMHO: - no respawn - no AI - utilization of realistic mods like WGL/ACE If you think I am wrong, slap me.

As a wimp I can say: staying in cover works better :)

Of course it will be there, if US and maybe IDF is using VBS or similar to deal with IEDs etc Hamas will use ArmA 2 to find out how to place IEDs correctly. Gents it is a game with dual use capabilities. If someone will find it useful for his needs he will use it and finding a way to get it. And it would be a bad move by BIS not offering ArmA 2 in IL, because OFP Avon Lady would not be amused.

1.) Buying a Special edition 2.) unpacking it 3.) dumping DVD and key and enjoying poster, shirt and ammo box :D Seriously, firing up editor and testing until I fall to sleep.

Raphier, you suggesting nonsense, your squadmembers would give you headshot for such fuzzy direction + distance reports. And to spell it takes much more time, we would be bored much more. I rather support the suggestion of CarlGustaffa, the clock reference relative to the squad direction was and is crap since you need visual contact to your squad(leader) or whoever is reporting to get it right (which is very often not the case). Direction with reference to the compass is absolute and hence works always. Assuming a reporter of any object/subject is facing exactly north, 1 o'clock could be reported as well as N(orth)-(N)orth-(E)ast, 2 o'clock as N(orth)-(E)ast)-(E)ast , 3 o'clock just (E)ast e.t.c. :D :D :D So true

An225 drops BMD-->BMD rebounces on the ground-->BMD hits the AN225 that recently dropped that BMD--->AN225 goes down and smashes into a tree--->tree still stand like a super-material-mega-pole and the AN225 hangs on it in one piece and burns. Does this sound familiar? :D

I guess the difference between Lada (simple version for the east block) and Shiguli (export version) is only visible for insiders, and they are both licensed by FIAT as far as I remember (dunno if based on the same FIAT model, seems that FIAT 124 was the grandfather). And I am somehow sure that some old communist manufacturers ignoring copyrights for years will not sue BIS now. Since ArmA2 Story should be utilize "modern" equipment what about this ugly Lada? http://images.google.de/imgres?imgurl=http://forum.avtoindex.com/foto/data/media/175/lada_2170_priora_2005_2.jpg&imgrefurl=http://forum.avtoindex.com/foto/lada_2170_priora_photo_video_2267_de.html&usg=__qJLkEbFIQn1-WrFVxtX3MGIx-2I=&h=768&w=1024&sz=170&hl=de&start=1&um=1&tbnid=AjimZRCeFYmgSM:&tbnh=113&tbnw=150&prev=/images%3Fq%3Dlada%2B2170%26hl%3Dde%26client%3Dfirefox-a%26rls%3Dorg.mozilla:de:official%26sa%3DX%26um%3D1

Custom Faces were there since OFP. The method of sharing as well as limits to keep MP capabilitiy too. To avoid problems during JIP any kind of customized data like tags/faces/whatever the MP code should handle this traffic with lowest priority. Until full load of custom faces a standard face can serve as placeholder.

The main issue is that we have in ArmA 1 button assignments generic for all vehicles/weapons/units. Only granularity is that some are valid only for some vehicles/unit classes. But what we really need is a keymapping that comes with each addon and the default values are inside the addon and BIS defines a common way to make the keybinding visible and changable for each user. The changes are stored at the client with a reference to a unique ID of the addon. Keymappings should be even defined for each position in a vehicle and also for each "weapon". Example: Button "W" might be in a truck "foreward", as a soldier in normal condition "walking" as a soldier holding the weapon (addon) mixer it turns on the kitchen-aid, conflicts should not appear. But true, some functions need to be accessible in any situation like MAP or order menu. Hence a good solution is required to have fast access to common functions with a minimum of blocked keys.

??? Guess we have already a AC-130 thread.

Jorge, the thing is that BIS always had "mass", but not properly simulated. As far as I remember it was even possible to define "mass" per "section" of an vehicle. But the problem is that the flight characteristics nor any other vehicle behavior changes with its changing weight due to cargo-fuel-ammo. For example when you drop bombs the plane goes up, something that I never experienced in ArmA. If you load a truck up to its limit you should have problems to climb a hill with that. Not in ArmA. A Mi8/17 with the max amount of unguided rockets and internal fuel tanks should behave like a fat cow and improve the more rockets fired/fuel consumed - but not in ArmA.

Whatever they do, they will use parts of the currrent engine and develope it further. And on the battle deck of a carrier (space-) ship with simulated gravity they have to simulate the simulated gravity :D :D :D So if they waste time making other nonsense apart from MilSims they might be able to use their engine in 2035 to do ArmA 3.

Thanks for the clarification vectorboson. My problem is not that I think to much in physical terms, it is rather that I think only in physical terms :D It is a kind of stomach feeling that solutions like you and PhilippRauch desctibed might do the job for a "raw" simulation, but if it comes to some tiny differences which result in the end into 0% or 100%, no grey between (missed or hit), it matters how accurate a certain simulation is. Of course you do not virtually transmit waves like endless vectors of endless amount of bullets with their source in the virtual transmitter. But working with that much simplified models you described makes it almost impossible do model the sometimes huge differences between all the radar- and rocket guidance systems in the world. They would work all the same way.

Use case: Mission+addons that should support: - 2 radar wavelenghtes - IR - normal light - multiple radar sources to illuminate the target(s) Now my questions: - how you make sure with your approach that a virtual sensor for Radar wave type 2 (which should be visualised on a radar screen in an AA control vehicle) does not react on virtually transmitted waves of IR sources (fire, heat, ..) ; radar waves Type 1 and normal virtual light sources (Sun, Moon, lamp pole...)? - how you sum up the signal at sensor if the illumination of a plane received by a target tracking radar by 2 ore more radar transmitters should be simulated? - How you simulate that the Sun is transmitting in Light band and IR band, but not (at significant level above noise) at radar band(s)? - how you simulate short pulses of radar so that it can not be received by spinning dishes if they do not point to that direction? - how do you simulate reflection/deflection of all those waves by water/rocks causing noise that disturbes/blinds some sensors? Now tell me that all that is not needed, then I say without that it is not serious to model any weapon system after 1955 with that engine.

This is NOT the way. To many limitations if you do it this way. It might work in a very odd way for IR partly, but having a airport radar that should not be sensitive for waves used by target radar and visa versa, IR, light, ...in the same environment - I have doubts that it works. The sensitivity-behavior of sensors might be simplified in the solution I prefer, but for the propagation you can use more or less the same model as for visible light but with different parameters. And you need to need to create new parameters like the presence time (e.g. absolute start time + perid e.t.c) of the transmitter synced with mission time to simulate a modulated radar in sync for all clients. Also signal strength and horizontal and vertical focus should be changeable.

From methodology POV totally wrong. If you want to control an environment, you work with whitlists, not with blacklists. So only the last part applies, each client with more loaded then in the whitelist must be kicked.

The reason why I am asking for this feature is that we use in ArmA more and more hight-tech-weapons, but by the nature of the ArmA 1 engine they are very odd simulated (well, god for the time when it was coded, bad if you compare with reality). From that POV you can simulate with the ArmA 1 engine another WWII environment. Since many modern weapon characteristics are classified it is difficult to make a simple radar guided rocket anyway. Since sensor charackteristics, tracking capabilities etc are to complex and as I said, unknown, one should be very careful creating "Ãœberwaffen". Earliest HARM rockets had a hit ratio of 25% only in reality, most Flight-SIMs simulated much higher rates. But if one is serious with the attempt to simulate modern weapons, it starts with the proper simulation of waves and their reflection, deflection etc. If the propagation is correctly simulated, it is already a big deal, no radar signals anymore if the target is sharp behind a mountain e.t.c. Or your IR scanner is blinded if your target is in the middle of a burning town with lots of burning houses and burning vehicles.

I guess it even does not exist like I described in VBS2 atm.

Only if every item in ArmA 2 MUST have a parameter + value for weight it is possible to do it the right way.

According to a preview presented by Jan Prazak we can forget it for ArmA 2 engine. Obvious that they have to turn the engine upside-down to make it happen.

Rolling and rebouncing. In ArmA they sometimes glue at the wall instead of rebounce.

Let's be generic in the request: - we need a customizable sign that shows the ID of the player. - to keep the OFP/ArmA freedom it should not use alphanumeric characters, rather a 128x128 (limitation needed to avoid to hight traffic in MP) pixels sign like for the clan tag - it should be possible for addonmakes to place them everywhere on the surface of an addon - it should be possible to resize them by keeping the resolution In OFP I remember tank addons where the clan tag (from squad.xml) appeared on top of the antenna. It was the same tag that was on the other 3 places in the standard BIS model.

IF we would have REAL underground structures (e.g. tunnels and bunkers) we would as a consequence like to destroy them (of couuurssse :D ). Since dynamic terrain is not supported in ArmA 1 (dunno how it will be in ArmA2) and workarounds usually causing other side effects, I would skip this wish for ArmA 2 but making a vote for ArmA 3. It won't come before if it really requires a complete overhaul of the engine to properly support this.