PhilippRauch

Well, now that the chinese got the plans for the F-35, it will be cheaper to buy them from them i guess... :D

If we can map any and endless (joystick)keys to actions, scripts and variables that would be nice. I have several sticks with like 32 buttons and 8 rotary and whatnot... especially if i use a HOTAS setup there would be loads of possible switches and buttons and dials to attach to some functions. i.e. I mean that addonmakers can add their "actions" (or GlobalVariables etc) to the games keymap menu, where the player then can set his joystick buttons or keyboard or... as he likes. for example: I write some in my config like CfgUserInput or CfgHID or so... class NewKeyMapMenuEntry {    idp = 34 // position in Keymap list.    isRemappable = 0; // if so user can change it to own inside game    isKeyboard = 0; // for creating listentry    isJoystick = 1;    isWheel = 0;    isPedal = 0;    isAnalog = 0; // for sliders and dials or throttles    isInputControl[] = "Button";     // or "Rotary", "Dial", "Switch", "CoolieHatMouse",  depending on what type inputcontrol we want it to be    HIDid = 32; // to set the DIK or HID id or such if  "isRemappable = 0"    entryName = "Firebutton - SuperAddon";  // name appearing in list    actions[] = {["this"] spawn Keychecksrc; VIG_keycheckFireBx32 = true}; // well what happens on keypress etc       // if analog = 1 "this" will contain the momentary state of the dial/throttle i.e. 10%, 55% etc.. }; Which will give a entry under options/keysettings like: Firebutton - SuperAddon  [JoyButton_32] the [JoyButton_#] is made up from the isJoystick,isInputControl,HIDid If you have isRemappable = 1 then it would be Firebutton - SuperAddon  [JoyButton_XXXXXXXX] with XXXXXXXX you new attached key. (HID id or such) how about something like that? i know it could be done via armalib with its pipes and an external keymapper, but that would be just a workaround

Yeah, or something like that... but my idea shouldnt be a problem with LAN games, where i really would like that... why is sharing that data a problem? All objects are 3d data and if so, lets have the ability to create "clan-head"packs/modfolders, where you can put your clanmembers 'heads' serversided into and all get their goons head... I just liked the idea ... i know its a bit far fetched... thats how it is with dreams... :)

I think most work will be spent on gameplay this time i.e. nice storyline, proper campaign and such things that keep a game interesting... walking and shooting from/inside vehicles ... maybe but i rather guess it will be up to the community to do such things, thats ok for me. Look at what the community did already... NO gamepublisher nor producer could create THAT much HIGH quality content than this community did, even down to altering engine behaviours (somehow). I really believe that they put most effort into bugsquashing and aforementioned gameplay stuff than in little 'gimmicks' ... honestly ... in the beginning we will be much more taken in by the whole situation and HUGE terrain with procedural plants and being keen on exploring the new engine possibilities than shooting from a vehicle, i mean you can do that already, just not with your personal weapon... very minute detail for me ...

Well, i aint buying FP:DR but i might rent it at the local videorental store for 'testing' ;) ...

Well, i aint buying FP:DR but i might rent it at the local videorental store for 'testing' ;) ...

Where is the limitation exactly? No 'REAL' IR beams being used? For what? It just needs to handle/look and more importantely 'feel' like its viewed through some IR system.. sure it would be nice to have some influence of enginestate (heat generated) on the textures and such but then we will also need ammbient temperature, which we just dont have in a/this game right now, hell who cares, if i can use it and have the same advantage and shortcomings of actual fielded IR equipment then its all right for me. There is just no point in using up resources for raytracing from IR all the way up to UV or Microwaves or ... hell lets do some gamma ray raytracing or quarks... :p ! You can already program all kinds of different behaviours/systems like sensors and such inside ArmA1 it all depends on your abilities and phantasy! And funky Radar systems are already done and can even be improved, so lets start the work! But they just dont use rays or anything like that since its NOT NECESSARY! The gameengine has all the data we need, no need for tracing gazillions of rays of IR and microwaves... What needs to be done are interfaces/scripts that interpret the data to some 'edible' or usable format like a radarscreen or some warhead... all has been done in ArmA and even in OFP (Like RWR, tracking missiles)! And i am not talking about the 'radar' included in the vanilla arma... To clarify my point further: There is simply NO use or advantage in using raytracing for such things since they can be had at a lesser CPU cost already and with some clever use of engine abilities even more so.

In one video i even saw the player move into the Huey on standby on deck... so should be possible...

Well, according to some interviews BIS said they dropped dx11 because it had no significant advantage over dx10 and a smaller userbase (which was a good decision, now i ONLY ;) need to upgrade MB and CPU *g). And reflections are ingame (ArmA 2 !) , just check the developers blog and the entry with/about the new armoury, there you can see the unit being reflected in a pond of water while doing a crosscountry course or so...

for Radar check SPON Radar or some of the stuff in mandos missile suite... nice implementation of radar, and since the engine ALWAYS knows where any object/vehicle/unit is at, there is no problem 'simulating' different kinds of radar systems (2d or 3d radar systems are already possible)...

if this principle works better in large multiplayer settings than ragdoll does right now, that would be quite awesome, i like the fluidity... But couldnt this principle be already implemented in ArmA? Like checking the motion vectors and adding those animations as needed? For this there would be only:rolleyes: some more intermediate animations needed? Just my guess... not that it will be the same system, but somehow using its basic principles of 'animation estimation'??

:) I think i read somewhere that they dropped physix support, so i 'assumed' it was in there at some point in development... But i am good with anything they will put in that package which i will pre-order i a few days anyway... :D

Yeah, i can second that, but do we need a 'Simulation' or is just haveing the proper 'feel' of it ingame? Thats what i mean with workarounds/emulation... Many Values are simply not available to public, which doesnt mean they are classified, just subscribe to Janes if you got the xxxx$ and you will have most non-classified data right away. But do we need proper 'scientific' simulation inside a gameengine?? I dont think so, the difference in faking and feeling it and 'proper' scientific representation wont be really noticable anyway, if you look at the values/numbers... sure you will see a difference but we wanna play not write nice articles with big statistics and other numbergames, or do we? I really, REALLY would love to have a more 'proper' inbuild IR for sure, NVS i like already, but for example my Javelin addon is just using whats inside the engine and fakes 'proper' behaviour, like the missile is using some scripts that guide it to that target which position is always known by the engine, which the real javelin missile simply cannot, the RL Javelin uses a intricate visual comparing 'thingsystem' which will keep it locked on selected target... i just fake that behaviour inside my scripts to make it handle/feel/look like the RL would behave/do/fly ... if we would go for 'proper' scientific simulation of something soo complicated as rays and behaviour of wavelenghts then we would need supercomputerclusters for simply doing a CTF game!? I would rather have some kind of 'layer' system for textures, where with some globalvariable 'IRON=true' will switch all non_ir textures simply off or set their alpha to 0 so only the IR textures will be shown, additionally some changes to the lighting engine/shaders (like the green for NVS) and we should have nice 'representation' of 'proper' IR systems... or something like that... :)

Thats what i meant... but i sureley wouldnt mind if its possible/included in ArmA2 or ArmAx ... :D Proper simulation of wavelenghts is a different beast than creating a nice battlefield game/sim... in a game it would be anyway some kind of workaround/emulation and hence many hardcore simmers wouldnt be happy either, so i would rather have more units, worlds and missions in my game than that, but again if would be easy to implement than im all for it!

Search for Vectorbosons drop/particle tutorials... and read/search in biki for drop and particle you will find the corresponding entries for those commands responsible for smoke or any other particle effect: drop and vehicle class #particlesource there are also some templates contained in biki

YEAH and let the new female models serve some icecold drinks inflight... (geeesh, i already thought of a nude mod ... damnit..)

But maybe CM pays better admoney ... ;) But anyway thanks and big kudos to Deadfast, you are on my YT subscription list now and i recommend all to do same, this way he gets even more attention to his channel! Lets help BIS with some viral marketing shall we? :D

LOL yeah, i hope i dont but in the end i will just to get better framerates/viewdistance ... ;) But then i will check if my addons and my other favourite mods still work the same as in ArmA1... and then very likely to fix em asap...

Since Codemasters has bigger marketing budget and as such a bigger first influence/impact on (potential) buyers mindset/information IMHO it was very important for BIS to set things straight right away. POTS is somehow right, but that is also the reason why BIS did react so directly and decisive to Codemasters claims that FP:DR is the successor of OFP, which it clearly isnt... so even calling it OFP2 isnt really correct... its FP:DR by all means...

Since Codemasters has bigger marketing budget and as such a bigger first influence/impact on (potential) buyers mindset/information IMHO it was very important for BIS to set things straight right away. POTS is somehow right, but that is also the reason why BIS did react so directly and decisive to Codemasters claims that FP:DR is the successor of OFP, which it clearly isnt... so even calling it OFP2 isnt really correct... its FP:DR by all means...

Somehow nice but i think thats reserved for serious games, aka VBS...

Yeah, somehow too bad they got rid of PhysiX support in ArmA2, especially since you dont need a specialized card for it anymore...

LOL ... but whats inside? I mean is it filled or solid bacon?

YEAH, play from the viewpoint of an animal, yeeha!

I mean, if its for submarines, haveing some 'holomap desk' could be quite 'cool' although i know little about naval stuff, even though i loved to play dangerous waters and my granddad was in the trading navy... :rolleyes: http://www.flashpoint1985.com/cgi-bin/ikonboard311/ikonboard.cgi?act=ST;f=70;t=76596 is the link to old bis forum thread with it... maybe thats something... at least for the newer 'high-tec' subs out there, otherwise maybe the system of spon radar (converted to spon sonar) could be nice inside a subs bridge..