baddo

Well as I already hinted in the first reply, you could try this: Create two objects out of the same object: 1) Configure this object to be a helicopter. 2) Configure this object to be an airplane. Then you would have a script which detects the speed of the object constantly running. The script would change the object between helicopter and airplane on the conditions set by you. To avoid possible performance problems, you should have both objects loaded into the mission at the start. And keep them both there so they are ready to be used at any time. Hide the airplane at the start. When the airplane is needed, take it into use and hide the helicopter. You would set the position, orientation and speed of the airplane object so that the transition from the helicopter object is as smooth as possible. You would also, of course, have to transfer all crew and passengers. Ammo, damage and fuel values maybe too. I don't know how well that would work but at least in theory it should be possible. It's for sure a hacky workaround but waiting for a patch to add this kind of functionality is a tall order. Also as BraTTy mentions you could try forcing either the airplane or the helicopter to act as another by using a script to force its position, orientation and speed. All of these workarounds are so hacky that it will almost certainly bring problems in multiplayer.

So what USB devices do you have? Try removing one at a time, and their drivers, and see if there is a change. What else? Try different drivers for your USB devices, newer or older.

If you go to http://developer.nvidia.com/ and spend some time reading, you can find what kind of recommendations nvidia gives for programming games SLI in mind. Some quotes from nvidia's GPU Programming Guide version 2.5.0. Some things which, according to nvidia, are bad for SLI (GDC 2005 SLI presentation): - CPU-bound applications - vsync enabled - Limiting number of frames buffered - Communications overhead (both cards must have data) My not-so-wild guess about Operation Flashpoint is that it is CPU-bound, thus no performance boost for you in SLI mode. A couple of years ago I changed my graphics card to a much better model but did not do anything else to my computer. Result was that I did not perceive almost any performance boost in Operation Flashpoint. The almost non-existant difference was definitely not worth the price of the new graphics card. But I could run dxdll with it so I got something out of it. BIS could arrange better support for SLI by: 1) Pestering nvidia to add an ArmA profile into their driver. 2) Programmatically force suitable settings. Why not do it? It's all for improving the user experience.

Spamming every thread with "the patch doesn't exist" or "the patch will never be released" does something good? Maybe just go do something else for a while... I mean ArmA is just a computer game, it should not be a disaster for anyone if all support for it ends today. Julgubben kommer Maybe this thread could concentrate on helping XPETIT to solve his problem, and not to talk about the patch. I asked a question from XPETIT in the first reply and he never answered. It could be nice to hear exactly what kind of solutions XPETIT has already tried, so we could think if we can improve on them.

Well security problems came to my mind too as the first reason why not to do it. It's possible with fwatch, if someone modifies it to do evil things and tells users to use their version without giving source code... What if only read access to data is provided? Allow an external application to read the game state. Would this be useful enough?

Isn't it a server setting. Some servers disable it, some don't.

Well I was thinking that an internal tool isn't that important... the game is different. But the tool, if it allows BIS to do their work then that is enough for them. It's not worth to polish it as much as a commercial product. So there could be a temptation to remove stuff which they never really cared to implement properly, before giving it to public release. For example, import/export functions could be only partially implemented for the specific file formats. I do not know. But it could be true that not all properties of the file formats are supported in this kind of tool. As an example of why to remove some functionality from a public release of this kind of tool.

Well me thinks removing features can also be an attempt to reduce the number of bugs in the program, and not an attempt to limit you. If some code doesn't work well, then just remove it. Problem solved. It's possible Â

Try this instead : Not (Alive Vul1) && Not (Alive Vul2) && Not (Alive Vul3) I think the error was that he put a condition into the "On Activation" field of a trigger, as he said he had done. That is not going to work. You just reduced some parenthesis but that doesn't make the logic of this code any different. And I really advice to use !canFire and !canMove instead of !alive, so that the players are less likely to get significant, sudden hair loss.

Yes yes. Instead of hacky non-official workarounds (fwatch and others), some official support could be provided for this? Reasons why it can't be done? Security? Not worth to do by BIS? It should make business-sense for BIS.

Well I've seen it too I think. Your description sounds exactly like what I saw. I think it was some beta patch (1.07?) which gave me "exploded" soldiers whenever I looked at them through a weapon scope. I think then it was not because of graphics card temperature. Of course made the game unplayable. In 1.08 (I think) I got also similarly distorted objects on the whole screen, but that was cured by cooling the graphics card (nVidia 6600 GT). I now am very aware that if I don't arrange extra cooling for the graphics card, problems will appear if I play ArmA for a longer time. So ensure first that you have enough cooling for the graphics card. Open the case of the computer and put a big fan blow right into the graphics card. A fan like those people keep on their tables.

It's a conspiracy! Â Sorry couldn't resist... No-one had local copies on their hard disk drives? That's quite weird... Well it happened with other community websites too. Like with ofpec. Luckily ofpec had at least some kind of backups... I guess this proves that even if you are using a commercial host, bad things can, and do, happen. Backup to your computer and to DVD!

Well if BIS creates only a skeleton of a game... it's only useful for game developers then.

Hehe... well if you want to accurately simulate the gear the Finnish Army had in Winter War... many soldiers brought their own rifles, and many didn't have any uniform given by the state. Situation improved but at first it was like that for many. The Soviets donated a lot of equipment though. If you want to simulate that, then you need to be able to switch uniforms and, well, everything as you go in the battlefield. Imagine it's -35 degrees Celcius and you only have like 2 layers of clothing. You will want to get more if you can get, even if from a fallen enemy Â

Just to note: it was wrong because YOU are the player in your computer, aren't you.

Yeah... own fault for not recognizing how things are at that location When you are among any kind of fanatics then you ought to be careful and not put yourself into unnecessary danger, like calling a teddybear Mohammad? I would say that similar fanatism and extremism is among Christians too. In our lawbooks we have text which talks about "peace of religion" or something like that... don't know if it's translated properly. It says that if you make mockery out of someone's religion, or of a "holy thing", you could get a punishment. Even a death penalty has been at least theoretically possible here in Finland in the 19th century (source: wikipedia). In this case calling a teddybear Mohammad was serious-enough to warrant a punishment.

Try <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">[car1, "Medium"] exec "ied.sqs" Maybe that helps.

Well that has to be an anti-tank mine. I was thinking if someone already made an anti-personnel mine addon. And maybe someone has made a scripting solution for this problem already. I don't know. But make sure you, in addition to this forum, check http://www.ofpec.com/ its forum and its Editors Depot, there you can find lots of good stuff.

I have a hard time imagining why someone would want to take it off in the game. To be able to move faster.

Well I think it could be done within a script. But a trigger could be handy too. If you create a rather large mine field, maybe you could do something like this: - Dynamically detect all mines you have placed by using a trigger covering the whole map, which collects all of the mine objects into an array variable. - Then you would have a script which would loop through the mine array variable, and check if a soldier is near each mine. If yes, then create an explosion in the position of that particular mine. I actually don't think that would be a good method for large mine fields. It could be possible that stepping on a mine is not always detected because the loop could be too slow to detect it. Maybe divide the mine array into multiple arrays and have a separate loop for each to reduce the possibility of not detecting someone stepping on a mine. If you want to improve on this, yes you could create a trigger for each mine. But it depends how many mines you want to have, if it is practical. Are there not any anti-personnel mines?

Check how many indexed positions there are in the building (buildingPosCount.sqf), then have that much AI soldiers, then make them go into each of the indexed positions at the same time. A script with a loop will do that nicely. This way you will see quickly if the soldiers have some problems going into the building. Maybe the soldier is actually in some indexed position, but it's the wrong position? This could be tested, as I said, by ordering a soldier into each of the indexed positions and see if they all get filled up. In my tests in OFP I got apartment blocks filled up by doing that. But soldiers sometimes went through walls, went into non-existant basement, or did not find their way into the building at all if they were initially too close to the entrance of the building, this could be fixed by giving the soldier first a waypoint away from the house, then the order to go into the building. I don't know how much of these problems ArmA have inherited from OFP, but I think you should know these kinds of problems were in OFP and it wouldn't surprise me if they exists in ArmA too.

You are trying to use anti-tank mines against walking soldiers? That won't work unless you script a workaround! Detect when a soldier is close-enough and then boom, with the help of a script.

Well the braking effect feels excessive, especially when there is no visual clues, other than not driving on road, as to why the vehicle is slowing down so drastically. It might simulate terrain roughness but it feels wrong when there is nothing visual to show the player why the speed should slow down so drastically. The vehicle doesn't sink into the ground, no rocks, nothing other than different colour than the road. If BIS continues to develop these kinds of games in the future, I suggest they consider how to simulate vehicles sinking into the terrain (and maybe even leaving deep trails), like when driving on 0.5 m snow. We Northern people would like to have that to simulate our conditions in the Winter, and I don't think others would be sorry to have it either.

Have you tried changing the object on fly? Create two objects, one helicopter and one airplane, then switch between them when needed? It's not clear from your post if you already tried this. You tried some way but what way it was.

I have to add to my previous post that I think that people should direct their efforts into -- hehe, if it isn't coming across clearly enough from my previous post -- creating content which belong to the theme of the game! Create content which doesn't try to make the game be some other game like hmm what comes to mind... there are lots of examples, I think not hard to find for you. People try to replicate movies and games which have certainly nothing to do with a military simulation. Well maybe there is a (small) market for mods themed completely out of military simulation, and I certainly give people the right to create what they want, but isn't it so that the product (OFP & ArmA) can only be complemented with content which belong to the same genre as the original theme of the game does? Creating a monkey-zoo-donkey-mod will in my humble opinion take a sidestep from what the game actually is. Complementing the original theme of the game would give us a more complete product in the end, wouldn't it? Alright, having the sidesteps too can be said to be a richness, so yes go ahead and take the sidesteps, I won't be angry. I just think the original theme of the game would be better to be complemented, not sidestepped. Another thing is, if modders just can and have time to do it, they should try to get voice acting done in the native language of the units they create (for things as big as FDF Mod). A big selling point of FDF Mod to me is that the voices are in my language. Even different dialects are represented! That is certainly great. German, Russian, French, British-English, even Swedish, and what others, bring it on I will play it and certainly will enjoy listening to your language!