Drakkhen

Yeah, noticed it... but what makes me mad is I had this problem once and I don't understand what changed between the two versions of my (now working) first chopper. The fact the problem disappeared means there CAN be a solution. Edit: Well, found something weird there. It's not relative to visual LOD properties. I did a test with the chopper that "suddenly" worked and here's what I've got: I just moved the camera back slowly (tactical view) without changing of LOD (I only have one LOD with the antenna on the tail). And at some distance, before the LOD change, the lights suddenly worked as they always should have!!! Could it be linked to a bad default value of the BIAS of the textures on the model faces? Edit2: depending on the model, the distance -the lighting works correctly- changes (while keeping in the very same LOD). Regardless how far the distance for the second LOD is.

I'm for if the chemical weapons remain poor ones (effects can be stopped if an exposed player is treated fast enough). The problem is the medical/health system has to be more than correct to allow this. Using extreme severity toxins (making the smallest hit lethal) will tend to make the game annoying for some (not me, I would love that but I know my tastes are not all shared).

Damn, I tried to keep around

Regardless of where I am from, it's Central Europe for the variety of landscapes. Muddy valleys, austrian Alps, green fields, a <bip>load of rivers. But CentralEurope is vast. Where is it planed to take place if it does? Bulgary? Hungary? Romania? Ex-Yougoslavia? Germany/Austria?.... ?

You're welcome. I just wanted to be sure that was the real solution before sharing.

Hi, I work for weeks now on a mod for a pack to be released soon (I hoped so) but as I implemented the multi skins on my planes, I faced a strange effect: I put the setObjectTexture script I prepared in the init of the three planes, one being painted with the texture I used in O2 to map the P3D and the two others with alternative skins. The result when I run the game without touching anything is that the alternative skins are simply AWFULLY mip-mapped while the native texture is perfectly detailed. The solution: "get in (pilot)" one of the planes!!?!?? Once it made you change of view (pilot view in the present case), you just can get out and enjoy the real detail of the textures. The "funny" point is I can get the same awfull mip-mapping using alt-tab and wait some seconds before coming back to the game. Then the mip-map from Hell is back again and not refreshed until I move to a pilot place. Maybe is this just a trouble with mip-mapping/fps ratio refresh? Too bad anyway since it will be hard to make the player get-in/get-out at the beginning of the mission just for this... and it'll be impossible if he starts piloting a flying vehicle. The SEPECAT Jaguar A will be featured in the second Air-pack of OFrP.

Faces is the first step like you said Leone, I figured it out weeks before coming on with this thread, but even with that, I had this mip-map problem for the weeks after. To keep the detail level correct, the faces must be sized so that the size of a mapped part of the added face (hidden selection) corresponds to the most detailed face map size. For example: if for a vehicle you use a 2m long face with the half of a bitmap, you have to make the hidden selection face 4m to have the same mip-map level when you'll make the setObjectTexture. The simplest is to copy the most detailed face using each of the textures... but there still can be surprises (unsing a 0,0/0,1/1,0 face I had no more problem while a simple face copy still @#$! up the mip-map) I thought the position of the face was important (since its mip-map level depends on how it faces the camera) but it seems not to be important... it seems. Beware... having those big faces changes the position of the relative generated "drops" (they rely on the bounding box of the whole model, including those faces).

No need now... I found a solution. That works well. You'll see that in the upcoming pack.

Yeah, that is the solution adopted for every current multiskinned mod. Though, I find it strange that because of this little mip-mapping problem we have to multiply the model's number of faces for something that could have been handled using the setObjectTexture command. Strange too that no correction to this has been implemented in the recent patches... let's pray for next patch to correct this Â

I noticed that what make the "get out" able to correctly set the mip-mapping is the presence of hidden-selected objects in the highest LOD that hold the textures used for multi texturing. Without them, get-in/get-out won't do much about this mip-map problem.

Concerning blood loss... I did a while ago a script to simulate that on a unit for a rescue mission (with choppers). So, I played the bleeding man... but the problem with current OFP engine is that when you're hit, you often reach a damage amount close to impossibility to aim/walk, and then bleeding, even slow makes the thing worse. It's hard to find a correct value for the bleeding amout to have realistic dying times. Here's the script I did that doesn't force the state too soon and let the guy able 'til the 5 last minutes. Remove Hint line if you don't want of the time to death pinging. The unit will anyway warn you of his last seconds of life. To call it just put in the init of the unit you wanna bleed: [this,0] exec "NameYouGaveToScript.sqs" (0 is bleeding amount-0=no bleed-10=10mn to death) <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">_me=_this select 0 _bleed=_this select 1 ?(_bleed==0):goto "NoBleed" _s=_bleed mod 1 _m=_bleed-_s _s=_s*100 _bleed=_s+(_m*60) _bleed=1/_bleed #NoBleed _ostat=getdammage _me _NotTold=true _NotTold2=true #Loop ~1 _stat=getdammage _me ?(_stat<_ostat): _bleed=0 ?(_stat>_ostat): _bleed=_bleed+(0.01*(_stat-_ostat)/(1+(random 10))) _ostat=_stat+_bleed _me setdammage _ostat ?(_ostat>=1):Exit ?(_bleed==0):goto "Loop" _m=(1-_ostat)/_bleed ?((_m<30)AND _NotTold):goto "DontLetMeGo" ?((_m<5)AND _NotTold2):goto "ImDying" #EndSay _s=_m mod 60 _h=(_m-_s)/60 _s=_s-(_s mod 1) _m=_h mod 60 _h=(_h-_m)/60 Hint format ["Time to Death: %1h%2'%3''",_h,_m,_s] goto "Loop" #DontLetMeGo _me globalchat "I feel cold... don't let me go" _NotTold=false goto "EndSay" #ImDying _me globalchat "I'm dying... mm... I'm..." _NotTold2=false goto "EndSay"

You're right... game-play needs not being limpy too.

Three levels of medical help would be enough: - first aid (stops most of haemorrhagies but leaves the subject with reduced movement ability and inaccurate) any soldier can attempt one - battlefield medical care (restores movement but not accuracy etc...) only medic can do one - full medical recover -if possible- (restores whole capabilities) only in hospital/surgical units (means you have to extract the subject from the battle field) Only a suggestion.

The medic AI should also subit some medical attention. I mean, the medic role isn't a first line unit behaviour and for the moment, he uses to run and engage just like the others reason why it's often recommended to have a human playing the medic to preserve this STRONG potential in the team. Too strong because of the (too) full regeneration he provides. Maybe could it also be possible to think about some medi-pack the medic could have on his back, filling most of the inventory slots and slowing the unit but possible to drop somewhere before assault. The pack would allow better recovery for the subjects...

First point, they're not french, second point jacobaby simply scared them with his hat

An other great point would be a real modular class management, allowing even the weirdest things like putting a turret on a soldier or whatever not only when you master scripting (which consumes your CPU time for something the engine could have handled faster).

Better collisions. OFP is great for open-ground fighting but finer collisions would improve the close-quarters and urban combat... a style that fits well to a resistance guerrilla standard.

The radio should hold the "com-linked" information allowing the holder or the one next to him to send/receive intel/reco data or orders. The radio destroyed, the coms should be restricted to voice range since there are very few units who really are radio linked in common troops. Thus, the radio could be taken from a dead body by another teammate and requires the leader to be constantly close to the radio holder to transmit orders to his platoon. Yet, in game-play terms, it's an enormous constraint. When the realism approaches fun absence... the border is hard to find.

I think this thread is about damage realism more than gore/not gore. Beside, gore is a simple switch in most games, so, just turn it off. PS:Killing someone without bleeding him is still killing.

Who do you play with? Â Saying [damage localisation/unit control] interaction meant exactly what you're also asking for on vehicles. In fact, to allow more realistic damage management, there could be interesting improvements: - localisation improvement: tell right extremities from left ones, and for vehicles, the natural possibility to deform/change visual aspect of the destroyed parts: tires could be ripped off for exemple (we currently only have a strange dynamic behaviour or some texture changes on choppers/humans). Yeah... I stared at dead AIs to notice that - interaction improvement: A both leg wounded man shouldn't be able to drive a car while he still can try to move a plane (limit the Gs). And above all (that would be great for realistic extractions) the ability for a unit to carry/drag another (that would also suppress the "hide body option" since we should put the bodies in bushes or behind rocks far from patrol paths). Carrying a legs wounded man would allow it to move with its carrier quite as fast as a healthy one, but they're both to be covered since it's harder for them to hide and fire back on agressors Yet, I didn't thought about buildings since they should first be collision improved. I assume it would be "easy" for BI to implement visual and geometry damageLODs system to add impacts and model different walls. Thus, the collisions would correspond with what be see and a destroyed building wouldn't be just a pile of stretched faces impossible to infiltrate and to use as a hiding/camping place (think about those poor sniper lost in the middle of these battlefields full of GI berserkers). Back to the man carrying man... it seems to be already feasible if you know someone good enough in animations and action creation, since a human is already a vehicle. "A vessel for my soul..."

Agreed with that. But it means that many OFP players who enjoy the game ambiance without searching for ultimate realism will be annoyed by some points: - the medic can not restore a unit... save it from Death at most. - most of war wounds will induce a bleeding, that usually ends in a way the wounded wouldn't like to "live". (I'm not one of them but I play with some) I suggest to improve the [damage localisation/unit control] interaction but if it's too much of a CPU calculation, instead of making bleedings... think about NBC feature. "War only feeds war"

A french maybe... Anyway... why focusing on Vietnam? No one went victorious of this war (if some did, the border wouldn't be where it is). There were so many other "little" wars all over the world, the point is to let as many doors open as it is possible to allow the widest mission creation freedom. It sure did the success of OFP.

As I suggested in a mail to BI I sent once... the simple matrix system in the mission editor would be great. It would allow to define alliances like this (assuming there can me more than three sides): In this case we have: - Warsaw forces agressive to both NATO and Resistance side - NATO forces trying to avoid engagement with Warsaw ones - NATO forces trying to help/cover Resistance whenever they can - Resistance forces trying to avoid NATO problems - Resistance agressive to Warsaw forces Something like that, allowing to switch A/N/F (and more if possible) relations between sides would allow more complex mission situations and not to have to create units and change their sides manually in the SQM. In OFP, there were four sides where only the RE columns and rows were configurable (three configurations only), but with such a dynamic matrix, I assume four sides would be more than sufficient.

The two problems I noticed with sounds are (from less to most important): - The sound distance dimming. Correctly managed by some 5.1 cards, basses are kept while trembles fade and localisation gets harder with distance (loss of stereo difference), fine but maybe could it be improved to make the sound fade also on the other cards... if possible. - The soundspeed lag, perfectly rendered with explosions and other short sounds seem not to rule the engine/environnemental sounds of the vehicles. The result is noticeable when you explode a vehicle at distance: you hear the engine stop THEN the explosion. I assume the engine sound don't rely on distance. It's anyway one of the most immersive sound engine I ever played with and I'm sure that OFP2's sound engine will be at least as surprising.

Hi, Â I've searched for an answer to these questions in the Mods discussion forum but it seems no one even cares, so, since the problem also relates to the Memory LOD (gyros)... here's what I was asking for The reason of this is that we have an RPM hand on the instruments @ I guess it relies on an RPM value somewhere in the PC memory, but while there is two commands to get the bearing of a vehicle (getdir, direction), there's no one to get the RPM value. So are these invisible data: - Sight (direction but in 3D vector) - Absolute Z (visible in baro alt) - Fwb/Bckwd control pos (somthin'like -1.0 to 1.0 value) Since I currently work on a plane, does someone know if there is a way to have (like on choppers) TWO gyros? Thanx for ANY help.