crashdome

Noticed you also asked about having access to a parent class. I am working on a project that is based wholly around HashmapObjects and some AI related things. I haven't publicly announced it yet but, I have been working on it since dev announcement of HMOs. I make parent class methods a thing you can do now. I also have preprocessing of the definition arrays where you can even validate code, make methods and properties 'private' through obfuscation and introduce a formal interface class. Interested in your thoughts or if you find cool things that could be added. Basically, arrays are defined in an sqf file, read in at load via config (similar to functions) and preprocessed where they are finally turned into a global var (type definition) that can be used to create objects. And Cached similar to how CBA handled caching Interfaces are declared as only Method/Property declarations that are checked if they exist and return the type expected on a Type Parent methods generated so for example if you have TypeA and a TypeB that inherits from TypeA, you can reference the parent method (for example "Method") by calling the "TypeA.Method" on the TypeB object. There's also attributes you can add as a third element in the [key , pair] that the preprocessor will do extra stuff when compiling the type definition. Feel free to check out the source on github and the brief notes in the wiki. Def check out the wiki first.

For having a conversation maybe. What Arma needs and, I'm really surprised no one has done it yet, are basic AI concepts like behavior trees, GOAP, and utility AI. I'm wrestling with those concepts right now.

If you dont sell to Chinnees no wonder they have to pirate this stuff, unless i missed your point and someone else but a chinees company markets it.  What I think Suma is trying to point out is that if you try and sell software in the Chinese market, you will most likely get under-bid by pirates as what they do is not against the law. Example: You make a Software application  and decide to sell for equivalent of $10US. Pirates take your software, crack it, and distribute it as their own for $8US because it's legal. Nobody buys your product and you lose all revenue spent on marketing and distribution making it not only a loss of sales, but much.. MUCH worse. On the contrary, if you decide not to spend the money on marketing and distribution to Chinese market, you don't really lose anything other than "potential sales" depending on if you really want to consider that they exist or not. [EDIT] fromz, I would like to add that some of us appreciate what you are trying to do as little or as much as it might help. I am sure a Chinese company that sells in any other country wish their product not be stolen by pirates also. Persistance and time will hopefully make things right.

Baddo, I agree with you about being a PC mechanic to get things working, but let's remember the context that a PC is *not* a console and the features you get with each are completely different. Secondly, I do have one linux box at my work here that is far more troublesome than any windows box. I don't know what it is, but imagine for a second you installed 1gb of extra memory into your machine (going from 1gb to 2gb) and found out you need to install a "different" version of Windows for it to recognize it at all - no tweaks, no upates, etc.. but a complete different version. THAT sums up my problem with Linux and I will say they are both equal (equal in # of problems!!! lol) and I'll leave it at that... no need for a war. I'm glad the hotfix fixed my problem, and I wish I would have been able to see it sooner. My original install worked fine with just 1.08 which I had in another directory stored already. So when I reinstalled, I missed the hotfix had been released because I just used what I had. Part my fault for not checking updates and part.. well... not going there.

It was SuckRom. Hotfix cleared it.

lol... "unsupported" yeah, you hit the nail with just about everything. My install is ok despite the motherboard change. I haven't tried the securom fix yet (I do have Atari's release) but I did disable onboard sound and disabled the Audigy 2. I did not actually physically remove it, because that would require alot of work. I will try that next but I doubt it's going to help. I got an idea to install a second Vista install on an 80gb drive I got lying around and try and mimic my main install as much as possible (drivers and all) and see if it runs. If it does, I'll copy and install as much as possible from the first drive and then finally clone the 80gb to my main 160gb drive when I am done and then reactivate. Now if ArmA still doesn't work on the second drive by itself (Vista + Drivers only) then I KNOW it's not my OS install. That will take awhile so I will probably do it over the next 2-3 days. [EDIT] Someone sent me a PM about trying to disable EAX... I will see if I can do that (not sure if it's possible in Vista) but I did wanna say thanks because I got an email notification with the message but no message on the forums

OK, thanks guys, First: This is Vista (32 bit) the OS is fine... I've been doing things like this forever and a day and I am 100% confident my OS installation AND drivers are up to date (as much as possible). Second here are my specs: Asus P5L-MX mainboard - using Integrated ADI 1986A sound chip for Teamspeak only - using integrated gigabit LAN - not using, but enabled integrated Video PCI-Express Geforce 7600GT w/ 256mb RAM (BFG brand) Soundblaster Audigy 2 ZS 2gb Kingston RAM 160gb SATA 3gb drive Leadtek TV2000 Expert TV Tuner card (gotta watch my soaps! ) Here's some history: The above setup was almost entirely the same with the old Intel board I used **except** at one point I removed the Audigy 2 because of a conflict with the integrated Sigmatel sound chip. I installed a $10US PCI cheap-o sound card in it's place (I need two sound cards - one for TS *only* Â so I can use a headset to listen/talk while having my games play through my 5.1 surround sound speakers). I used the Sigmatel sound chip for my 5.1 after removing the Audigy 2 which was great for games but bad for my TV Tuner. This change was done *after* installing and playing ArmA. Over the course of time, the Sigmatel sound chip caused me various issues with my TV tuner and other apps so I finally decided to chuck this Intel board when I got the chance to pick up a cheap P5L-MX. I did my research and knew the P5L-MX was pre-Vista release and made sure all drivers for this board were updated for Vista before buying. I've installed ALL latest drivers from Asus. There are no options to get manufacturer sound drivers or other drivers for that matter (that I know of). All this sound card business aside... why is it that ArmA doesn't work after a hardware upgrade? I can understand if I really did need better sound drivers for my Audigy 2, but should that cause such a problem that it doesn't even load the little checkbox screen? This is utter nonsense. My friend had that "openAL32.dll" problem and luckily he is a professional IT person. It took the both of us three days to find the fix. If he had been some 30 year old joe-schmoe who is not computer savvy, even with my help, he would have NEVER got it to run. He would have been fed up by day 2 returned the game if possible. I find this completely inexcusable. Oh how I miss Avon's site... [EDIT] Tried installing latest DirectX 9.0c version and added it to list of things I tried on prev post

OK, I just changed out my motherboard to an Asus P5L-MX because of sound issues I had with the other(not ArmA related) and now ArmA will not start. I get the lovely "ArmA has stopped working" crap. [EDIT]No boxes, no nothing[/EDIT] Personally, I am getting frustrated. I had zero problems with my previous board. Worked great. In the past two months, I convinced a friend of mine to buy ArmA so we could play online together and it took him three days to get it to work (on Win XP Pro) and now I am going into day 5 of my "upgrade" and the *ONLY* thing not working is ArmA. I've got all the latest drivers, about 90% of them certified. I haven't changes any video cards, memory, chip, or otherwise... the only thing that has changed is sound and motherboard drivers. Everything else I have runs perfect. I must admit that everyday I work/play with ArmA the more I hate it. Here is what I have done (generally) so far: * Updated all drivers * Tried all commandline switches known * Tried Reinstalling ArmA * Tried deleting the files in the buried directory (cannot remember the name at this point) * Tried updating OpenAL dll file (no use it was correct version anyways) * Tried updating to latest DirectX 9.0c release just in case (already had 9.0c) +more

All of these are good so far, but I especially liked that one.

If you feel you have been defrauded of your serial key (or even better - you KNOW you have been defrauded): http://www.ic3.gov/ You can file a complaint and submit their website AND/OR IP address of the offending person per incident. It may just be a game, and it may just be ~$40... but they take it seriously when there are alot of people involved. If you add up all the keys they have stolen or generated, you can multiply $40 times each and that adds up to alot of lost revenue. I am sure they would love to investigate these people simply for the fact they've probably got more stuff amongst themselves besides just ArmA serial keys. Trust me, this works.

Thanks Q, for the work. As far as feedback... not everyone is into minimalism or is strictly a functionalist. Perhaps, there should be some graphic designers come forward to help design a few options for alternative menus. For example, one minimalist one like this, one with streamlined menus for the MP person, one for the "Editor"-type , all containing atleast some color and/or design work.

I second that comment!

Thank you pennywise for the taking the initiative. I miss bn880 and his ability to always open one's eye to problems and possible solutions. You, however, have done a great service by continuing the legacy that is CoC_NS. A must have tool for any advanced MP mission designer.

Yeah..it didn't work.

is this possible?: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> switch (value) { case 1: case 2: { }; };

I've been commenting to others about this, but I want to ask a few questions just to make sure I understand some of this correctly. For one, am I to assume that all intel is shared? i.e. what an SL sees is what the "Armchair general" sees? Secondly, how does this affect the players in the lower level? I see alot of eye-candy for the high-level leaders, but does this mean that the players are directed in such a fashion that mimics real life orders? or is it the built-in waypoint system (which in veteran mode is pretty useless)? [EDIT] I like the waypoint grab and drag ability btw.. very cool

They must have changed something. I will see if I can reproduce them. It should certainly be possible if it was in OFP.

Isn't there a civilian pack that has captured soldiers which are basically soldiers without helmets? or is it maybe already a stock unit? I thought I saw it as part of the one the zombie missions use, but it could have been just a regular "captive soldier" in the unit editor.

Sorry for the delay... The group box is a style and is applied to a static control. Other controls are then place on top of it. This is from SoW v2 for OFP (the screens you saw): <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> #define CT_STATIC Â Â Â Â Â Â Â Â Â 0 #define ST_GROUP_BOX Â Â Â Â Â Â Â Â 96 #define ST_GROUP_BOX2 Â Â Â Â Â Â Â 112 class SOWRscGroupBox { type = CT_STATIC; idc = -1; style = ST_GROUP_BOX; colorBackground[] = SOW_Background; colorText[] = SOW_Text; font = SOWFontTitle; sizeEx = 0.04; text =; }; class SOWRscGroupBox2 { type = CT_STATIC; idc = -1; style = ST_GROUP_BOX2; colorBackground[] = SOW_Background; colorText[] = SOW_Text; font = SOWFontTitle; sizeEx = 0.04; text =; }; Whatever you make the background color, the frame will be solid version of it. So as you can see in the pics if the background of the GroupBox is blue, but even if slightly transparent, the frame will be solid blue. If you make your main background completely transparent... the groupbox background white and transparent, you will be left with a solid white round-cornered frame.

um.... Sorry, but those phrases looked like exact opposites to me. Either way, I still stand by my advice that the ability to alter the effects of ESC key is contradictory to the purpose and behavior it was intended for. You can program any other key ('X' perhaps?) to close a child dialog. Why *must* it be ESC?

How about a completely transparent dialog with a groupbox control? You can see them here (green,blue areas): http://community.bistudio.com/wiki/Image:SOW_AE2.jpg The background is not transparent in the pics, but it can be.

Disabling the ESC key would suck for a player. How am I supposed to exit the game should I want to? I wouldn't use ANY dialog that didn't let me ESC. Why do you need to disable it? So you can force them to click many X's? If ESC closes everything, I say let the player learn the hard way NOT to hit ESC if they don't mean to.

You seem to know a lot about internals of other project, some of which are not even released yet  . I go by what I have available to read about I'll admit I play the role of investigative reader, but I can conclude certain facts to be reasonably true. I am merely pointing out an observation and suggesting a perspective. I certainly do not mean to put down anyone's work. Points well taken, but it seems we have more interface related progress than otherwise (in terms of immediate usefulness). From an engine development standpoint, what's easier to modify should the need arise? the core features API or the interface API?

Excellent initiative. I think you're on your way to making some great stuff. I would like to provide a counter-argument however. Please understand I respect everything you've worked very hard on so far. (I love your dialogs btw). I think you are approaching things from the wrong angle. In fact, I think a majority of people in this community trying to provide a more cohesive and modular structure are doing things completely wrong (CEX included). You should build the framework before the dialogs. The framework should be based on communication. Once you have that laid down, the dialogs (UI, etc..) should fall into place. In fact, the comms should not rely on the UI at all. I should, as a mission maker, be allowed to create an action, a dialog, OR an automatic call within a script to perform the same function within said framework. If you can get a solid way for the AI to talk to players and vice-versa, you don't need half the scripts you have created.

As above said... don't make it public. Post your remote IP on your website in a registered area. Password the server even. Require TS presence or the admin kicks. I play on a server that does this very thing (except it's publicly listed). We've been having a great time. I find it quite contridictory to have a PUBLICLY LISTED server only to jail it up so only an elite few can get in. It isn't the purpose of public listings so that PRIVATE servers can have their ++=[uBEREliteClan]=++W3R0cks0rzSevrer.ButtzU.KantG3t1n clogging up my browsing.