Drakkhen
-
Content Count
85 -
Joined
-
Last visited
-
Medals
Posts posted by Drakkhen
-
-
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).
-
Let me guess...Czechoslovakia Â
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.
-
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.
-
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.
-
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.
-
people who like to stop and stare at dead AIWho 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"
-
who'd want to play as the French?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.
-
Ah??? Got the Bronco too but on the version I have, only the HUD lines gyro seems to work. I haven't seen the dash one turning.
Ok for the burner. But it will remain difficult to make scripts using RPM (overheat etc) except if I copy the FDF_Mig21 system where you have an action to switch AB on/off.
I'll feedback this thread if I ever find something with the gyro.
Fly-Bye!
Lod overlapping
in TROUBLESHOOTING
Posted
Hi,
A good picture tells more than a hundred words:
The position light is masked by the model, which is behind it (I even exagerated the distance of the light and the surface to be sure).
I had this problem once, on my first mod, but without understanding what changed, it worked from a version to another. And now, months later, I notice the very same problem on a new model. But this time... it just don't wanna disappear.
I checked the canOcclude on FireGeo, Geo, HitPoints, etc... but it seems to come from elsewhere. The chopper texture is a PAC without any alpha... I just don't get what's wrong.
Thanx for any tip.