Masaketsu

Hey all, I'm a first timer to this kind of scripting so I'm way out of my depth. I've got several .cpp configs under various folders launched in my .pbo. In a SP environment it runs great, and under virtual arsenal even better. The Issue comes up when I try to enter my mission on A3 dedicated servers under test conditions it states that it cannot play the mission due to a missing file / content and it's named exactly the same as CfgPatches class. http://pastebin.com/fqWuv6Vp Here is my pastebin, at present the mod is roughly 99.99% finished and there are thousands of classnames (this is one example) and I would be indebted to everyone if we can help me to finish the problem solving of this particular issue. I really appreciate any help you can provide on it as this has been a seven month project and we've only just entered MP. Thanks.

I'm working on a project that will offer above 500 uniforms, and it only took me about 3 weeks and the quality is roughly BF3/BF4 HD. So hopefully maybe I can work with a range of options requested by yourself. Albeit these are correctional reskins of the A3 vanilla content to try and rectify some of these horrible issue's such as low texture's.

So is it a plausible expectation (theoretically) that there will be some new vests for A3, that come directly from content showcased in your A2 modification? Because these vests and an entire selection of LC-2 NSN equipment is spot on. I think if you were to release these with some drop leg holsters attached (think early 2000's onward) You'd have a solid early 2000's mod. I've begun work on the Officer uniform from A3 (it features an LC-2 "like" belt) and i've got them in DCU and BDU formats. So maybe that would cut down your dev time as well..! Eh, just a thought.

Firstly, Allow me to thank you for the work done. It's critical that you maintain an honest rapport with the consumer/community. That said, I think the best direction is for individuals who specialize in specific area's to modularize this project. The entirely compartmentalized variant of this project is pivotal to the further development, a vision even I can foresee being difficult, but very, very rewarding if finished fully. Essentially, to manage a project like this some steps must be taken, and done so in a manner both timely and also patiently, these are my feedbacks on your word: -Begin with a template for each module. Complete one, fully working template, a good (great) example is a helicopter, fully ported with physical and code based aspects completed, this will become the framework for working in later data or if an SDK is released for this, mods to be ported, vital ones such as A2/OA mods. -Conduct the creation of the compartmentalized features one step at a time, if it is infantry, simply strip them of their gear for now, again, template and build an adequate set for each faction, gear and equipment can be rewritten later. -Be realistic, are we going to really play vanilla A2/OA missions? Probably not, a better way to view this is that player created content will make up this portion of the work and will save a considerable amount of time regarding mission build. -Terrains seem to be fine with the recent A3MP map + fixes, thus addressing a huge time span issue for development. So again, template one, fix the rest, at that point, write from that template, and compartmentalize projects so that a percentage of OA, A2, etc. is implemented successfully. However, I feel that I sense you're at a limit in your development days and exhausted from no funds. NOTE: This is normal, and after so long I think honestly bringing this project in a new, more streamlined, specific direction will save it from cancellation. I know one of the CUP developers, and if you deem necessary I can attempt to help, I've got big projects on my hands yet to be named, but may be of worth to you later on if and when I choose. However, I wish you luck in all these plans. Your work may yet be the most important, yet understated of ArmA legacy dev.

Moderators, please note this has happened on Steam Community as well. DJOtacon is infact pursuing Zooloo75, I see no actual statement regarding him directly or anyone specific, but infact criticising just the way the community is on steam in general. This is the second time i've seen this, and while it is true I am on Zooloo75's dev group for a prominent mod, that is no reason for me not to speak up when I see a recurring event. I'd like to ask that you see resolution to this where both parties can benefit (or neither) but at the least note that the individual in question (DJOtacon) did infact come in here and make the post a personal one. Please advise.

^ Agreed, you didn't. The topic point is motivation enough however, steam community forums need better moderation. There are too many people with a half conclusive ideal or bias whom later back out of their argument with a irate attitude simply because they didn't favor the courtesy of criticism and due credit, instead trolling or reporting one another's posts to win their case. I find that steam's posters are often more akin to mainstream users than all the hardcore, loyal-to-realism output developers who spend their time on a project and simply want proper feedback. I also feel that people are in high abrasive mode, pursuing not the original point of topics but favor derailment to satisfy their half (again ^ aforementioned idea) baked bias / emotion use. My 2 cents.

Thanks for the input; we're binding the UI element's coloration to the ingame customizable elements. Font colors dictate white, highlight UI elements incl. border corners, etc. The objective is that the user can dictate how he wishes to view the UI. The vehicular gauges are unique to the type of craft being in use; driving will typically only show the speedometer while at the drivers seat position *and* most importantly; scales depending on real in-game mechanics. Altitude is important, as we're giving a metric altimeter gauge in altitude ladder while the text is shown in feat, allowing both users to benefit from this, while this happens, neither of these feature in the regular HUD while on foot or in a vehicle position that doesn't warrant such a thing. It's critical that we focus on consolidation rather than clutter. The only other "vehicle" HUD's outside of this module, known as the weaponstat.module, will be shown in a status HUD in the top right or another undisclosed yet to be implemented location, which shows the (upto) six boxes and their states/status, Hull, Eng, Inst, Mrot, etc. We're focused on giving the user options, and typically when this is finally in place, a user can forget about eye strain looking at finicky, or odd positioned HUD elements, and focus on the real-time data in a non cluttered way ingame!

http://i.imgur.com/AUSACCY.jpg (307 kB) http://i.imgur.com/9HsgSYf.jpg (244 kB) These are the final'ish concepts (likely to be interred into program actual) for the consolidated statistic HUD, on the right side. If anyone would like a detail based explanation of what each function does, I can discuss it, but I am sure it goes without saying what most of this stuff does, and allows the user if in an interest to fly with HUD's on, to enjoy the experience of the HUD onscreen. Hope this works.

We're working in "modules" which means we're compartmentalizing each aspect for a more consolidated, unified HUD. While Zooloo works the implementation aspect solely, the share of work for us both falls under managing the projecting and directly seeing what we will be able to consolidate to streamline the UI. For instance, the RADAR system could also easily be reworked to count in GPS information, incl. of course bearing and courses, just like in a real scenario. So of course our plan is not going to subsidize realism, but bare in mind that this HUD UI is to cater for everyone, you will have the option to disable/enable Goggle HUD effects, irrespective of the FX being turned on or off, and same with UI. Meaning that the user can choose to have the UI only show in third person, a time when Goggles don't show. Or, he can choose to have the FX turned off, or any of these options on or off, it means a user can not only customize the coloration of his HUD (via the already in-game UI custom color feature), but also allow the user to choose in config files, what shows and what wont. We're building UI2's template, it's much like a web design template in that it comes in its own modular folders, and has modules for each portion of the HUD, allowing a designer to radically change out how the whole design looks, and what can be shown and hidden too. This also in combination with detection of ingame data, alpha fade transitions and marquee scroll data, allows us to make a more professional HUD. I'd recommend personally that any people trying to play an absolute hardcore experience in realism leave it only for 3rd person. That way, you can get the benefits of a truly immersive Goggle HUD system, new weather and damage FX, and at the same time when going into third person if needed, your HUD's will provide you necessary information, and tactical data that will help in the battlefield too.

As the CGI Artist behind this I can safely say this is one of the most advanced graphical UI reworks on the mod market. That said, I'd like to say regarding 2D effects; i've been considering ways to implement a later oculus specific graphic definition that would simulate the visible peripheral blur of both glasses/goggles. For now, glasses/goggles will retain their currently beautiful look, simply as the monitor of many screens in 16:9 format widescreen will look strange having the blurred peripheri consistently. I imagine if there were an Oculus Rift code patch that detected the device ID, it would alter/swap the overlay HUD for one that could become more peripheral depending on movement, conditions or head sway. Someone also suggested a Field of View adjustment bar, whereas it scales only the textured overlay HUD, but not the FX, meaning the edging of the said glass or goggles could be more edged, peripheral based, especially so with said oculus code above. Again, all features that are only possible via UI2, and not vanilla A3. Thank you all for the complements on the CGI work, please direct your critique's and complements here as we continue to further the work. The real magic is the C# used in Zooloo75's data. I will say this, you may see individuals claiming that it can be done easily in ArmA 3 default code, via CutRSC or RSCTitle, but we are aware of the limitations that this yields, henceforth why this modification exists! Please don't be fooled by the idea that this is a simple project, it tethers UI, CGI and Frame-by-Frame animation into a fluid, dynamic UI recreation mod that allow developers and users alike to customize their HUD's however they see fit, even a slight alteration such as coloration changes can be made simple with this, and an expansive codex of options will likely follow as development works to assist mod's. So, many thanks not only to you guys for your positive feedback, but your idea's, we aim to create the bridge between ArmA 3, Immersion and most importantly, a consistently improving UI editing system in place that may soon support an Oculus future for gaming. In closing, don't forget to post ideas you feel will benefit UI² dev!

Thank you A******** G****** for your contribution of 5.00 USD Thank you L*** J****** for your contribution of 10.00 USD Our objective is to properly gather the resources needed, and rather than pirate or rip content, we'd prefer to pay for video and imagery effects for a professional use. For those who are wondering, we're not simply using ArmA 3 Code, we're using a bridge with ArmA2Net, to allow C# code manipulation for HD'd Graphical interfaces. The water FX shown could not have the beautiful luster it does without the contributions from you all. The endgame project will be to get a devkit for oculus for my friend and colleague Zooloo, he's the coder behind the genius of this wonderful development. I'm the CGI Artist, so what i'm good at is developing specular, HUD, UI and professional user interface modifications for a variety of applications/solutions! Again, thank you both, we are excited to work with you on it.

He make it rain; http://www.twitch.tv/zooloo75/b/544937034

Some food for thought here as we stumbled across some odd issues in regards to HUD drawing. I've noticed that in ZAM Glasses mod, while diligently working on the project LHM was pushed back by a BI issue of not being able to render/draw the UI ontop of his desired Goggles. This ensured that the project took on a form of trying to be subtle in design, rather than as immersive as he originally desired. The mod is great, but it inspired me to wonder: "Can we really break the immersion barrier?" In this endeavor I sought to demonstrate what (while quickly doing some UI HUD design) it could look like, this; http://forums.bistudio.com/showthread.php?163658-ZAM-Glasses&p=2715814#post2715814 this URL shows us all that there is the potential of an unhooked HUD. So, I spoke with Zooloo75, a prominent programmer/coder who seeks a challenge with ArmA and I'd assume future enthusiast projects that can build the artisans resume. That said, we discussed an idea: -A- The original UI suppressed or removed from the game, while initially daunting we will explain that by doing so, a core framework would rebuild the exact (or better UI) in an external applet, working strictly for sole purpose of allowing a developer to rewrite, rebuild or alter existing HUD/UI functions in any order sought.. -B- This meant that, essentially you could have all your Goggles ingame, working with beautiful C# effects, a UI that sits ontop of it, toggled by a button via userconfig .hpp format. The Goggles would be articulated in code by a library of classname detections (allowing further support), a definable .hpp would allow HUDs to be configured at will ensuring expandable mod support, to incl. Modules for in-mission definition of PAA. -C- Definable throughout is the aim. Initially, the core framework aims to encompass the initial eyewear of A3 Classnames, an immersive and beautiful Goggle HUD that can be altered/affected by FX incl. Snow, Rain, Fog, Dust and even Blood is in the plan. The UI, while likely Legacy in emulation to the original, can be in user preference, turned on inside the Goggles (if worn) or off at will. Customized completely should Users clientside wish to edit these features. Furthermore, gas masks will exhibit similar audio FX to Scuba dives. -D- The last feature, will be to encompass vehicle developers, more specifically; aviation. When a developer's goal is to make immersive his aim, he may forget that his vehicle comes with a unique UI. A helmet of his or hers choice as a p3d, plus classname could be shipped with the product and extensible code added to UI²'s script folder ensures that he or she can write a .hpp UI applet strictly for use only in this vehicle on which only the corresponding helmet would work. This .hpp means that it can be written professionally, a vista of realistic functions bound to the helmet and removed when the headwear is no longer on a player. This feature means that while a template is created initially, a developer can endlessly create new, user- friendly UI elements that simulate the real world, or his own choice rather than bending to the initial BIS script found within the codex of A3's engine. There is one last feature, but will likely come into affect as development is donated into; and that is Oculus support. The idea that your claustrophobic senses must play as much a role in real life as they would in-game means that a functional, powerful UI & GoggleHUD can be even more immersive as the player zones out the monitor and puts on a new set of eyes, in ArmA. We expect that the player can look forward to immersive FX, powerful UI support and the unhooking of a former HUD, for one that can be turned on/off at will, customized entirely and can be used in every mod available on ArmAholic, Six or BIS. It means that at the end of the day, you can create the panic of Gas Mask's in a zombie apocalypse, or the dust strewn across an operators goggles, while choosing a UI I/O in-game. A few examples of idea's in mind incl. a PiP Shoulder/Helmet Cam management, and possibly an entirely permission based Webcam "Crosscom" system similar to that of Tom Clancy's Ghost Recon as an online team can use their webcam to co-ordinate movements using real hand signals, and more besides! These idea's while initially bold, are actually possible and with some commitment from dev, the push for this is an immensely revolutionary ideal not yet realized in simulators. This can bridge the gap between super fidelity MilSim all the way down to simple HUD tweaks, or fun, hobby-level development such as adding a ZombieHUD for a mod. Click here for Concept's or... Thank you.

Hey LordHeart et all, I've always loved GoggleHUD systems and since my own development in a previous AAA mod release I've felt it is overlooked way too often. Anywho, I digress. I love what is done here.. That said, I've taken the liberty of providing extra HUD work should LHM wish to expand and update the previous version, incl. HD Rain, Dust is left untouched (it was amazing, whew!) I added a TBD Frost effect, several Goggle types incl. potential support for HiddenIdentity and SP Pack. I'm hoping to help out this development as it is an amazing addition to all immersion. Thus... I feel that due to ballistics, the unlikelihood (and hollywood-esque) idea of cracking was a feature that isn't often seen. The U.S.'s GSA and NSN System of issuing equipment also is ANSI rated for testing ballistics, most would likely either bend or have scratches, dirt, etc. Most of which can be wiped and cleaned off with several attempts, that means that I did make a blast texture, which can simulate scorches but which can be scrubbed off by hand. These are all just screenshots from ArmA 3 but overlayed with the texture design, if a HUD element must be factored in, I'd recommend the mod disables standard HUD's and an .HPP Userconfig for assigning a "show HUD" temporarily Key be implemented, while keeping third person's HUD showable at all times. Otherwise this is just an expansion on the idea LHM's been so kind enough to show a proof of concept upon. Many thanks for your work in this. Awesome work LHM! 'Ketsu. P.S. Some of those HUD's incl. an M40 Gas Mask (recommend Scuba HUD be used for M50) P.P.S. Please don't misunderstand, right now I'm trying to see if LHM would like to collab with me, this work is not implemented, but shows promise. His codework is epic, I am simply a texture artist in this role, but am hoping to work alongside LHM, also.

Is this image https://dl.dropboxusercontent.com/u/28808032/pictures/U.S.%20Military%20Mod%20Preview%2037.jpg (1465 kB) already in the current version? I've yet to find the Rangers in the version I downloaded. Is there a hidden texture selection for a ranger with his RBA Vest? I'm quite intent on playing on some Somalia '93 like missions but I'm refraining from using the PASGT... XD Anyone? Also, Holy crap, after reading the posts. Delta, you're adding SPEAR vests and 2000+ Gear? Wow O.O

I'm new to the forum, but a long time Arma 1 user. Now i've transitioned to Arma 2, and i'm intent on getting ACE within my gaming habits. However, as the topic title states, i'm at a point where i cannot make ACE 2 Save a custom controls scheme, under the ACE Settings menu. Please assist in full. P.S. I've configured the userconfigure, clientside, so i am sure it is not that, but i am open to any help at this point. Also, in my ignorance i have yet to find out how to delete a mission (in multiplayer) that comes with ACE, i'd like to just have at the least, the default missions. Thank you for your help, all.

Perfect, thank you.

The ACE Mod thread i located, was locked. Can someone please help to rectify this ongoing issue? Many thanks if anyone has any verbose intel.

I did, but for some reason it only lets me save say; certain toggle functions rather than actually the individual controls. That, is why i have the difficult task of working with custom controls on Arma 2. Advise me on ClippiTool ok? ^^