Jump to content
Bohemia Interactive Forums

baddo

Member
 View Profile  See their activity

  • Content Count

    1295

  • Joined

  • Last visited

  • Medals

Posts posted by baddo

  3. Posted

    None!

    Why can't people just get along with each other.

    And stay out of my country with your guns, tanks and your "superior" ideologies of how to run a state/live a life or  pistols.gif

    If your way is superior to my way, I will eventually notice. No wars needed to make me notice.

    Just understand to stay out and all will be well.

    If I need military help from you, I will ask. Don't try to force help upon me. I will do the same for you.

    ArmaVidz, unfortunately the "clear roadmap" about WW II is not so clear in my opinion. There are a lot of things presented wrong and many things are on purpose not mentioned. I'm sorry I will have to keep my specific opinions out of this thread, but there are lots of things under debate about how the history of the WW II should be written. I would say that it is far from a clear roadmap. The roadmap depends on who you ask. Each side writes their own history books, either honestly as they think things were, or lying. Soviet propaganda is a good example of not telling the truth to their own people. I think in modern-day U.S.A. things are not much better regarding how the government tries to justify their actions in front of their own nation.

  4. Posted

    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.

  6. Posted

    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.

    Quote[/b] ]8.1 What is SLI?

    When the two graphics boards are then linked via an external SLI bridge connector, the driver recognizes the configuration and allows you to enter SLI Multi-GPU mode. In SLI Multi-GPU mode the driver configures both boards as a single device: the two GPUs look like a single logical device to all graphics applications.

    ...

    Note that running in SLI mode does not double available video memory. For example, plugging in two 256 MB graphics boards still only results in a device with at most 256 MB of video memory. The reason is that the driver generally replicates all video memory across both GPUs. That is, at any given time the video memory of GPU 0 contains the same data as the video memory of GPU 1.

    ...

    When running an application on a SLI system, it may run in one of several modes: compatibility mode, alternate frame rendering (AFR), or split frame rendering (SFR) mode.

    Compatibility mode simply uses only a single GPU to render everything (that is, the second GPU is idle at all times). This mode cannot show any performance enhancement, but also ensures an application is compatible with SLI.

    For AFR the driver renders all of frame n on GPU 0 and all of frame n+1 on GPU 1. Frame n+2 renders on GPU 0 and so on. As long as each frame is self-contained (that is, frames share little to no data) AFR is maximally efficient, since all rendering work, such as per-vertex, rasterization, and per-pixel work splits evenly across GPUs. If some data is shared between frames (for example, reusing previously rendered-to textures), the data needs to transfer between the GPUs. This data transfer constitutes communications overhead preventing a full 2x speed-up.

    For SFR the driver assigns the top portion of a frame to GPU 0 and the bottom portion to GPU 1. The size of the top versus the bottom portion of the frame is load balanced: if GPU 0 is underutilized in a frame, because the top portion is less work to render than the bottom portion, the driver makes the top portion larger in an attempt to keep both GPUs equally busy. Clipping the scene to the top and bottom portions for, respectively, GPU 0 and 1, attempts to avoid processing all vertices in a frame on both GPUs.

    SFR mode still requires data sharing, for example, for render-to-texture operations. Because AFR generally has less communications overhead and better vertex-load balancing than SFR, AFR is the preferred mode. Sometimes, however, AFR fails to apply, for example, if an application limits the maximum number of frames buffered to less than two.

    Quote[/b] ]8.2 Choosing SLI Modes

    Applications in development default to compatibility mode in current drivers (66.93 and later). Application developers can force AFR and SFR modes by creating an application-specific profile in the driver, i.e., in the display driver control panel, click on the GeForce tab, select “Performance & Quality Settings,†click on “Add Profile,†and enter the name of your application’s executable. Then enable “Show advanced settings†and choose “AFR†or “SFRâ€.

    Another option is for the application to programmatically choose an SLI mode. All NVIDIA drivers support a control panel API that lets applications query and set various control panel options. As part of that API the NvCplGetDataInt() entry point allows querying for how many total GPUs are installed and how many of those are currently in SLI mode. The NvCplSetDataInt() entry point lets application set whether the calling application runs in compatibility, AFR, or SFR mode.

    Quote[/b] ]8.3 Avoid CPU Bottlenecks

    If your application is CPU-bound running it on a more powerful graphics solution has little to no performance impact. To take advantage of a multi-GPU configuration, you must avoid becoming bottlenecked by the CPU. Chapter 2 of this Programming Guide provides guidance how to detect and avoid CPU bottlenecks.

    Similarly, if your application artificially throttles its frame rate to an arbitrary and fixed value, then the frame rate cannot exceed that value. Please avoid that situation.

    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.

  7. Posted

    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.

    xmas_o.gif 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.

  8. Posted

    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?

  10. Posted

    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.

  12. Posted

    Quote[/b] ](Not(Alive Vul1)) && (Not(Alive Vul2)) && (Not(Alive Vul3))

    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.

  14. Posted

    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.

  15. Posted

    It's a conspiracy!   wow_o.gif

    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!

  17. Posted

    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  tounge2.gif

  19. Posted

    Yeah... own fault for not recognizing how things are at that location crazy_o.gif

    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.

  23. Posted

    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?

  24. Posted

    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.

×