subx

Sorry should have said, I was talking about FTP. I don't think HTTP will have the same problem, because the file request is all in one connection. And testing on your repository seems to back this up (successfully downloaded large files). So it's probably a FTP only issue, but adding a bit of robustness against networking errors is always a good thing.

Just been trying to use Arma3Sync to download a repository and have encountered the same stops in the download process as previously reported by another user: I can't see resolution to the issue in this thread, so I'll explain what I think is going wrong. I was finding that any file larger than about 250Mb would cause the problem, but it's not the size that's the issue, it's the time taken to download. A file of that size was taking about five minutes to download from the repository. A quick look at the network traffic to and from the server when a file is requested shows there are three parts: the initial request, a small piece of information about the file, and then the file contents itself. The problem is that the initial request does not complete until the file contents completes, and when a file takes a long time to transfer one or both parties lose interest in the initial request and it never completes. The file finishes downloading, but Arma3Sync is left indefinitely waiting for the initial request to complete. Not sure if the miscommunication is caused by a server configuration issue, but Arma3Sync should really be able to handle the situation, even something as basic as timing out if no data is being transferred anymore and moving on to the next file, would help.

VA seems to be a case of style over substance (and another example of BIS's inability to design a decent UI). It overcomplicates a simple task. Its use fails to be immediately obvious. Once you understand the way it works, it's cumbersome and lacks clarity (being surprised to find things in your inventory after using it isn't a good sign). The VAS UI is not perfect, but it is a damn sight quicker and clearer to use than VA.

The lack of analogue controls for vehicle acceleration and braking has always seemed like a bizarre omission. Even more so with the karts addon. Considering there's an analogue steering control, it just seems odd. Anyone know why they're missing? (Bit puzzled that I can't find any other posts asking this simple question... makes me wonder if I'm missing something!)

Excellent, I was looking for an output window for debugging and this has that and much more :) Quick note on the included script with dummy functions for when the addon isn't present: executing this at init for a mission (as suggested in the readme) causes problems because (isNil "FHQ_DebugConsole_Commit") is always true at this point because the debug console functions are not yet defined. Adding a slight delay gets round the issue, and quickly looking at the code, I don't think debugConsole_outputconsole_fn.sqf gets included in preinit because init.sqf only references it with execVM. Below is a slightly modified fhq_debugconsole_support.sqf with a delay so it works with the current addon. I've also added an override of FHQ_Debug_KeyHandler to add an extra binding so the output window can be directly toggled (far more convenient!) sleep 0.01; if(isNil "FHQ_DebugConsole_Commit") then { FHQ_DebugConsole_Commit = { }; FHQ_DebugConsole_Clear = { }; FHQ_DebugConsole_DebugOut = { }; FHQ_DebugConsole_SetOutput = { }; } else { hint "FHQ DebugConsole initialised"; FHQ_Debug_KeyHandler = { _res = false; if((_this select 1) in (actionKeys "User20")) then { [] call FHQ_DebugConsole_MainDebug; _res = true; }; if((_this select 1) in (actionKeys "User19")) then { [] call FHQ_DebugConsole_User19Key; _res = true; }; if((_this select 1) in (actionKeys "User18")) then { [] spawn FHQ_DebugConsole_ToggleOutputWindow; _res = true; }; _res }; };

Not sure about voice commands, but GlovePIE seems to be able to control this mod without issue. For example, if I set "X" to toggle the map in tao_foldmap_a3.hpp, I can then use GlovePIE to assign a button on my midi control surface to do that action: GlovePIE script: Pressed(midi0.cc46) => Key.X;

Thanks for the update, think it's looking pretty much perfect now :) Also I think the control weirdness that tortuosit reported was probably due to the same CTRL variable issue I found.

The class defined on line 14 of config,.cpp is what's causing the second entry to appear: class CfgMods { class tao_foldmap_a3 { dir = "tao_foldmap_a3"; name = "Tao Folding Map"; picture = ""; hidePicture = "true"; hideName = "false"; actionName = "Website"; action = "http://ryanschultz.org/arma-3/"; }; }; Now obviously I'm no expert with my full two hours worth of experience :) - but I believe it's unnecessary since (based on this old thread) it's just replicating the information from mod.cpp anyway.

Hmm no fix for this... so I guess I'll learn a bit about making addons for ArmA and debug it myself... lines 367-369 of init.sqf have incorrect variable names for the CTRL key setting from tao_foldmap_a3.hpp. Corrections needed are shown in red: tao_foldmap_keyZoomIn = [TAO_FOLDMAP_ZOOMIN, TAO_FOLDMAP_ZOOMIN_SHIFT, TAO_FOLD[color="#FF0000"]MAP_[/color]ZOOMIN_CTRL, TAO_FOLDMAP_ZOOMIN_ALT]; tao_foldmap_keyZoomOut = [TAO_FOLDMAP_ZOOMOUT, TAO_FOLDMAP_ZOOMOUT_SHIFT, TAO_FOLD[color="#FF0000"]MAP_[/color]ZOOMOUT_CTRL, TAO_FOLDMAP_ZOOMOUT_ALT]; tao_foldmap_keyNVMode = [TAO_FOLDMAP_NVMODE, TAO_FOLDMAP_NVMODE_SHIFT, TAO_FOLD[color="#FF0000"]MAP_[/color]NVMODE_CTRL, TAO_FOLDMAP_NVMODE_ALT];

Thanks for adding the option for manual key bindings, much appreciated :) Second entry on expansions list: I think I've got some vague memory of it happening with some mods on ArmA 2, no idea why though. Interestingly it doesn't happen with version 2.1 of the mod. Issue: CTRL modifier on its own doesn't seem to work for zoom in/out (key bindings work whether CTRL is pressed or not), However SHIFT does work, and CTRL does work for recentre map,

If I enable via the expansion menu in ArmA and restart, a second entry for folding maps then appears in the expansion menu....? Re: the controls: You can't use modifier keys with mouse/joystick buttons, so I'm unable to zoom the map becuase I use the mouse wheel to zoom. So being able to configure the keys would be a real help (even if it's done by manually hacking a config file like with VTS weapon resting). Also didn't you used to be able to recentre the map? Can't seem to do that anymore...? When the map was "paper" it made sense that it didn't scroll, but now it looks like a tablet there no longer seems to be a reason for it to be static.

While some UI elements have gradually improved over the versions, the Action Menu has stayed pretty much the same (possibly since OFP?) Almost everyone will have experienced the highlighted option changing between deciding to select it and actually activating it - always fun if "touch off bomb" is the one you accidentally activate. There's nothing more annoying than blatantly bad UI design being ignored, especially when it could be fixed with minimal effort. It's probably the most efficient use of time to improve user experience. The Action Menu fails to adhere to some very basic UI principles: - do not move interface items - only the user is allowed to change the function of an interface item So to fix: (while the Action Menu remains on screen) - do not remove menu items, just disable them (important: only prevent the user from activating them, not selecting them) - never change what the user currently has selected - when adding new menu items, do not move existing ones It's not some amazing new concept, it's just how it should have been programmed in the first place.

Anyone who's spent some time hacking around the A2 Domination code should realise that doing a straight port would be more trouble than it's worth anyway. I mean, it works but, well... lets just say that creating a Boolean with a triple negative meaning is some kind of achievement! Take the concepts and reengineer them.

It would be nice to play Domination somewhere that wasn't Takistan. I've been there so often I think the locals are starting to recognise me... Of course there are other islands out there, but there's sometimes a reluctance to use resources which aren't easily accessible. So how about porting Domination to Zargabad? Everyone has that. There only seems to be one version out there already, and it's a fairly small scale affair. I want something which can be used in place of Takistan, with all those main targets and side missions. But surely having all that stuff crammed into such a small area would be complete chaos... ...sounds like fun :) This port of Domination is a bit different, with less sitting around and more getting shot at. Most people running Domination have customised the mission to fit their needs. So with that in mind, Zargabad Domination is a straight port of the original Takistan version. All the units, vehicles and buildings are the same, and there's no additional custom code. So converting your own version of Takistan Domination should hopefully be a fairly straightforward process. Suggestion: try to resist the temptation to fill the base with respawning tanks, it significantly reduces the challenge of the mission. The Zargabad port has been done for four versions of Domination: 2.60zc which is still quite widely used, 2.60zc ACE, 2.71 if you want something more up-to-date and 2.71 ACE. co30_Domination_2_60zc_West_OA.Takistan -> co40_Domination_2_60zc_West_z3.Zargabad co@30_Domination_2_60zc_West_ACE_OA.Takistan -> co@40_Domination_2_60zc_West_ACE_z3.Zargabad co40_Domination_2_71_West_OA.Takistan -> co40_Domination_2_71_West_z3.Zargabad co@40_Domination_2_71_West_ACE_OA.Takistan -> co@40_Domination_2_71_West_ACE_z3.Zargabad So what has been done? All 21 main targets have been implemented. There aren't 21 towns in the Zargabad map, so a bit of creativity had to be employed here. The main targets are set to occur in a predefined order rather than randomly. Although this leads to less variation, controlling the flow of the mission helps make it work in the limited space (by reducing the chance of units from the next main target spawning on top of people). All 45 side missions have been implemented and had their descriptions rewritten (this took... a while :) The main base has been liberally sprinkled with fortifications, etc. to make things a bit more interesting. The 2.60zc version has had its number of players increased from 30 to 40. The unit configuration was copied from the 2.71 version. Some of the default Domination settings have been modified to what seems sensible (for example, no para jumps, since it isn't really needed on a map this size). The default time of day has been set to tie in with the mission briefing (see below). The base marker is quite tightly fitted, this is an intentional effort to try and reduce kicks for shooting in base (at the start of the mission there's a strong temptation to hide in the base and shoot from there). The default number of shots to get kicked is also set quite high for the same reason. These measures may possibly be abused on a public server though and might need to be revisited. There are a couple of lines added to init.sqf to mute the colour palette (noted here in case you want to remove them). A general sweep for the spelling errors has been done (no more "carefull" or "canceled" :) Playing Zargabad Domination Briefing: It is imperative we secure Zargabad and the surrounding area if the on-going war effort is going to succeed. 24th of May Our scouts have reported that the Takistani army is having issues with troop deployment in the region. This has temporarily left the airfield at Zargabad susceptible to attack from the west. 25th of May - 0200 A small expeditionary force will insert west of the airfield, neutralise any remaining defence forces, and attempt to secure it before first light. 25th of May - 0400 A new day is dawning. The Takistani army is waking up our presence in the region. Expect fierce resistance. The mission starts fast and doesn't stop, and is meant to sometimes be tough going :) Depending on the weather, it can be quite dark at the start of the mission, make use of it. There's a small amount of left over Takistani hardware to help at the start, but it won't respawn, so use it wisely. Defending the base is an important part of the mission, there is the constant threat of it being overrun. If you ignore it, there might not be much of a base to come back to. Get It http://www.armaholic.com/page.php?id=18442

New version released.

A few people have reported slow down issues on the mission, which may be due to the higher concentration of enemy units. Default view distances have been returned to the values from the original version in an effort to alleviate this problem.

z3 Added: port to 2.60zc ACE version (for completeness) Added: extra setting for MHQDisableNearMT (300m) which is now set as default (was previously 0m) Fixed: positioning of AI hut and spawn which had not been placed properly Fixed: removed a couple of markers in Nango which shouldn't have been there Fixed: corrected some minor typos Fixed: tweaked the positioning of a few objects Fixed: some more spelling errors from the original have been cleaned up Changed: default view distances set to original values Changed: wrecks now stay for longer and more can be fixed at once by default Changed: default frequency of AI artillery attacks reduced z2 Added: port to 2.71 ACE version Fixed: "Zargabad" added to the mission name (less confusing now) Fixed: the searchlights in the anti-air and radar positions are now shut down as the mission starts Fixed: some main base buildings now don't take damage to prevent objects being left in mid-air (!) Fixed: Bravo leader could call for a drop in 2.60zc but not 2.71, he can now do so in both Fixed: some objects moved slightly further away from the taxiway to make more room for large planes Fixed: small adjustments to some marker positions Fixed: tidied up some sloppy scripting in the mission z1 Initial release

I can see your reasoning about panel contrasts, but the fact that I'm using a CRT and have observed the same issues described above would suggest that it's not a major contributing factor in this case.

My personal favourite is getting in a Mi-24 at night and being blinded when starting it up, because the dials light up, totally obscuring the outside world. Brilliant. (not sure why contrast ratios have been brought up, not really anything to do with this issue)

I just reinstalled OFP (+gold +1.46update +resistance + 1.96update) which I haven't played in quite some time, so I don't know if the problem I've had is specific to the current version or not. Anyway the problem that I first encountered was that, when I tried to join a game via ASE, OFP would get to the point where it says, "Wait for server..." and not get any further. Figuring that something needed setting in my ADSL router's firewall, I looked through its logs. Only to find that it was actually blocking a UDP flood coming from my computer to every server I tried to connect to. **UDP Flood to Host** 192.168.1.2, 2304->> XXX.XXX.XXX.XXX, 2434 (from ATM Outbound) Very odd. Better remove ASE from the equation then... connecting to a server from a short cut causes the same problem. After an extensive search of the internet I found a couple of other brief mentions of a similar problem, but no real solution (other than turn off the firewall and therefore let the UDP flood go). After a good long while thinking how to get around the problem, I realised I hadn't I tried connecting from within OFP. So I brought up the remote server entry page and plugged in a random server's IP and... the same thing happened, nuts. But then I tried the in game server browser, and... that worked no problem. Bizarre. So although I'd rather be using ASE to connect, I'm just glad that I found a work around before I'd pulled all my hair out :) Any suggestions as to what the hell is going on would still be appreciated. OS: Windows 2000 SP4 Connect: networked 3Com ADSL router

No one with any ideas on this issue?

A bit off topic, but is there any documentation for all the command line switches? Tried to find some the other day and didn't manage to come up with anything.

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote </td></tr><tr><td id="QUOTE">Quote: from ufo hk on 5:41 am on Oct. 16, 2001 To say that because one feature is missing the game is likely to die, over looks the fact that there are many other features / functionality provided that will ensure it's survival.... <span id='postcolor'> I think what you're overlooking is what the majority of people want out of a game: easy, "out of the box" usage that they can play for an hour or two when it's convenient for them. The features you talk about are welcome, but will not appeal to the majority. I can think of several games over the passed few years that had entertaining multiplayer games, but because their ease of use was poor they didn't take off.

The way I see it the next big thing in MP gaming will be first person, allow people to play different roles, allow them to cooporate in those different roles, let them fight against other people, provide various additional equipment such as vehicles, have large and persistant combat zones, and allow people to join the game when they want (it's not difficult, you start them in a safe base external the game and then transport them into the game in a realistic reinforcements way). OFP is achingly close, but my high hopes for the game are fading fast. An occasional game to play with a couple of friends, but not the next best thing.