Cross platform client in addition to server?

[Cross platform client in addition to server?]

Yes, do it BIS. Why do you force us to keep a Windows operating system installed, is beyond me... Well to be honest I can't call the Linux distributions for example to be easy enough to use and maintain for them to really become mainstream so that's the catch. But it wouldn't hurt if you looked what you can do for it. Like a wrapper for your DirectX calls, bind them to some other libraries instead. If that's not possible feature-wise then that's bad.

I would even buy both Windows and Linux versions of your products, just to support you (and see what differences there are).

Thanks for considering.

Baddo.

[House Position #1, #2, #3]

Hi

This comment is from my experiences with OFP. About the problem with AI's not able to go to building when you order them. Some good time ago I experimented with scripts and functions to make AI's take all the pre-determined positions in buildings or some of them. I wrote a function to determine the number of pre-determined positions in the buildings to help in this, so you need not to know every building in advance, like it is in Group Link II for example. Indeed I found out that AI were far from good when it came to buildings. Some problems I found and which must have been noticed by many, many other people too by now:

- If AI is close to the building already, when you issue a move to buildingPos order, they might not move anywhere. If you first order the AI to go some good 20 or so meters away from the building and then giving the order to go into the building then it can work most of the times. But even then it might happen that the AI can be able to not find the entrance point to the building, and then it can get very annoying because you'd have to repeat the "go away then come back" procedure. In a script you could use an ugly looking setPos if you wish.

- AI can go to very weird positions in the building even when you give them the exact buildingPos to go to. They can indeed position themselfs in the basement, when there is no basement in the building. They can indeed go through walls like the ectoplasma or something, in Ghostbusters the movie.

- There should be inbuilt functionality in the game to make AI's rush into a building to hunt an enemy player or AI soldier down. It should not have to be made in scripts. I don't know if this is in ArmA, I doubt it is. AI's can use building hallways at least which are at ground level but beyond that I don't know.

- There should be a function in the game to give us the number of pre-determined positions in a building.

- There should be a function in the game to give us an array of the pre-determined positions in a building.

- There could be a function in the game to give us an array of buildings inside a user-determined radius which have pre-determined positions.

After playing the ArmA demo coop mission a couple of times I can say the AI's move between the buildings fairly good and I even saw enemy AI's come through hallways in buildings to get me. But I can say nothing how it works when you try to order AI's into a building.

I have a distant memory that I saw in an OFP mission AI's coming to second floor of a Nogova building (the big "Town Hall") by themselfs, not ordered but I might remember wrong.

Hopefully this is much better in ArmA than in OFP, if not then BIS must seriously do something about it. We should not have to write scripts and functions for getting AI's into buildings for example when they notice that you, the player, are in the building or when you want to garrison a building. Such features should be built into the game.

BR,

Baddo.

Edit: modified a "would" into a "should".

[pathfinding of AI in cities is horrible]

In the coop mission of the demo I have noticed some things. I have played the mission on my own, with AI soldiers as team mates.

For two times now the enemy AI soldiers have surprised me by coming to get me through those buildings in the city which have a hallway to walk through the building. In both times I almost pissed in my pants because the suprise was so big. On the first one I was going to go through the building but quickly decided to "back up" because of seeing that I wasn't alone in the building. Using a pistol in such close combat situations seemed to be quite good strategy. Almost pissing in my pants is a positive thing at least for me when I play games. This could happen in OFP too but there it was very rare, according to my memory. I mean, the thing that AI's go through buildings without ordering them to do it.

On some of the sessions in the coop mission, I decided to use the pistol to my advantage and it worked quite well. I was behind a brick fence and shot the enemies from a hole in the fence. The enemies were running on the other side of the street and it was easy for me to use the pistol and take them out. To the point when 3 enemies came walking on my side of the road (close to the fence so that I could not see them in time) from that hole to my side of the fence and I had to reload the pistol and got shot. It wasn't the smartest route the enemies took. A much better route for them (which human players would have chosen) would have been to go round some buildings and surprise me behind my back because that side was not covered by my team, and also because I had killed their team mates into that part of the street so it is not the first idea that comes to mind that you walk right into a zone where your team mates are getting killed one after other. Now the AI had some serious casualties, when they could have had none in taking my character out.

A BRDM has got stuck in a fountain, or some other similar object in the city for two times now, in separate sessions. In both times the BRDM was positioned exactly similarly. That is a serious problem, even if the mission makers put not-so-good waypoints, the AI's should still be able to avoid objects which cause them to get stuck like that. I might go and get a screenshot of this problem if no one else confirms this (and if I can get such situation arranged again). It might have to do something with my team attacking their troops on the other side of the city and the BRDM decides to turn and come to help but does the turning in a bad location (no junction in that spot, just a little bit wider area with some fountain or similar object).

About the AI team mates: they have surprised me with their ability to follow me in between the buildings. I think they are actually quite good in making their way through a city (the city). I might not have seen enough but this far I am positively surprised of the AI soldiers' ability to move between the buildings.

It is clear that the AI could be much better when there are lot of AI soldiers close to each other, though. Then it can get too much time for them to figure out which way to go, and then they can take somewhat stupid looking directions when they start to move. I guess when there probably are not so many paths the AI can take, they get serious problems when many of those paths are already taken by someone else.

Offtopic, sorry. About the weapon selection in the demo coop mission: I noticed that the M4 is not a good choice for a weapon, I equip the team with sniper rifles and heavy machine guns + pistols and that seems to be the most playable choice, and most "productive". The M4 is simply too hard to use. Looking through its scope feels bulky and, annoying? The red dot is too big as someone said on some other thread (1024x768 resolution). Or then, if it is realistic then keep it that way.

[The Iraq thread 4]

Hi

I have never visited the United States of America but I read much about it and am actually quite interested in what exact freedoms and rights they have over there which I don't have over here, which I would need?

I'm just curious, please educate me. The Yankees advertise their freedoms and rights so much that I feel like it is a responsibility for me to find out what all the talks are about. This far in my life no one has been stopping me from doing anything I have ever wanted to do but if there is more then let me know please.

Best Wishes,

Baddo.

[Identical file's in ArmA PBO's]

Hi all

It would be ideal if there were a resource manager in the game which would allow only one copy of resource data to be loaded into memory. From what Suma says we can say there isn't such a strict system in place.

One reason I can think of why the system is like it is can be that the resource manager relies only on checking the full path of the resource file, and it is not checking if the particular file is already loaded. When I say full path I mean the path from the game's root directory to the resource file. Then there will be multiple copies of the same resources in memory of course: if you put texture.paa to x.pbo and to y.pbo and load both of those pbo's then texture.paa would be loaded two times because their path is different even though the file has exactly the same name and data. I assume from what Suma said that this is how the resource system in ArmA (and in OFP) works. There could be an unjustifiedly big performance hit during loading of the resources if you wanted to always check if resource data you are about to load is already loaded among the thousands of resource files. ArmA streams resources from hard disk drive when needed and it is easy to say that you don't want to put too many checks in there to slow the streaming.

This doesn't still tell much about why there are multiple copies of the same files (equal filename and content or just content) distributed with the game. I happen to have experience in handling very large 3D model assemblies. I'm talking about thousands of 3D model entities combined under one product file. Multiple entities in such an assembly can reference to the same 3D model file. In an ideal data hierarchy we would only have one single file for one single 3D shape. "Why it is not always strictly required in practice, then?" you ask. In practice it is often not a good thing to aim for, let me explain why.

After working with large model assemblies for some time it became obvious for me that there can arise serious problems if you try to enforce a strict rule that you must at any one time have only one 3D model file of a certain 3D shape in the data hierarchy. I will tell you what the problem is with such a strict rule. If assemblies A and B contain exactly the same 3D models (the models can be positioned and orientated in the assemblies differently) it sounds ideal to share the same model files between the two assemblies to conserve hard disk drive space, and RAM when loading both of the assemblies in the same time. But what if we need to go and modify a certain 3D model in assembly B, how can we know that the modified model still fits into assembly A? We must open and check assembly A of course! And if the modified model is used in many other assemblies too, we need to check them all. That isn't what you want to do when you only modify a file just a little bit, I am sure of that. Practically this means that you can not go and just modify the model file without knowing all the places where the model is used, and without checking if the model still fits all of those places after the modifications are done. It is much much easier, safer and faster to just make a new file and modify that. Then you can tell for sure that you didn't break any old assemblies with your modifications. And if you use an existing 3D model (which you need not modify) created by someone else, how can you be sure that your model assembly will stay correct over time? You can't! So the problem with sharing data between many entities is that it can create tremendeous dependency problems which can be a nightmare to fix after the damage has been done. Even if you modified a file "just a little bit" it doesn't matter if it breaks the whole thing. In fact, in the industry my experience is from, it is not at all exceptional to create new copies of all the existing model files when creating a new assembly, even if only a few of the files need to be modified. That way maximum safety and flexibility is achieved. Standard model libraries are a way to improve the situation. In standard model libraries no one is allowed to modify a model after it has been accepted into the model library. But I think data files which are never allowed to be modified after initial release doesn't fit well into games, especially if we expect the game to be patched into better. It is very possible that there are duplicate data files in the ArmA distribution just to avoid dependency problems which would create unjustified maintenance workload.

I'm sure you can imagine how all this fits into the data hierarchy used in OFP and ArmA. The same problems are there if you require that only one single file of one single shape/texture/whatever data (which is used in many different places) is in the distribution. It would be desirable though if the BIS developers aimed towards the ideal data hierarchy, even if it means more work for them. In my example the files are not distributed to end customers but with BIS products it is so. There might be other main reasons for BIS to do their system like they have done it, but avoiding a data hierarchy with a lot of dependencies between different data tree branches is for sure a good bet.

Best Regards,

Baddo.

Edit:

...identical data in the same directory? Then the theory of avoiding dependencies between different data tree branches is not that likely to be the reason! What is up with that, BIS...?

[Joysticks. A question for BIS.]

Back when OFP first came out they removed manual fire in a patch they released, and I fought long and hard to have it back. In the end we got back manual fire but I had to fight hard for it.

Thank You!

My hope for ArmA, way back in the old wish list thread, was that controller sensitivity be allowed to have different settings for different vehicle classes.

Now that could be a very good thing to have! Sounds like it wouldn't even be hard to do, just more work for BIS if they care to do it. If not for ArmA, then for future products they should consider it. There is a danger that you could ruin the different feeling between a light vehicle and a heavy vehicle then, though. If you, by adjusting controller sensitivity differently for different vehicle types, achieve a feeling that a heavy vehicle has the same inertia as a light vehicle then that's away from realism, but it would be the players' decision then, of course.

Best Regards,

Baddo.

[Arma under Linux]

Hi GBee,

could you please give some more information about how you got DirectX games perform much better under Linux than under Windows? What games are you referring to? You must have done some comparisons on both platforms for some games to come up with that argument.

I ask only because this is an interesting subject to me as a Linux user. I have used Linux for some years now but I never took it seriously when talking about games written for DirectX because of knowing that there must be an additional layer of indirection (indirection usually doesn't boost performance).

Thanks,

Baddo.

P.S. If anyone has managed to get Armed Assault demo or full version somehow working under Linux then let us know about it. Information about performance against running it under Windows is also welcomed.

[Single player Demo]

Well I have played the coop mission in the demo alone a couple of times and there is no problem at all, the opponents are AI and the other team members are AI too, and are in fact quite good fighters so I see no problem with it. Practically it is the same as if you played a "normal" single player mission.

[Demo today....WOOT]

I recommend updating to the latest DirectX. There is no reason to install old versions.

[Modyfied Demo MP Missions]

I don't believe bis would make the demo editable, nor want it to be edited.

I fully agree. There is no doubt about BIS not wanting us to start modifying the demo or adding content for it so, if it is not possible then it is perfectly OK for me.

Baddo

[Modyfied Demo MP Missions]

Hi

I used Kegetys' cpbo and unRap to examine the demo's files and those programs seemed to work without errors.

I couldn't get a modified MPMissions.pbo loaded into the demo. Must be the .bisign file in the way, it obviously includes a checksum of the .pbo and if you go and modify the .pbo then the checksum doesn't match anymore and your .pbo gets rejected. Removing the .bisign file did not help.

I'm curious if someone has found a way around this little problem (other than buying the game). It's OK BIS, we are all going to buy the game anyways so you're not losing anything

How are the mission pbo's made in the full version? Does the mission editor create a .bisign file when you export a mission as a pbo, or is the .bisign not needed at all there?

Best Regards,

Baddo.

[RIP Turkmenbashi]

May His soul rest in peace.

I hope the people get to choose a new President themselfs, in a free election.

[Merry Christmas]

Hyvää Joulua!

[Firefight Sounds]

After a couple of sessions playing the demo, I have started to really like the firefight sounds. If I walk some distance away from where the action is going on, the sounds are pretty good imho. The M4's plus BRDM were firing some distance away and it sounded very good! I was getting worried of my team mates, the gun sounds were popping way too much in their direction...

I need to get some more experience on the subject until I can give my final judgement, but this far it seems to be well done.

In OFP's FDF Mod the RK-62 assault rifle sound was in my opinion very close to the original sound (I have experience with RK-62). I'd say that in ArmA it can be even better so I hope the FDF Mod team is busy preparing to get their work converted to ArmA

[The Ideal ArmA System]

Yes this is very interesting topic, I need this information too. I have an old Athlon 1.4 GHz and Geforce 6600 GT system and if I am going to play Armed Assault then a new computer is a must. But I won't do any hasty purchases, this needs time, consideration and advice from Armed Assault players to get right.

Currently the Geforce 8800 graphics cards are way too expensive, even if you have the money, to be a reasonable purchase (I'm not saying I won't buy such card with today's prices but I try not to).

For the processor, it currently seems that only the Intel Core 2 Duo processors are worth of purchasing, but their price could come down a bit too. Hopefully AMD will soon release some competitive products with lower prices than the Core 2 Duo line has.

I will delay buying new hardware as long as possible so that A) game be released in my country B) hardware prices hopefully go down C) BIS has had the time to make some patches for the game before I get into it. As playing games is not what I normally do and Armed Assault being the only reason to get a new computer, I have no rush into buying hardware.

It would be very helpful and appreciated if the people who have Armed Assault running fine would post their system specifications here. Also people who have had problems with certain kind of hardware (not with old but relatively new hardware) could post their information.

Edit: There seems to be an existing thread for this kind of talk: http://www.flashpoint1985.com/cgi-bin....3;hl=pc

[Demo today....WOOT]

Dear All,

I tried the demo on this kind of system:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">Athlon 1.4 GHz

768 RAM

Geforce 6600 GT 128 MB VRAM

4xAGP bottleneck

WinXP Home with latest updates from Microsoft

DirectX9.0c "some edition"

This system does not fullfill the minimum requirements set by BIS, so low framerate and graphic errors mentioned below are not complaints, just observations what happens on a system like this.

Lets see what happened...

When trying to start the demo for the first time I got an error that file d3dx9_30.dll is missing. OK so there is a need to update DirectX then! No problem I can do that by downloading the latest DirectX runtime from Microsoft Downloads website (no need to go to a 3rd-party website to fix this, better download straight from MS). I think the readme of the demo has an error, or at least very misleading text when it says:

Quote[/b] ]DirectX 9.0c August 2006 edition (included with demo)

included with demo well for me the installer did not install or upgrade DirectX so clearly the readme was trying to fool me into thinking something which was not true, or did not work like intended. Maybe the installer sees that some version of DirectX 9 is installed so there is no need to install a new one, even if the installed version is not recent-enough. Only BIS knows.

OK now I got DirectX upgraded and yes the demo started quite nicely. Loading times were not too long. At this time the demo had 800x600 resolution, which it had determined to be good for my system. I switched it to 1024x768 though, to see an improvement. Then off to start a mission! Well I chose the coop mission and looked around at the start and everything looked just fine, except the frame rate was way too low to do anything close to playing. So back to 800x600, then! Well... what happened next was some very fancy graphics effects: all the buildings in the view crumpled into weird shape and some even lost textures completely (turned white). Well doesn't look good at all at this point... then I switched back to 1024x768 resolution and expected a change to even worse but no, it mostly stayed the same this time, all the buildings were crumpled and some of them were completely white. Also the ground looked like it was on the lowest level-of-detail it can go down to. At this point I was thinking, this system is just way too bad to be able to run the ArmA demo.

After a thinking and drinking break I restarted the demo. Now it was right from the start in 800x600 resolution and you know what? Things started to look just okay in the mission! It could even be played! Now things started to get warm... okay the visual quality is not good because the settings have been tuned down but hey it can be played! I had two pretty long-lasting sessions in the coop mission and I didn't run into any weird errors or problems with the gameplay (other than trying to keep my character alive). When a BRDM starts moving the framerate drops quite significantly (can't give values, didn't measure) but when the vehicles do not move then the framerate is acceptable, when it is known in advance that this computer is not anywhere near of being actually capable of running the demo with decent framerates. It is not possible for me to judge the quality of the gameplay or the visual quality with this computer, but I can say the demo is giving me a good feeling of what ArmA can be on a better system.

Thanks for the demo, BIS. I'll look forward playing the full version sometime next year with a much better computer.

Cheers,

Baddo.

P.S. I played on my own, locked server. No other players in the sessions.

[PC Discussion Thread - All PC related in here.]

Well some time ago I changed motherboard to a different make and model due to a failure in the old motherboard. The computer has both Windows XP and Debian GNU/Linux installed. Windows XP gave me Blue Screen of Death in reboot. Debian gave me a nice startup, everything worked fine except hard disk drives were working in a slower PIO-mode instead of faster UDMA-mode (that I got corrected, forgot how). So a motherboard change can indeed make booting into Windows much harder... I think it's because Windows expects to see the same chipset in the motherboard that was there at the time of installation of Windows, and if it is not there, problems will arise. But a Linux with a generic kernel (not compiled for a certain chipset only) will detect the chipset when booting and thus has less problems, if any. This is only speculation about Windows, I don't know for sure if it will detect new chipsets or not, but it certainly didn't do it with my computer.

[official complaint to BIS]

I understood very well what they were saying. I was not directly referring to them only, there are other posts around these forums too.

I believe that at BIS, there are no special development team for the "dev tools" but they are the same people who work with the game engine. Probably there is no ready "dev tool" package to be released right now, so somebody must do some work before a release can happen. I'd say, work on the game engine and not on the "dev tools", if you have to make a choice.

Thanks,

Baddo.

[official complaint to BIS]

Sorry I can't do anything else but cry and laugh at the same time when I read the posts you guys are making here about how BIS should do their job – I mean come on now, people, â€GIVE US THE DEV TOOLS AND THE COMMUNITY WILL FIX THE PRODUCTâ€!? Stop that ******** talk right now! BIS is supposed to be a professional software development company and not a bunch of hairy and smelly open-source maniacs who release a half-***** product and then give it to others to finish it. Do not encourage them, in any way, to become hairy and smelly open-source maniacs. I repeat: do not encourage them! Did you understand?! If not then read again until you do. And the talks about â€it is enough for the engine to be good, rest is not that importantâ€!? Hey what if I were a car manufacturer, sold you a thing that looks like a car and walks like car but doesn't really work like a car when you try to use it for what a car is meant to be used. Then you come cry to me that this car you sold is not working, what's wrong? Well hey I could then say that â€Yeah but the engine is perfect isn't it?! See, here is a drill, here is an angle grinder, here is a welding machine, here is a hammer, here is a sheet of steel, build the rest of the car to look and work like you want I am out of here bye!†Now, how does that sound to you?

Oh by the way, I have not seen the product and thus I will not judge it. I can only judge the product after spending countless of hours crawling under trees, watching out for enemies and freaking out when they surprise me with my pants down – until I have done that plus something else I don't know about yet, I can't say anything about the quality of the product. If the product gets me sucked in like Operation Flashpoint did, then I can start talking about the quality.

What really sticks to my eyes here in these forums is the unbeliavable attitude of many people who are saying that the community will fix the product if only they get the â€dev toolsâ€. Now, in your dreams maybe that will work, but in the reality it is not an option. Step down from your fantasies for a moment and look what you are saying. I think when you are asking for the â€dev toolsâ€, you are only talking about wanting to get the community adding more content to the product, but that is totally different from fixing possible bugs in the 3D engine or in the scripting engine, you name it, I don't know what bugs there are in, if any. If BIS rightfully thinks that fixing the possible bugs in their product is way more important than rushing to release some â€dev tool†package, then I thank them very much for being such a professional team which actually plans what they are doing.

If this post offends you then good. Maybe it is needed to get you realize what you are saying, what kind of backhanded favour you are making to BIS when you are talking about community fixing their product. I think that the worst thing BIS could do now would be to trust the quality of their product into the hands of the â€communityâ€. Fixing the product is BIS' job, and they know it **** well because they are not hairy and smelly open-source maniacs, they are professionals. That's why they are working their ***** off trying to improve the product. Now, give them pros some time to do their job and stop harassing them. I have full confidence in BIS that when I get the product some time next year (I don't care much exactly when, take your time) it works well and it sucks me in, just like Operation Flashpoint did.

Thanks,

Baddo.

[What do you *HOPE* will be in ArmA modding?]

Well... as I don't have ArmA yet (possibly a very good thing ;) I can only speculate what could work... of course The Mod of all times, FDF Mod should be converted. Of all the addons and mods I have tried over the years, FDF Mod has been and still is the most balanced and working mod. Many other addons and mods are simply unsuitable for good gameplay because of not balanced configuration values, or create too much load for the computer, making especially multiplayer sessions an unpleasant experience. Yes it is true, my opinion is a little bit biased 'cause I belong to real FDF reserves but I can't hide the truth can I? It's still teh best mod out there and it would be a shame if it wasn't converted to ArmA. Most other addons just don't give the same feeling of realism. Maybe it has something to do with the fact that I fired the assault rifle RK-62 many times in reality and when I go do the same in a game, it gives me such a great vibe that I must go back once in a while just for the kicks. The quality of weapon sounds in FDF Mod still impress me (raises hat to the sound team), the sounds do sound realistic I can confirm that for sure. There is some serious talent in the FDF Mod team which should be kept utilized.

After FDF Mod has been done for ArmA, then we would need troops from other countries with config values matching close enough to the FDF Mod config values. Bundeswehr Mod is also very promising and it should definitely be co-ordinated too with the other quality mods to get the configs close enough to allow enjoyable gameplay. Also I think a good quality mod modeling the Bosnian War during the 1990's would get many fans from Europe and from North America too. It was quite unsecure and frightening time even up here in Finland, you could never say how much the war would spread out from there (like happened before) or would it just stay as a local conflict.

Thanks,

Baddo.

[Some ArmA tools]

Great work

One thing about the Paaplug: it would be very, very nice to be able to use this plugin in GIMP (http://www.gimp.org/). For those of you who are not familiar with GIMP: it is a free open-source alternative for Photoshop.

I had a look around and couldn't find a plugin hack which could make Paaplug work in GIMP. There is a Photoshop-filter-plugin-to-GIMP hack called pspi (http://www.gimp.org/~tml/gimp/win32/pspi.html) available but that doesn't help with Paaplug, it handles different type of plugins.

Please help us poor GIMP users and port Paaplug to GIMP, for both Linux and Windows.

[trigger for spawning]

This is even further complicated by the fact that the created unit isn't returned when you createunit, meaning you have to figure out which one he is the hard way.

I think it is not a very hard way to get a variable pointing at the spawned unit by initializing a global variable in the init string of the createUnit function... it is no more complicated than if the function returned the unit.

You do either this when you only want to access the vehicle from the same scope only (a script for example):

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">_bemu = "BMP" createVehicle getmarkerpos "BDO_ruskibase"

or this when you want to access the vehicle from the global scope:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">BDO_bemu = "BMP" createVehicle getmarkerpos "BDO_ruskibase"

or this when creating units (now we must use a global variable):

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">"SoldierECrew" createUnit [getMarkerPos "BDO_ruskibase", BDO_geoutrobmp, "BDO_bmpdriver = this;removeallweapons this", 1, "sergeant"]

In the last example we get global access to the created unit via the BDO_bmpdriver variable.

[Keyboard input problems]

A shot in very dark: try to adjust the character repeat rate and/or delay.

I am lucky enough to not have ArmA yet so I don't know what settings, if any, are present there for keyboard speed. But try fiddling with the Windows keyboard settings.

[Passing Variables By Reference]

Hi,

just a thought about the "how many rounds in mags" problem: in my opinion it does not matter at all for the gameplay if you give re-spawned AI units full magazines even if they had fired some rounds already. The players will never be able to find out how many rounds there is supposed to be in enemy soldiers' magazines. Only if you see the enemy soldier all the time right from the mission start maybe then you could count how many rounds were fired but this is about re-spawn so that can't be the case or can it

It might be a different matter when you are dealing with player groups. Maybe even then trying to count the rounds is wasted effort.

Edit: Well at another look at kutya's post it seems like he's only talking about the number of magazines, but can that really be a problem shouldn't it be fairly easy to find out and restore later...? But then again it still doesn't matter if it is not about a player group.

[Partial Visitor Translation Patch]

I think this program could look like a virus to the virus scanners, because it modifies another program and that's what rootkits and other such crap created by complete morons tend to do. Or because this program is based on some common cracker program template and gets flagged because of that.

I ran a scan to the file using newest F-Secure and did not get any kind of warning. I did not get any warnings from F-Secure scanner about this program at the time of my first post into this thread either.