shinRaiden

Are you sure it's an 8800m and not an 8600m? 86's are quite common, while 88's are still rather rare.

+1 for Linux, I've got my ulterior motives, but the likelihood of it being realized is sadly slim to none.

Indeed. The community is far too fragile at this point to bear the acrimony of religious bully-pulpit'ing comparable to historical locked threads. Those of faith are to an equal extent by the ignorant insults of those who rather than ignore it, prefer to abuse and assault that which they do not value. There is place for fair and reasoned debates. The purpose of this topic however is to question the suppression of said fair discussions and explorations.

Your CfgWorlds child class is stacked correctly, but you are overwriting in CfgSurfaces and CfgMaterials. As a result, you're making a global change instead of local inheritance only.

As a moderator you should be well aware of the significant number of individuals in the forums who are not of legal responsibility age. Furthermore, citing UnrealDevNet is also nonsense because you get tools and references, but not the whole raw content package, unless you front the $350K 'club fee'. Additionally, if you actually browse the Unreal Dev net you will notice that all the black 'public' links require no special 'club pass' to access, which also happens to be the policy at the BIS community wiki. So if you propose controlling access, then you are proposing a 'private exclusivity' tighter than what BIS or Epic are already doing. On the other hand, if you are proposing a full raw p:\ca distribution, you have to be a Gears of War level licensee to get that kind of service from epic.

I see where you're going Miles, and that's a fair interpretation. What I really meant though is the notion of BIS setting up their own private 'club' to control access to the 'privilege' of 'exclusive' info is a subject that's been at the center of some of the most contentious fights on the forums and elsewhere. You still have the problem to deal with on BIS's side of how do they manage from a business standpoint the need for multiple non-revenue positions and infrastructure. -edit- The majority of my complaints here are focused not on the legal issues, rather they have to do with opinions and practices that lead to poor content design. Reliance on content that has legal issues for derivative works also has serious content design complications on a strictly technical level. Imho, it's pointless bantering about assumed past policies and pleading for changes to the stated policies, as the result of that would directly lead to poor content development standards on a strictly technical basis.

Statements like that are in poor form, and are easily mis-interpreted to suggest that BIS is withholding information, which is not true at all. Secondly, it also recommends the segregation of 'elitists', which has been consistently been rejected by the community. To even suggest such is to show a total lack of understanding about BIS or the community, and is directly inviting vicious and destructive community in-fighting. Absence of desired information from the Community Wiki does not imply withholding on BIS's part, rather, in most if not nearly all cases that information might not be documented within BIS. This is a not-uncommon blessing and curse of small development teams, where a lot of 'vital' information remains in peoples heads or in direct communication.

@[APS]Gnat : What DM and I are both trying to explain is that in many cases it's not possible to trade model complexities, and formerly acceptable practices such as 'bolting on' parts to an existing model have a substantial negative cost in performance that was not as noticeable in OFP. @Miles Teg : The Stryker would be a prime example of this problem above. The base model is already one of the more complex and 'heavy' models in the content library. To add slat armor would necessarily add a section penalty. To add slat armor with an absolute minimum impact on the model would necessitate substantially deconstructing the model beyond a basic MLOD analysis. For that and a variety of other reasons, imho it would be more beneficial in the long run for the community to create a new Stryker base MLOD, rather than pursue deriving from the BIS model. This is irrespective of the issues at the core of this thread topic.

As far as derivative works go, bolting on to existing MLOD's is actually a really bad idea. It creates a very high risk of section-heavy models which hurts performance big time. It's a risky and easily abused crutch. As a reference, they can be useful. But bolting on parts, ie a shemaugh onto an existing unit, without incurring a penalty, is impossible unless you re-work the entire model.

I kind of find this whole discussion rather ridiculous, and aside from a big "I told you so" it's rather clear that BIS has no other option than to pursue the course that they have. Let's look at the blindingly obvious facts : This is not what's about right or wrong, it's about what's legal or not. Do you the community member have the authority to say "Hmm, I think I will put ArmA up on an ftp somewhere to download without restriction, in part or in whole"? Can I go and post all or some of the CoD4 data files on an FTP, then make a link to it on Activision's forums? Absolutely not, a copied file hardly amounts to a derivative work. If you insist on a policy of fully free sharing, then you must also condone this. Furthermore, the most blatant examples of this are in direct relation to fundamentally flawed content development processes. Myself and others have endeavored to communicate the best practices as well as we are able to, but in general it has only been met with insult and ridicule, reflecting a general absence of tolerance and consideration; an attitude consistent with the problems addressed here by Placebo. As has been recently discussed here, there was as myself and many others detailed no need to directly edit the BIS configs and re-distribute BIS's content. A prime example of this would of course be the XAM mod, and any other mod that mistakenly thinks that they need to directly edit dta\bin.pbo. or ca\addons\ca.pbo for config-only modifications. The entire purpose of various changes BIS made was so that the community would have a greater standard of compatibility by not having to alter each other's content, instead it was the community that went and screwed it all up by insulting corrections and directions when offered. Another prime example of this problem is the fights over incorrect information about model.cfg content (that directly lead to my 3 WL's.) As is being evidenced with increasing frequency, while placing cfgmodels code into the config.cpp in theory is technically possible, unless it is absolutely perfect it introduces massive cascading problems wrecking content left and right. It was not intended to be a config construct, it was intended to be used as a framework directly linked to the unbinarized models. So vital is this knowledge that the information was one of the first items to be included in BIS's community wiki. So now that I've said my piece, you'll rebut with "but they made us do it, because they failed to deliver on their promise to give us the tools and content and info we wanted when we wanted." Well sorry, but it's not because they don't want to. They're trying, and they've been steadily making progress. The short of the matter is that none of it was ready to go at or before release, and they've been working on it as best as they are able to or know how. Which of course "isn't good enough" for the "I want it now and my way" crowd. That's the basic problem, and this action is imho long overdue. The impatience and impulsiveness of the community is no excuse for bad behavior. There has been far too much scamming, bickering, harassing, and in-fighting going on already. It's high time there be some real collaboration, instead of self-aggrandizement. This here is a great example of that spirit and effort. @granq : imho, content derived from and / including the sample content may reasonably be redistributed. It would be best to have a BIS clarification, but I believe that this was part of the intent of the sample content. @bdfy : The ODOL Explorer developer got raked over the coals by BIS, what more could you ask for? Your impatience does not constitute an emergency on BIS's part. As they have time and resources for non-revenue activities, they are preparing and releasing information. You may think you do not see it, but that doesn't mean it's not there. Also, the problem didn't appear when the content hosting moved, it's been ongoing, but not actioned until now. Anything else is merely coincidental. @Panda[PL] : It's not so simple as just dumping configs. There's some crucial changes to how configs work that are much more complicated to explain, and are not obvious by looking at the configs. Rather, it's structural and relational theories best documented on the wiki. Also, documenting all the applicable parameters is a gigantic mountain of work that only BIS can do. @Maddmatt : The presence or absence of comment from BIS does not equate to a statement of policy or official opinion. Linker_Split had no problem sacking his 'modeller' who was only ripping content from CoD4, how is that any different from ripping from ArmA? As for the configs, as I mentioned, the information you seek is not in the configs, it's in the designers' head's. Dumping the configs won't help there, and the Binarize ones don't have the more detailed addon configs. Shaders are a definite no, as they're tied directly to the precise engine build and opening them would be unleashing a nightmare of chaos. @Tomislav : The design practices and procedures for ArmA and ArmA2 are the same, whereas they differ dramatically between OFP and ArmA. If you follow the bad practices of hacking the arma content, then your content will suffer compatibility-wise with ArmA2. If on the other hand you design your content in an independent context, without any modifications back into ArmA, at the most you're probably looking a a couple lines of config changes and a rebinarization. @kegetys : I've always viewed OFP/ArmA as more of a 'platform' rather than a 'product'. I also don't see a sudden change in policy, I just see a history of lax enforcement due to other priorities. Just because BIS may think that the results of something the community does looks neat, doesn't mean that it then is automatically granted appropriateness. @benreeper : That's ridiculous, no rational justification for that at all.

Why aren't we giving these people a medal or the Nobel Prize for reducing the surplus population, accelerating measures to correct for over-population, and reduction of human impact on global warming?

Agreed Seconded. Motion carried! What they said, ibid. BAS, Combat, MapFact, RHS, WGL, COC, and most of the other successful mod teams used that structure because it works and is the right way to develop content, for reasons that have been well documented elsewhere. However, the issue of the OP is not one of content development management. I'm not going to point fingers and say thief though. Rather, I give a caution against impulsive impatience, and respect. When you say "I want you to do things MY way to facilitate MY interests for MY addons, and I am going to complain if you don't share MY interests and MY development methods", what's the consistent message there? I'm not pointing fingers of blame at you, rather I'm raising a cautionary note to all that before we get grumpy and impatient, we need to chill out, take a deep breath, and remember it's just a game.

I might misunderstand you ... but weird, im running here with 22" CRT Monitor, and with 52" HDCP compatible LCD Hdtv. I can run any DX10 game on both of them. What are those restrictions about exactly?Also, I find it hard to believe that a gaming platform (DX), would require DRM. Aren't you confused with the new driver model and/or Vista's virtualization of about every hardware aspect? @Buzzard: Aren't you one year behind mate? Latest Mac OS actually runs on x86 (ibm pc) hardware. It's just not sold without an Apple supplied PC afaik. Not confused at all. WHY the new driver model? WHY the virtualization aspect? That's because Microsoft couldn't get Windows 95's performance on NT without putting hacks into the executive, instead of cleanly keeping the operating system safely in user-space. As a result, starting with NT 4.0, they deliberately broke the model in laziness or stupidity. That allowed user-space applications the 'license' to muck around in executive space, so that executive space was then unprotectable. As a direct consequence, DRM was also unmaintainable. The only way to guarantee DRM, and get the crucial licenses from the entertainment industry, was to fix that hole. That's what DX10 does. It's not about the shiney, it's about the wrappers. There's plenty of new shiney in Direct3D 10, but the DirectX package is aimed at keeping your fingers out of the video card. That's not primarily about wall hacks, though that's a nice benefit. It's primarily to keep you out of the frame buffer.

That is the wrong way to go, and would expose the system to more hacks, not less. You're right though that the anti-cheat apps rightfully flag intercepts to the DX api, as genericly that's the same way wall hacks are introduced. If you want the ability to have the user manipulate the rendering parameters (aka dxdll) you also must accept opening your rendering system to manipulation. More appropriately, a 'safe' way would be for the video device mfgrs to put in frame buffer capture on the output side, and make a user-mode method of retrieving those frames. However, that is a violation of license restrictions they have because of movie copyright protections. That's the intent of DX10, it's not to make gaming prettier or anything else, the purpose of the new graphics API and libraries is to unify the graphics system so that DRM can be enforced. All of you who bought into the shiney scams of DX10 games are directly to blame for your own misery in being stuck in this mess where you can't view your content from your PC on your monitor because of HDCP chaos.

And you say "Ah, surely you jest". But then you run the numbers on the data requirements needed to uniquely model the sands of the sea, and lo and behold, you discover that you demand the impossible. Meanwhile, a quantum temporal anomaly pops a black hole in your backpack, and out pops a miniature planet populated entirely by time-continuum duplicates of yourself. At least in theory anyway. And it will still only have support for one game controller. - edity - Perhaps I should clarify myself a bit. The picture is not in reference to the blade server chassis or storage systems in the background, rather it was to emphasize the interconnect requirements, as illustrated by this over the top image of a mesh interconnect switch. I've already posted several times in the past how attempting to scale some theoretical detail levels from OFP to ArmA and beyond would result in hundreds of gigabytes or even dozens of terabytes of data, you can search for those anecdotes if you wish. That is an example of stored input data, and I'm skipping over the processing stage as well. On the backend, you have the requirement to create a rendered frame in HDTV, which requires 2.5 to 4.25 times the amount of data as you typically used in OFP. Additionally, you have force multipliers such as normal and specular maps which multiply the processing requirements by more orders of magnitude. PCI-Express, included the forthcoming 2.0 standard, has cleaned up the bottleneck between getting data off the motherboard and into the GPU. However, what about getting the data on to the motherboard? This is largely the reason why we have terrain-streaming in ArmA. For Xbox development, even the classic OFP content was too big, it had to be stream-loaded in. Microsoft ties the hands of the developers, because there are specific requirements for minimal user impact (ie avoid "loading..." waits wherever possible) yet also doesn't provide enough memory for adequate caching. So the trick is to cache the data faster than or just-in-time for the CPU demands. Which brings us back to storage. This is where SSD really shines, because it can do arbitrary reads immediately from any pseudo-sector, as opposed to the latencies in mechanical storage media. However, you still have to move the data through the controller and storage adapter to the motherboard. Sometimes poor performance isn't BIS's fault, and it isn't your top-of-the-line PC's parts' fault either. Sometimes the user is at fault for demanding what is for all practicality, currently impossible demands. BTW, Nvidia lists a Quadro FX 5600 (Shares chipset family with the 8800 series) with 1.5GB of memory, on a single-board dual-slot leafblower. A sign of things to come perhaps?

http://www.bistudio.com/developers-blog/landscape-almost-real-2_en.html Regarding just the terrain it could reasonably pass for a third of the US, various places in western Europe, or even East Asia. Of course you'd need to replace the structures to make it blend better to those locations, but I don't see it looking 'too close to' the Caucasus region.

Ah, but then sony blocked the tools that allow the packaging and transfer of those mods, for the blindingly obvious reason that there's no way for Sony to protect the platform from malformed community content. The unreal team and sony have been going back and forth on this lately, since everyone's mad at unreal for failure to deliver on their launch promises. They've developed, but sony won't let them deliver. Now in all fairness, it's actually more likely that sony's worried about non-revenue content that they can't slice money from. But, the ability for an unknown third party to inject unvalidated content into the public stream inherently allows for cheat exploitation that would ruin the entertainment of the games, and significantly devalue the platform. Suppose CoD4 on the Playstation 3 was infested as bad as Arma is. What sort of impact do you think that would have on the console market in general? The isolation from alteration as a cheat prevention mechanism is one of the advantages of consoles over PC's.

There's a few solutions. 1 - Drive faster. 2 - Drive only at night. 3 - Announce that the AU SAS are fielding a team. 4 - ArcLight. Would make the course more eXtreme too, better media coverage, more $$$ 5 - There's a lot of Kamaz's in the truck division, it could be a matter of soviet national pride to have a soviet army entry and fire off rounds at anything that moves. Who said anything about playing fair? If the other competitor's cars are flaming hulks out there, you win. Seriously though, it's not just empty threats that's concerning. http://www.iht.com/article....lly.php And as much as the government would like to protest, there's a lot of empty ground a long way from Nouakchott and a lot closer to no-mans-lands of Algeria and Mali that would be and has been rather difficult to guarantee security or support in.

They are only flagged as such because it would be impossible to have an entire area destructible - the performance hit would be too great. Give it a few years, however, and it can probably be expected that everything will be destructible. The technology that is there, however, is certainly impressive - non-scripted dynamic destruction. It is only limited right now by hardware. No, it is limited now by hardware, but it more critically is limited now and in the future by the need to set materials flags. Especially if it is built as a surface rendering engine as opposed to a solid model system.

May I draw your attention to two examples? In the video, you note the dynamically splintering plywood panel and structural beams. Additionally, you note the interaction of a dynamic AI entity (stormtrooper) with the overhead dynamic beam. Unfortunately, this implies that this is far from the innovation imagined, and is only an escalation of existing technologies. Take for example the destructible environment of the Source engine. Wait, the environment is NOT destructible, you have to explicitly flag dynamic objects within the other-wise static environment to be destructible. You see that in evidence as well. The board splinters, and debris and decals are spread around, but the background environment is un-modified. Secondly, how does the engine know that a given polygonal form is a grabbable surface or edge? That too has to be defined somehow, either by calculating the feature size, or by manually setting a surface flag. Either way, there is a substantial amount of design work, and cpu load required. All of that points to incidental application, and not pervasive use in the environment. A nice middleware feature, but hardly innovative.

Answer : As soon as we see users who understand what the purpose of the Search Button is, and also competently understand the respective game engines to know just what it is that they think they are talking about. Which is never.

Quoted for shame... 1 - If you talk to Bin Laden, this war goes back to the Caliphate. That's not Bush's problem. If you talk to the analysts, this war dates back to '79, or '48, or '39, or '18, or '14, or any arbitrary date in history, but in any case all of them agree that the present mess predates 9/11 by the number of years of your IQ, which isn't very difficult. 2 - http://www.michaelyon-online.com/wp/a-thank-you-letter.htm 3 - Nice of a myopicly naive socialist like you to observe that I made the exact same point, but for entirely different reasons/context previously. If you want to provide cake for everyone, where is that cake going to come from? Who pays for the cake? Why should they pay for someone else's cake? How do you plan to encourage the compulsory providing of cake for others who might not want cake in the first place? Corruption is often the price of freedom, it is a potential occurrence when people have both means and opportunity. You wish that we enjoy neither. 4 - The only reason Bob Dylan had the money to smoke whatever dope he did backstage was because of the capitalistic democracy you despise. You can either chose to make the world a better place cheerfully by whatever opportunities you create - which is a very bourgeoisie idea - or you can sit on your rear end and complain about the life imposed on you by your idealists.

Bhutto was hardly more of a saint than Musharraf was. Bhutto bought her role after her husband, the prior comrade leader, died after siphoning off untold billions. She was out of the country only because there was an arrest warrant for her for supporting and continuing his corruption. That said, her business is no long in this world, and may the innocents also killed be at peace. The mess in Pakistan is currently a three-way chaos. Bhutto represented the corrupt, but west-friendly business and political groups, as well as a certain set of clans. Musharraf represents a different set of clans, who use the army as their fist to be strong-man of the day. The third element is the clerics with the clans in the north backed by money, guns, and foreign radicalization. The real effect is that this will put the Bhutto-biased elements in the US/UK State Department and Foriegn Office into a confused panic, and will be neutered for a time from adequately balancing the Musharraf-biased defense/intelligence community. Both of those element pairings are opposed to the rabble-rousing of the northwestern radicals and clans, but their operational approaches to managing the entire country have subtle differences. Musharraf wields an iron fist over the mess Bhutto built. Each time that Musharraf has gotten in trouble in the past, Bhutto's raised her head threatening to overthrow the country. Each time that's happened, Musharraf has suddenly cracked down and 'toed-the-line' and busted up the trouble makers with a worrying heavy hand. BUT... before any of you equally biased trolls goes off saying that my indications of bias in DC would be resolved by actions that would warrant you a visit from the Secret Service, bear in mind that what you are seeing at least in US policy is the culmination of over 250 years of institutional policy, not just the actions of one administration. There are tens and hundreds of thousands of people involved in the bureaucratic and myopic leviathan that is charged with policy. Changing one or two people at the top will not change anything. Changing all their minions will not change anything. So freaking out about one thing or another is not going to change anything at all, other than your blood pressure, which is certainly not going to help you or those around you.

OFP was highly unique in that it had a ready-made, experienced, and mature community essentially handed to it at launch, that then went on to work wonders. That is not the same community that we have now, and it is vital to be cognizant of the differences, and the impact that those differences have on the future directions of the product.

Then you lack an elementary understanding of logistical organization and business processes. That $10000 part may only have $1000 worth of materials and components. But also factored into the total cost are the legal fees to maintain regulatory compliance, service and support costs - which can be substantially escalated in various environments, audited quality control processes which cost substantially more than 'normal' processes etc. Several of the 'classic' cases were where the ordering entity required a product that was no longer produced, and required the very low quantity be made in the same contracted and certified process as the original parts. In cases where the original tooling is no longer available, or has deteriorated, this will exponentially increased the costs beyond normal recoup ratios. Finally, standard account practices prevent the bundling of parts for one contracted program to be bundled and 'stealth billed' to an unrelated project. Now to very specifically the topic at hand. Audio in ArmA consists of the following components : * Audio files * Config properties * Engine audio processing * OpenAL system OpenAL, as well as EAX, and DirectSound, have some fairly specific limits on what it can and can't do, ie how many simultaneous files/channels it can mix, and what it can render with crappy hardware. That then determines what the engine can allow out, so the engine has to calculate and cull sounds on-demand along with engine/environment specific flags and effects. The Config files, for optimization, only have specific base modifications to the initial sounds. This results in the very real situation of the audio effect not having a proper propagation envelope, with large ranges potentially outside the 'proper' observation range. Lastly, with the audio files, how do you propose the BIS go about obtaining precision calibrated audio sources, that will work uniformly in all operating environments, in all virtual climes, and with all entity degradation stats?