mahuja

Placing this here since people are most likely to check here. If you get the error message Addon 'AiA_Roads2_Config' requires addon 'AiA_Roads2_Data' and have all roads and lots of buildings missing from the AiA terrains, then likely you have also installed @nam. Both have a *roads2.pbo which maps to \ca\roads2 - and this likely overrides the other. It may solve the problem if you reverse their order in the -mods parameter.

Wrt capping the players turning speed relative to his weight - in arma 2 bi did exactly that, but dependent on active weapon rather than total player weight. (Because let's face it, vanilla arma2 didn't have a concept of weight.) So if you held a MAAWS/Javelin you'd need around 5-6 seconds to turn full circle. Why was it removed? Probably because some people couldn't tell the difference between that and (negative) mouse acceleration. Some quite vocal people. Shouldn't be hard to find their videos. That's why you can, in arma3, spin in place at rates probably well over 100 rpm. Or at least could, I haven't tested recently.

TL;DR: Stamina CANNOT reach RiE's goals. The announcement post explicitly stated they were working in a specific direction, which is incompatible with the stated goals. --------------- To keep my post short(-er), I'm trying to skip what others have said where I'm not adding to it. Keep stamina (new) vs fatigue (old) systems straight as you read. >is usual in absolute majority of other games. Great software is sometimes made with "Take CVS as an example of what not to do; if in doubt, make the exact opposite decision." I consider arma better than those "other games" - I'm among the supporter 500 - because of the differences. If you systematically eliminate such differences I may as well go for a cod next time. At least they pump huge amounts of money into superficial stuff, and there won't be any deeper stuff to care about. >Why would the devs completely replace the old system, with a totally new, extremely simplified one, if the old system was already meeting the goals they themselves set? The conclusion one might come to is that their real goal was to simplify/dumb it down all along. And then you read the announcement post carefully, where they practically state it outright. However, I think it goes deeper: Reading RiE's post, I feel RiE still has the right vision for what arma is and should be. Noone seems to disagree with his goals. But I fear that vision is not shared by developers such as those responsible for the stamina system. >the stamina system rewards tactical use of load, environment and tempo Please write your setup, methods, and results as a research paper would, so that we can figure out what the hell you're doing to get whatever is "satisfactory" results in this matter. As you can see from the feedback, we're completely unable to reproduce it, and given the lack of a qualifier like "when finished", we should be able to. >it took several months of prototyping and internal discussions, together with various tests of proofs of concept. >Stamina = the time how long the sprint button has an effect. [in seconds] Maximum stamina = (1 - load player) * 60 [in seconds] Regeneration rate = maxStamina / 45 [seconds / second] How many man-hours are we talking about again? More to the point, can I get a promise from a person with the authority, that all of this will be dumped as a failed experiment should it prove to not be suitable for arma (see rie's goals) even when "finished"? > A) Encourages players to consider their loadout B) Asks players to plan their movement C) Rewards players that make objectively better choices D) Prohibits players from selecting unrealistic loadouts E) Is transparent and comprehensible for players Others have already covered why stamina doesn't meet these requirements, whereas fatigue does. I'm going to take it one step further. Here's what needs to happen to make stamina meet each goal. A: Carrying a lot has to impact your ability to move long distances in general (explicitly prohibited*) OR their max run speed, as well as sprint speed, gets gradually lowered as a function of carried load. B: Moving uphill drains stamina reserves (explicitly prohibited*) or you reduce speed (further) to what it would take not to tire out from moving uphill. For a given additional weight. The stamina release post was explicit about these factors. This was what made stamina stamina, as opposed to a tweaked fatigue. This means that steep hills (stratis) can only be climbed at a (figurative) crawl, especially with a realistic load. C: A proper discussion here would need to look at each choice the player is making. Given what's permissible in A and B, the number of choices you can make (e.g. what pace to go uphill vs how likely you are to meet enemies) are already reduced. Why would you ever walk, except when forced down to that speed? Single-person bounding would work better. Why would you run upright, given how much more visible that makes you? (Unless you put a hefty, unauthentic, speed penalty on crouched running.) D: Make A and B factors strong enough; punitively so at the upper end. As a starting guess, I'd say the A-factor at full load should reach 25% of the unloaded max speed. Perhaps with a flat 5% when it exceeds the max. They could probably be curves rather than linear, too. E: In the inventory, show the factor(A) to max movement speed along with the load% bar. Perhaps add a speedometer for walking, like seen in armory, to reveal how much speed the incline( B) is costing. While I'm at it, I would suggest another goal: Strengthen, or at least not be detrimental to, the combined arms gameplay that arma does best of all games. I have a suggestion for a better route. Make it your SOP to publish, along with (dev-branch version of) such extensive changes: A) The full set of reasons you decided to make the change. Preferrably make it clear which ones were factors in why you started working on it in the first place, and which were added later. If they don't hold up to scrutiny, rethink the project. B) What the goals are; what do you consider a success? (RiE's post has a good example this, but why did it take so long?) I believe a discussion of these goals, and the current solution's room for conformance, is the best kind of feedback at this early a stage. C) The current state of what you're publishing. Feel free to use "excessive" detail. D) The next step, and then further planned steps towards reaching the goal. I suggest making it explicit each time that this is merely the battle plan, and plans rarely survive contact with reality. E) Detailed comparison of finished feature as expected/envisioned with current equivalents, from mods if none exists in the vanilla game. F) Other paths that could reach the same goal, but were not chosen. Reasons. Here's how it has been applied in this situation: A has been very lacking. Not only that we have been drip-fed the reasons, and even now probably don't have the whole picture (AI reasons are speculation at this point) but the reasons themselves... "respect one of the most fundamental standards" deserves particular mention for brakechuting. The reasons have not held up to scrutiny, and a rethink of the entire project may be in order. Or give us the full set, so we can see if can stand up then. B is not just late (RiEs post), but more importantly it set goals that is unreachable for the stamina system. The announcement post set a "mission statement" for the new system which prohibits it from meeting the goals as well as fatigue did. And that's before fatigue is upgraded with script commands and UI. C... The information was mostly there, in between lots of markefuscation. (He IS a marketer, right?) The values and exact mechanics of the current release, could have been there already without requiring a user to dig up the details. (this space intentionally left blank) E. As C was mostly written as a comparison to current, some of that could apply here - to the extent he was speaking of the finished product rather than current. In other words, he's doing either C or E, and we don't even know which. F. The alternate this thread has been quite obvious in pointing out is to evolve fatigue with script commands and UI. Against the stated goals, this would probably do as well, if not better. You have already turned around on the question of having a hud element for the (fatigue/)stamina system, and that decision was fatigue's achilles heel - underlying many to most parts of your reasons for replacing it. Fix that, and you have a system that will better fullfill the goals stamina is to be measured by, than stamina can do while staying true to its mission statement. -- It is my sincere belief that upgrading fatigue with the UI and equivalent script commands would leave us far better off, and possibly leave BI with developer time left over for more productive work, compared to continuing with stamina. m

>My issue is that after a random amount of time normally after an hour of being in the game, I lose access to MCC, it is not in my scroll menu leaving me with no way of adding or removing stuff or ending the mission. I believe the default hot key is ctrl-del - or look it up in options/controls/addons/mcc. I've been able to access it that way even after it's disappeared from the action menu. @shay I'd suggest a button in the esc-menu (similar to ace and rhs buttons) that has the same effect as the mcc action menu. This would allow unbinding the keys rather than deconflicting them - and no need to remember them. At that point you could perhaps follow up by removing it from the action menu, decluttering it further - though given how it gives itself low priority (so is nearly always at the bottom) it's not a thing that needs doing. >I lose access to Zeus too Was there a respawn involved here? Logging out and back in to zeus has fixed this for me every time.

Nothing in his text indicates he expects full duplex. It does solve his problem, and there is a user error involved (in half duplex usage), but it sounds like there's a bug in there too. The timeline: T0 - P1 starts TX T1 - P2 starts TX T2 - P1 stops TX At this point P1 should be able to RX P2. His post indicates this does not happen. T1 should not happen before T2 in proper half-duplex use, so this is a typical did-not-test-this bug triggered by user error.

After I got properly rid of the previous version (I probably took a little bit more disk space on your server before that...) it stopped crashing. I get the 'beeps' when i press the radio button. The JVON client window appears as if unconnected. No messages, no userlist, nothing. Server window shows I've connected, though. Explicitly connecting it has it reconnect 'properly' in that regard. Also tested with other users, and it's promising so far. A few quirks to be worked out though.

Back in the alpha/beta days, the same problem plagued line-of-sight targeting as well. If you had the slightest slope you would miss. To counter this, BI applied an adjustment when you're not firing from the artycomp screen. Which is to say, the shell doesn't fly in the exact direction the tube is pointing. (Unless you're on perfectly flat ground...) This is redundant, and probably even conflicting, with your slope adjustment. Try using 0,0 slope adjustment when the shells go off target. Workaround: Enter negative numbers for the Y axis. (It might accept this already.) Fix: When this condition is detected by reading the values from config, treat all Y inputs as negative. Fix2: Do nothing with your mod, force them to fix the maps. (Config overrides, using other maps...) Another (related) problem: There are some maps broken enough to put the 0000/9999 divide in the middle of the map. Workaround: Manually offset all Y inputs by e.g. +5000. Fix: Treat initial Digit >=6 as 10-D Fix2: Do nothing with your mod, force them to fix the maps. (Config overrides, using other maps...) More importantly for me, however, there's some specific functionality I'm missing. Spotter: O-T is 200 Spotter: Adjust left 60 add 20 up 5 The spotter gives his OT (Observer-target) bearing. Turning this into X and Y offsets takes four sin/cos operations. I'd prefer not to use a calculator. Once that's in, it should not be hard to support polar missions. Spotter: I'm at 1234 5678 alt 250 Spotter: target 86.5 for 740 meters down 42 Basically, the latter can be performed as fire mission at my position, no shells fired, o-t is 86.5, adjust add 740 meters down 42 I also have a preference for mils(6400 nato) over degrees(360) but that's something I can live without. Especially given how the current kit is all degrees-only.

Courtesy of me and BlackAlpha at tier1ops.eu: How to stop them from pointing away when firing: gunner _tube setskill ["aimingSpeed", 0]; _tube setvariable ["FIRED",0]; _firedwait = _tube addeventhandler ["fired",{(_this select 0) setvariable ["FIRED",1];}]; sleep 1; // Fire _tube fire [_tubeType,_charge,_warheadType]; waituntil {(_tube getvariable "FIRED") == 1; }; _tube removeEventHandler ["fired",_firedwait]; gunner _tube setskill ["aimingspeed", 1]; They'll still be swerving their turrets away from the target, but only after they've fired and the round is headed where it was intended. An additional sleep could help with that. ps. No initial inaccuracy doesn't work for me either. Make sure you test it on high altitude targets.

The 117F needs to have its txpower unlocked from what appears to be 1W where it's outcompeted by the handhelds. I'm figuring it's just a matter of it not saving properly. Perhaps the default should be set at least as high. The 152 has repeatedly "crashed" - with the display mostly blanking out, not reacting to most buttons, and radio traffic not going through. No resetting ever fixed it, it had to be replaced. Saw 3 cases in 40 minutes with 4 people messing about, and heard of one more. No idea what specifically triggered it, but we were mostly focused on the radio and its interface. For the time being we're sticking to the 148.

Using virtualbox may negatively impact performance, though I don't know by how much. (It may even be unmeasurable, but I wouldn't bet on it.) And it's one more OS to support/update. I'm fairly new to linux development myself, but I've been in depth the last several weeks at work. Because the action was not done, I'm forced to do a bit of guessing. Something that could be more useful is to get a memory mapping listing (of code areas) that maps memory space to what files that code resides in, so as to check against all those addresses, but I have no idea of how to produce that in GDB. At #12, we enter the game's main() function, and then a bunch of calls are done in the same area of memory, meaning it's probably (here's my guessing) all inside the game's code, eventually ending at #2 which tries to call a function null pointer, leading to #1. Everything done up to that point succeeded, which was probably a lot if the dump measures "~4GB". Page 0 is always (as far as we're concerned) nonexistent, such that this case crashes with a SIGSEGV rather than let it continue when there's no way it'll be in a valid state again. Function null pointers tend to appear when trying to use a non-existent function from some .so file. (Especially since it's system dependent; it does work in one case.) .so "Shared object" is the linux equivalent of windows' .dll "Dynamic link library". I don't think arma3server does 'manual work' with .so files except for extensions, so most likely this is a result of a library version mismatch. The server was compiled with one version of some library, and is here served with (probably) an older version of that same library, that does not have that function. (At work, I'm currently struggling with the reverse problem, but once I get it right I can be pretty sure it will not crash from this at runtime. Which is kind of essential for an oracle db.) To continue debugging this issue do ldd arma3server and compare the outputs for the working and nonworking version. In particular you're looking for significant version differences in libraries. (What counts as "significant" depends on each library.) Libraries that only exist in one but not the other is probably not an issue - then it wouldn't start at all because it was missing.

Near the end of your range for any given charge, the shell will come down at around a ~45 degree angle. (Since air resistance is not a factor.) That means that for every 1 meter of elevation difference, you will be one meter short or far. Now take a look at this: https://docs.google.com/spreadsheet/ccc?key=0Aobq29XGqr-9dFNmMk40QWxPY29JQUVjamlUb0djbVE&usp=sharing THE DATA IN THE ABOVE TABLE IS CORRUPTED. Some of that will be obvious (high altitude short range particularly) but I believe the entire tables for short/mid are wrong because their muzzle velocities were changed since those tables were made in early a3 alpha. For ground level far charge I suspect it's correct but not so much I'd trust it in a mission. But as a format it provides a very nice lookup for the exact values you need when you know the altitude difference.

I don't know the implementation details but I think the "turret" was not a turret to the game engine, but an animated part, with the scripts animating it (="turn to here"). This removes the ability to aim by mouse, naturally, which means it's harder to disrupt its aim by accident. The m109a6 was partially ported to arma 3. I think maybe he needed SoulAssassin to update the model or something (see front heavy video), I don't remember. I am hestitant to ask nou about it again since I don't want to take his focus off of acre2 more than necessary.

The paladin fcs is part of the m109a6 paladin mod, which was never brought into ace. (I think that may have been the intent, but it was never actually done.) For drongo to expand the scope of his mod that widely though... don't hold your breath.

Putting this kind of "solution" into play is largely the domain of well organized groups or those somewhat deep in the modding/content part of the community. The majority of players won't be doing this, but instead buy the dlc if they want the full access. My biggest like about the whole dlc strategy is that my gaming group will be able to use these features at all. If this encourages, but not requires, the members to buy, I'm happy. If there's one drawback to having the supporter edition, it's the inability to see for myself what non-owners have to suffer.

There hasn't been an update since I last tested, so I'm assuming this still holds true. The altitude of the target seems to be ignored. So it'll assume the target is at sea level. If you have some idea what angle the shell will come in at, you can compensate for it (so long as you don't cross a charge boundary in doing so). It will be more accurate the closer the target is to sea level. At no point was this clearer than when I saw the arc the shells approached the steep half-island I was targeting at the time; if they had continued the arc would have hit the target point had it been at sea level. It is also one of the few values not kept. And it's probably caused by a spelling error. I'm curious though, did the shell flight characteristics change? Is that why you need to "determine all range data"? What format etc do you need the data in?