shinRaiden

I should probably clarify my comments a bit. The lower resolutions showing in the preceding linked doc would be more than sufficient in terms of required fidelity, so according to that model arguably premodeled roads may be more efficient. However, that may be compensated if the fidelity of the shader is reduced to a comparable level. The major point of all this though that you gain significant benefits in development and AI behavior, as well as a reduction in distribution loads of unique road tiles.

Don't even get me started on the subject of splines. I've been pestering this one over the last several years, and it's a pretty critical/blocking requirement, imho, for the reasons listed below. Each time I raise it, the answer back is "Won't work in the context of 50m clipping/collision". I never said I wanted it in that context, and a wide range of applications such as Train and Flight sims proves that it can be done reasonably. In all fairness, I'm not a programmer, but can't it be done in a different context, outside that of 'normal' objects? * This massively reduces the object count related problems in visitor. * This allows for useful road networks. * Vector networks used for spline-based roads could be provided directly to the AI for sensible on-road travel. http://wscg.zcu.cz/wscg2005/Papers_2005/Full/C61-full.pdf

This is why you need to be a programmer to do practical scripting. I've always thought tree and list type objects were 'cool', but it was always frustrating to figure out how to manage them. I expected to manage the content via the control, and always got frustrated trying to figure out how to manipulate the data. Finally someone a lot wiser than me suggested, "Don't use the control for your content handlers, put that all in the backend, and have the control be the interface to your logic, and the logic to the data." For example, this would mean putting index values as the data into your control, rather than putting the data itself. Then, you use the parameters from the control to figure out what to manipulate with your data sources. You logic then determines what the control should look like, rather than the control getting confused as to what to do with the data. Some controls allow you to modify or append the control's data, but in a worst-case scenario, you can still easily blank and reload the control, provided your backend logic is happy.

Contact Laser Shot for official military or law enforcement sales, http://www.lasershot-military.com

If you look at the soldier model I referenced, you'll notice that texture merging alone does not automagicly make things all better, ie head&hands. It can however get you started doing things the right way, and act as a precursor to a full uv-unwrap/re-wrap.

The 'nip&tuck' problem. If you watch the status bar on O2PE RC3, you'll notice one of the items tracked is the number of sections. That's an indication of how the graphics engine will decide to chunk the model to render it. Glomp bits here and there onto a model, regardless of whether they're sourced to the same texture, and you ratchet up your section count. Add disconnected blobs, or map to new textures, up goes your section count. Take a look at sample_models\bisoldier.p3d. You can't really avoid the separate sections on the face and hands unless you map to gloves instead. Webbing is one texture, and equipment two other textures. Total there is 7 sections in LOD1. In contrast, the recent BWMOD repackage of Afrographx's NH90 comes in at GPU-seppukku-inducing ~430 sections. I don't have a copy of the original model and mappings to determine what went wrong where, but even Scar's MI-24 Hind as released by RHS for Arma was no where near that horrendous, coming in only in the low hundred-something range. There really is no excuse for having the section count ~40 times what it should be. This incurs a substantial and unnecessary performance and stability penalty, and questions whether stability and performance problems are truely BIS's responsibility, or in large measure artificially created by community negligence. Additionally, you can use the "Window" menu >> "Resource Library" to rapidly navigate through the list of sections.

Correction : No it is not possible for Arma to interact with an external application or dll. This would require a direct engine modification, such as was required for native TrackIR implementation. Clarification : There exist several community projects, such as kegety's fwatch, dxdll, and soft-th, other's derivatives of fwatch, various arma-specific tools, and of course KFC's tool's for runtime state manipulation. These do not interact with Arma or OFP, rather they exploit defects in the BIS products or in Windows to intercept, monitor, and manipulate engine-level state changes and other events.

So so true people are just retextureing Bis units and a lot of them. They are also not putting the right equipment to the unit or modeling them in anyway, Lost Brothers Mods iv been playing on OFP and would love to play it on ArmA always looking forward to there release keep up the great work New models are lovely I'd also add that attempting to modify an existing model, ie adding and deleting 'kit' in particular, is by most observed samples, very poorly implemented. Improper modeling leads to astronomically high model sections count, with resulting appalling system performance.

Just to clarify, 'packer' modules in this sense are like 'zipped' exec's. It is a common practice by malware authors to use packers as a means of hiding their code from scanners, or also legitimately by developers as a rather futile effort to hide their program's executable code from those who wish to attack it.

For me, SOF2 was a bit mixed. + Gibs. AA-12 Auto shotgun. Various audio clips of people who don't know how to do realistic voice acting of massive trauma. AI isn't as positional-robotic as CoD-series. (ie good scenario designers) A semblance of a plot. Innovative implementation of ideas (open areas, clutter, aerial combat, etc) that the engine was never intended to do. - Invinci-Rambo vs Zombie Gunner Hordes. Mega-loadouts Cloned AI behaviors 'Nade and push gameplay Funnel-flow maps Marginal replayability inadequate gestures Crates ---------- I might get SOF3, after it's been out for a while. Maybe. There's plenty of more interesting things to blow money on though.

Correct, you nailed the problem on the head. The actual report is a different matter, it points to the manner in which the application is packaged, ie it loads itself into memory in a similar way to how many malware packages are also packaged. That's not immediately a problem, rather just a suspicious way of having a wrapper package load another package into the system. The real concern is that not raised in the scan report, and that is the operational behavior of the program. The whole basic premise of this type of application is to monitor a target for a specific activity, then inject a suitable response. As no direct method exists, it can only do this by exploiting malformed calls, or more nefarious means. Functionally, it is no different than KFC apps modifying memory space to change ammo classnames as they are fired, or other such activity. Obviously releasing 'the code' would allow it to be audited to confirm that the application does not have improper behavior or any other nasties hiding in it. However, that doesn't validate that the distributed package actually conforms to the code released. The only way to confirm that, is for everyone to compile their own. And that then swings the nightmare back, in that you have no mechanism to tell if someone else hasn't tinkered with their version to add in much bad things. This whole premise is the reason behind the draconian control systems like WoW's Guardian, Valve's Vac, and fully-implemented client-server Punkbuster. You can't just secure and monitor the target application, you have to secure and monitor the environment that the application resides in. Whether you agree with that or no on privacy grounds is a different matter, I refer solely to the technical dilemma of guaranteeing that there's no leeches subverting the system.

The outtake's aptly appropriate if you unpack the data files

x2. Assholes.... I got it of wikipedia for those who don't know what the US Marines or Navy SEALs are. If you don't have anything good to say than DON'T SAY IT!!! ----------------------------------- Also thanks for nice and supporting things to the other people that are interested. If you're on these forums and don't have a clue what z0mg!RangerDeltaSealsAndMarineNinjas are, you have no business being here, and you might as well go back to where you came from. If you're confused as to what all these addons have to do with depicting, resembling, or in anyway hinting at the real life (what's that?) organizations under the administration of the United States Department of Defense, you indeed are a sorry orphan of t3h intardnet-tubes. Fact is, nobody here gives a rip about backstory or anything of the sort, so skip to the addon-whoring and just randomize what's "uber-kit". Frankly, 120% of the folks here could care less about who or what they are, just make pretty pictures and uber models, slap any sort of label on them, and folks will be happy. Take your work seriously, and you'll be shown the door writ large. Also called a lynch mob, but the community might 'respectfully disagree'.

A few things that stand out to a not very impartial observer : Yes, there was a marketing angle. In fact, that was likely the primary purpose of the endeavor. The difference, was that it was inside sales, not outside. If they were trying to target the general public, as a recruitment or political support tool, then yes, they would have wined and dined MTV-E and everyone else in. So instead, it should be fairly clear, in light of comments in the interview, and the greater global transitions in military modernizations - specifically the training component of the various Future Soldier programs, that the intended 'customer' at this early stage is the internal decision makers, who make the determination if virtual training at the individual infantryman level is an effective training tool, and whether it is sufficiently advantageous in all aspects. In military training environments, they have a limited amount of time and resources to reach qualification in occupational specialties, and as a result constructive squad behavior training as opposed to strictly technical qualifications can be short-changed. The ability to have a deployable, scalable, integrated, and dynamic training platform, has substantial theoretical benefits. However, as expressed in a series of international panel discussions on the applicability of game-based virtual training, there is little or no statistical data that is quantifiable by traditional methods for validating the absolute and relative effectiveness of Game-based training. That's where most organizations are at. Some organizations, such as the USMC and ADF, for logistical or budgetary reasons, have been obliged to accelerate evaluation and deployment compared to other organizations. Across all organizations however, a common problem is the lack of integration into core operational training programs. As a result, in many cases Game-based training can be relegated to 'time-filler' or remedial roles. However, in organizations that have adopted wide-spread deployment of squad-level simulation systems, they have found entirely new training cycle processes that have resulted in substantial statistical advantages over conventional training methodologies. In referencing the term 'constructive simulation', I refer to concepts not entirely common in the larger gaming community. For example, as was evidenced in JerryHopper's report, the functional capability and proficiency of both teams improved dramatically with adequate inter-squad communication. In some cases, that may be the entire objective of the exercise, to assess the squad's communication and coordination behavior, or to evaluate the team, squad, or platoon leader's leadership capability. Another scenario may be to deliberately remove the squad leader without warning, to analyze the team's response. In many cases, traditional gaming objectives such as "clear the building" or "kill the target" are in actuality only the 'story' to give a scenario progression, and are at best only secondary objectives. In evaluating training methodologies, military organizations have very complex and structured analysis protocols. They have established extensive standardized training procedures with validated and predictable statistical outcomes. They know exactly what the attrition and proficiency rates will be for processing x number of y grade units with z time and efficiency. In most cases, when you introduce some "new cool thing", there is not the option to supplement what's known to work. If it works, why do you need to add to it? You don't. So then is the more realistic situation, that if you want to add A, you will have to eliminate B. In that case, the "new cool thing" of infantryman level virtual training has an implementation cost, an operation cost, and a question as to what the outcomes may be. If the profiency or attrition outcomes exceeds prior protocols, by what amount is required for it to be functionally competitive? What is the offset ratio between increased costs and increased returns? Additionally, most of the western nations have made some form of commitment to implement sweeping transitions in their organization, structure, and methodologies. As a result, there is a unique opportunity in this window (2000~2020) to in effect 'reinvent the wheel' with creating entirely new ways of implementing training programs. Instruction can be immersive, collaborative, portable, and all the other buzzwords you care to throw at it. It takes time, but the results are beginning to show substantial rewards. One other nugget of goodness, the whole article in general, but there's special reference on the last two pages. UK MOD Virtual Training

No different than with Arma. The only 'difference' is that the sat and layer mask's are 'scary'-big. Up close, yeah you're down to just detail textures, then it's a matter of creating, selecting, and matching as appropriate. Plus that map you pointed to is a smaller size map, so it can handle proportionally higher detail than a larger map.

Harsh? It's call the search button, and I'm breaking forums rules by posting a friendly explanation in this here duplicated topic. Anyways, the problem is both a problem and a non-problem. The chips were designed with DX10 in mind. You're trying to use DX9 code on them. The chips don't handle either. They expect magic code to come out of the Nvidia drivers. But the problem is that the magic code doesn't work the same for DX9 and DX10. Well, the particular issue is that DX9 accepts data that it doesn't know how to handle, and malforms it, resulting in slow leaks. This was confirmed months ago by BIS and Nvidia. So M$ has a problem. Are they going to fix it? Well no, DX9 and XP are dead, long live Vista and DX10. Besides, everything was working fine until Nvidia tried to send in data that DX9 accepts but shouldn't. So Nvidia's got a problem because their uber DX10 card gets cranky with malformed DX9 code. But if you guarantee a fix in software, kaboom, there goes all your performance. But if you feed bad data into DX, sooner or later you get mud in the system of different sorts. What's the dev supposed to do, work around issues in hardware, API's, and drivers? How about they just wash their hands of this mess and go back to doing what they do best, and that's make games. Let the other guys sort it out. Lastly, it's pointless to harass the OEM's about this, there's nothing they can do to the GPU silicon. BFG makes the card, but that's not the problem. So you're wasting their time and yours for a problem they can't do anything about.

ImageMagick requires an internal conversion of the entire image to a bitmap prior to any other operations. As a result, it crashes trying to convert EMF's generated from maps larger than 12km. Metacon can convert larger maps, but is limited to Windows GDI images sizes, so its output is restricted to 4096^2px

A search of the forums instead of the Big Tub of Spam will tell you that yes, BIS developers have been in contact with Nvidia engineering, and that the principal issue with the 8800's is their different memory management architechture, and the resulting instability that creates when combined with legacy DirectX SDK factors. A cursory scan of the buzzwords bandied about on the standard fanboy tech review sites should have been sufficent warning that severe stability issues were likely to ensue from the memory manager handler change that underlies the unified shader architecture in silicon. That system, incompatible with DX9 and built specifically for nvidia's interpretation of DX10, requires some rather exotic software hacks on the part of Nvidia engineering to maintain compliance with the legacy deprecated DX9 architecture, which is functionally leaky when exposed to the new code that exploits an unanticipated API weakness. Call Microsoft and convince them to shelve Vista, and reopen dev on Dx9. Let us know how that goes.

I was referring to the requests to pester the dev's about this matter. I don't remember where I saw the discussion, and it was probably internal, but 'switching the code on' introduces all sorts of weirdness due to frame rate calculations. My point in bringing this up is that like with the demands for destructible buildings, there's all sorts of 'nice-to-have' things that when you turn them on makes the entire system go 'squiffy'. Remember, you don't have the liberty of concurrency in virtual simulations, so even microsecond linear latencies in simulation make the results go bonkers. That's not to say that it should be just ignored and buried. Far from it, I think it would be a particularly delightful addition - working properly. But I also think that there are much higher priorities, and the community needs to be realistic and pragmatic before they go off pestering people about every last item.

Not likely, don't waste your time. It goes into some really esoteric stuff relating to simulated speeds and frame calculations.

Indeed, you are entitled to your own personal opinion. You are welcome to continue believing whatever nonsensical rubbish you smoke and blow that out your whatever. Especially when it is utterly devoid of any basis in fact or reality.

Bogus. Does not correlate with known BIS IP address ranges, traces back to a personal DSL line in the greater Berlin/Hanover area in Germany.

So they expanded on client-side state prediction and swapped the network over to a p2p model? Spurious prior-art laden patents loom friends... There's several problems listed in the discussion, and various non-solutions : * Lack of upstream bandwidth - Existing workaround is to use hosted servers in a datacenter and not self-host. Solution is slap the politicians upside with the pork-riddled intertubes until they obligate the telco's to meet their decade old funded mandates to deploy usable bandwidth, and provide adequate safe harbor for municipal providers from the allegedly regulated telco monopolies. p2p is not a valid solution, as p2p inherently requires that all nodes have substantially more upload capacity than their nodes nominally have in ratio. That much is painfully clear in Supreme Commander multiplayer games where a n-way p2p model is used. * Interpolation of intermittent states - The work around has been to perform client-side interpolation where appropriate, and gracefully lag out where insufficient. Performing substantial behavioral interpolation well beyond the common bounds, and having those local interpolations be considered valid in a global p2p context, is highly inappropriate and inherently extremely vulnerable to cheating of direct and indirect state manipulatory manners. Proper development logic many times dictates that it is far safer and more reliable to fail a given task, than to attempt to perform a likely invalid operation. This has wide-ranging stability and functionality benefits including anti-cheat controls on a fundamental level.

Meh. Mere market manipulatory machinations. Intel's 'solution' for fixing up the underpowered GPU's they sell to the bottomfeeder market was recently announced to be a software hack to offload GPU tasks back to the CPU. Intel scavenged the remnants of various other tech firms, but it's nowhere near what AMD did when they harvested the DEC parking lot and gave them free reign to remake the K7. That is innovation, and not just marketing fluff. Furthermore, AMD's purchase of a redevelopable IP (ie Nvidia's got too much momentum to remold into AMD's master vision) proposes a much more flexible architecture in the very long run. Havok's advantage is having a mature product, with a robust development and support infrastructure. Aegia's trying to solve the wrong problem (the real problem is concurrent simulation, not scalable simulation) and most of the rest either are not mature or insufficiently supported kits. This will change nothing, except that there is now a couple more pages in Intel's annual stockholder report. This news is far from being any sort of useful or epic, and is only a mere business transaction, shuffling revenue from one corporation to another.

You're missing the point, Walker's getting frustrated trying to explain the simple things to the n00bers here. The basic points are simple : * Unauthorized access to a system, even an insecure and publicly accessible one, can be prosecuted as a cybercrime in many jurisdictions. * The deliberate and unlawful activities of the vermin filth result in real financial effects, ie loss of anticipated usability. If the hosting provider were negligent or in collusion, then they would be liable, otherwise it's just the unwarranted loss of use of the paid for services. * There's libel and slander in there too, but that get's messy, and really is more BIS's turf than the community's. Doesn't matter how sloppy BIS is, when you have the vermin filth dedicated openly to the malignment of a legal commercial product, then there's grounds for a libel/slander case. * Conspiracy to commit all of the above. Now what's the practicality of all this? Meh, pretty nil. There's not enough revenue spread all around to make it worthwhile. That's part of the reason Walker's pushing the criminal aspect. Besides, there's a bigger news item here. Suppose this does all work as a class action civil suit. (There's a couple juicy details that would actually make this very practical imho) You think this is the only game with a cheating problem? You'd have a bunch of lawyers from the other game corps interested as well in helping out. Or if you go the criminal route, you can just start racking up the 'dings' per each hit, then get a plea bargin including a lifetime ban from all computers.