wamingo

My problem with your idea is that if you wanted to deselect something you had just selected then a doubletap could mess things up. Perhaps better then to have a hold-key. ie hold it for say 0.5 seconds. But frankly I think the best suggestion yet is this one: http://dev-heaven.net/issues/11240 in brief: shift + F1 = Red F2 = Blue F3 = Green F4 = Yellow F5 = White This way you don't have to find a particular colored unit to get the whole team with shift. A downside to this idea is you have to remember them if a legend isn't displayed. hold shift = display legend? edit: whaddya know, kju suggested an excellent improvement to the above here: http://dev-heaven.net/issues/17501 *voted*

It has been probably 8+ years since a gear or loadout menu was first suggested and it has been asked for, ever since. Is it time? Here's what I think it could look like... This is just one possibility! Better ones probably exist. Feel free to change/add to the image. Class names in this mockup are inaccurate. The main reason for this style (over eg the ingame gear menu) is it's universal - meaning it would work for any type of unit: infantry, vehicle, ammo crate, etc. Are you sceptical? 1. Automatic indexing of available gear BIS item class names can be found on assorted wonderful sites like ofpec, armaholic, some of them even on the biki. But what about mods? Needing lists from all over is a bother. A loadout editor could (should) most probably be able to index it it all for you, and be able to tell you exactly what magazines fits where. 2. Streamlining = Polish Polish is what sells games and it is also what will make people use the editor. An addition such as the loadout editor could help a lot of people do something very basic that probably ought to be easy and intuitive. discuss

CIT request for mp-folders: http://dev-heaven.net/issues/6258 got a fair few votes already

The one You mentioned probably shouldn't be though, heh! You are right that many animations are indeed blended wonderfully, but some remain, and some of them are major culprits in the clunkiness of control and some in silly looks. here's some I've found: - Stance-Changes before movement and dying. eg Crouch->Stand and vice versa force you to wait for eons for the animations to finish. - Secondary weapon switch makes you unable to move. - Pistol switch makes you unable to move and isn't interrupted by death. - Binocular switch - same as Pistol switch. - Lower/raise weapon - same as Stance-Changes. I actually wrote these down a while ago as I wanted to start a suggestion or CIT-topic for a long time. But felt like I needed a more complete list.

If I understand you correctly then I think I disagree -- except on the lack of documentation - can never have enough of that :) 1. If init.sqf was executed before objects were created, it could not be used to access them. That could be very bad - or it would severely limit init.sqf's functionality. For instance tasks could not be assigned to objects that doesn't exist. 2. Init-lines are part of object's creation and can be completely instrumental to scripts outside of it. take: this setPos [blah,blah,blah] If that isn't executed first, init.sqf will have no clue where it will be, should it need to, for example, place a marker on that location. 3. In multiplayer environments you shouldn't initialize a variable that has already been transmitted to you - or you risk overwriting it, which is bad. That's why you typically check if public variables are already initialized - eg: if (isnil "myPublicVar") then {myPublicVar = whatever} And to avoid serious injury with other bits, like tasks or similar, it can help putting at/near the top of the init.sqf, something like: if (!isServer) then { waitUntil {!isNull player}; }; So, well, I think you can rely on it. With the exception of non-preprocessed scripts, objects and their init-lines are always fully created before init.sqf runs, I'm fairly sure. I grant you it isn't "simple". But I think the real solution you're looking for is indeed documentation -- or templates/examples delivered by BIS. Perhaps with a good deal of comments in them. On the last part, I agree. Accessing an uninitialized variable should create an error. sorry about wall of text...

I'm convinced that no greater, straight-forward, single upgrade could be made to arma than to make the appropriate animations interruptable/blendable. It might seem like a small thing, but quality is found in the details. When we were given reload while moving, people cheered. And people will cheer again, I think, when given stance-to-stance-change interruption and stance-to-movement blending, to name a few. The PVP crowd might be especially appreciative. Now, it probably won't quadrouble the number of players! But whatever might achieve that, probably won't be straight forward.

There's a CIT request for a query cargo that you can vote on here: http://dev-heaven.net/issues/2109 Personally I think BIS should combine the Cargo and non-Cargo commands, making them universal -- instead of having a set of add/remove magazine/weapon commands for each type of container. For example: addMagazine would work for both soldiers, backpacks, crates, vehicles, turrets, and you name it. so to add magazines to some soldier's backpack: addMagazine unitBackpack unit "30Rnd_556x45_Stanag" Of course commands like clearMagazineCargo also becomes something like: removeAllMagazines unitBackpack unit It's longer to type, but it's still a lot more sensible in my opinion. I wrote a related thing in the comments here: http://dev-heaven.net/issues/5364 Although that was to improve the commands to take arrays. And best of all, it could be backward compatible with little fuss. Of course it's 1 in a million that something like this happens, but hey... you can dream right? :)

Preeety sure a Z coordinate would be wise too, otherwise it has to calculate how high up it should be, based on terrain - at least it sounds like an expensive operation to me? Being able to save it to an array in an sqf that you could call or something like that sounds sensible to me. Then you could also edit it afterwards. imo the generator is too slow to be usable beyond more than a few houses.

You're asking for the wrong thing, I think. These are not engine related really. Bugs can be of course, but it's not really what you're talking about here. You're talking about general frustrations about the game which are things like: Slow gameplay, clunky controls, too much travel time and high death penalty. Those are at least some of the key factors I think. But the latter ones are mission design specific for the most part. And MP maps are probably very difficult make truely fun -- how to improve on them really needs its own topic. The clunky controls could definitely be improved however. But again, I'm not sure it's the engine code that needs to be touched much. Either way we need more animation-blending, allowing especially stance changes to be interruptable, and perhaps also the ability to shoot more easily while moving. I think this area is a critical factor in peoples frustrations over the game.

How is BIS managing to change the normal standing recoil? Isn't that tied to an animation too? I would have thought they had some control over how much the weapon is swaying, but even if nothing can be done in realtime, ie some basic inverse kinematic control over particular joints (the hands/gun point), it should be possible to edit the animation directly in the same fashion. Although it may be motioncap, it can easily have been exaggerated - like acting often is. I don't think it's a major issue to do something about it, it's probably more a case of BIS being too busy with whatever they're doing to have everything perfectly polished and accurate.

A consistent crash every 10 to 30 minutes could easily sound like heat problems.

If you want pop on groups you can try deletevehicle on a random number ie a trigger: condition: isServer && random 9 < 5 onact: {deleteVehicle _x} foreach units group man1 That'll delete every unit of the group which man1 is in at 50% chance. I think that should work?

Now that we're brainstorming... Modules could have their individual UI's with fields corresponding to at least their most important parameters?

Spork using any addons/islands anything?

"Not worth it" ? Compared to what? Since forever have some people been kicking and screaming: Don't do this! don't do that! BIS have better things to worry about! - Typically wanting BIS to prioritise simulator-related stuff like AI and Damage Models and such. If you're part of this crowd, then I believe you are a part of a tiny, albeit loud, minority. The overwhelming Majority however, really only care for one thing: Overall polish. They give a flying fart about speed or other advantages of style, they want the ability to do it without having to resort to forums and other complex documentation (which affects speed, y'know?). It shouldn't just be possible to do it, it should EASY to do. And it should Look good when doing it! It should Feel good, be Accessible, still Functional yet Easy. Hard edges should be smoothened. Basic things should be streamlined. Every stone should be turned and meassured. I contend, that is what people will pay money for, and that is what will make them use the editor - rather than skip it. Besides, we'll still have the init field to copy and paste in. The "GENERATED CODE" field, in the mockup, would be copyable as well, preferably. So yes, I think it would be worth it. It wouldn't be an overly complex thing to do, and it would benefit a lot of people - probably You included. Carl, I wrote specifically that classnames in the mockup were inaccurate - I don't care about shortform. By the way, I'm sure you can tell, that I used your idea for inspiration. ;) NoRailGunner, I agree templates might be cool - just have to be wary that some soldiers have less inventory than others. Perhaps a red number when out of bounds would suffice? ie if you add 2x M16, it could go red.

sorry I wrote garbage first... what I think you need is this: You want to check that all the men who are alive are in either of the zones. This can be done like so: Each zone trigger should be: REPEAT, BLUFOR, PRESENT, (or whatever condition) trigger_zone_X = thislist where X is a number for each trigger. Then a master trigger Condition could look like so: men = units group1 + units group2; living = {alive _x} count men; {_x in trigger_zone_1 or _x in trigger_zone_2 .........} count men == living; where groupX is each group that you might have which can be defined in the init field of each squad leader like so: group1 = group this; etc. hope that helps.

probably dumb questions but... Do either of you have any problems when joining public servers or anyone else? Tried disabling windows or other firewall/AV/maybe more?

How far is "far away"? What's your sensitivity set to? No mods right? Video or no one believes you! ;) Maybe try a temporary profile and see if it persists. aaand I'm out. sorry, useless.

I obviously didn't read it all, sorry. Not sure why sleep wouldn't work for you though.

Seems to work fine for me. Check your difficulty settings. It's off by default in Recruit mode, I believe.

So how much faster is loading textures from systemram to vram compared to hd to vram? Suma says it'll make no difference going 64bit, but is he only right as long as textures isn't held in system memory? I might not have a clue of what I'm speaking.

I think you meant to write "settle down to (0,0.5)"? Anyway, while it's probably true that drift isn't one direction in reality, I think it might be wise to stick to one direction, because the predictability actually encourages the player's constant involvement. If you have a completely random distribution, ie one without "forced trends" then it only make sense to get involved when the distribution has made outliers. And after outliers you can often expect a regression to the mean and you may have a tendency to overshoot the correction, "dramatically". I would probably have to see it in action really, but I suspect random direction muzzle drift, or even forced trends muzzle dirft, could end up being impossible to adjust for.

Not liking delay and not working is not the same thing. An un-equal 1st and 3rd person animation I think will be regarded as worse than the current system. (As I wrote in option 2). You don't want an animation to occur first person that doesn't happen 3rd person. You want it to be equal. Try starting up editor with a rifleman, and turn on time acceleration, then repeatedly lower weapon and raise weapon and see if you think the little delay would be a game killer for you. Of course it'd have to be fluent with movement and all that.

I do, I want to control more. This game is too arcady :) Haven't seen you complain about any of the number of new things to control that BIS added with OA either... Seriously though, see my proposal here: http://forums.bistudio.com/showpost.php?p=1684709&postcount=8 I think it would feel pretty automatic and realistic. The big counter argument is it introduces delay, but I think the delay is actually part of what would be realistic. ArmA needs to be a bit slow. The word "instant" doesn't exist in the arma-dictionary. Yesterday I fell over a old feature request on the CIT that suggested that it should take a a couple of seconds to switch positions in vehicles. And I thought hell yeah, that's exactly what arma needs! Don't have to go over the edge about it, but enough to symbolize that: yo man, solo operating a whole tank is kind of silly, mkay? ;) I forgot to vote though..

I've said templates before, and I'll say it again: Templates! I really think if BI made a few templates the editor wouldn't feel as empty and intimidating. Also, some of the most fun I ever had were with missions that didn't even have a briefing... Granted a faulty end trigger won't harm me (mostly 3-5 player coop) as much as it would dedicated servers. But simple missions are very often good fun.