Jump to content
RozekPoland

OFP/ACWA - facts | myths | findings | experiments | prototypes | tutorials | protection

Recommended Posts

20 minutes ago, RozekPoland said:

tI0YPH7.png

Nice, but we can fix it and put here. The separate models for anyone who wants to change default ones. I want MLODs to fix them and somebody will binarize them for materials works, that's it. What do you think about it?

Share this post


Link to post
Share on other sites

Wait hold on a second does this means that AI can see trough bushes in vanilla OFP?

 

Also I found this in scripting a while ago but I'm gonna still point it out... and I mean "this" in scripting

 

If you put a trigger in map and add these:

 

Condition : true

 

Activation : player groupchat format ["%1" , this]

 

You will see that "this" returns the name of something random in the mission

 

Now I want to know what this could be used for and i still haven't figured out yet any ideas?

Share this post


Link to post
Share on other sites

HMM THIS LOOKS LIKE AN INTERESTING TOPIC HMM : 

 

 

But seriously there is new findings like how to stop an AI in 1 position without using disableAI "Move" there is a trick to it all you gotta do is check the files

  • Like 1

Share this post


Link to post
Share on other sites

As for a swimming: does anybody tries to add a landcontact piont to the soldier and canfloat=1?

 

UPD: Busted, engine does not handle it. BTW i took the saboteur(blackop) model and a landcontact with a point was already there. Now i am trying some other additions to the model to force our man to swim.

  • Sad 1

Share this post


Link to post
Share on other sites

How to build a proper Forest ViewGeometry (02)

 

What customisation do the forest models require to get on well with the new ViewGeo?

1. Build Geo, FireGeo (and ViewGeo too) components for bushes, tree trunks and other elements of forests that the original models lack of to get the best experience.

2. In case of non-replacing method for implementation of the fixed forest models (if you want to avoid replacing the original data3d.pbo) make sure to set the right paths in config(s) and .wrp file(s).

 

What are advantages and disadvantages of changing class type of forest models to house?

+ ViewGeo works like in any other static model

+ Fully working eventhandlers (besides EH init)

- Enormous performance drop, especially when AI units are nearby (or inside) forest models. Probably caused by a different way of calculating geometries

- Nonalignment of models in relation to the ground curve (especially the northern Nogova type of forest)

 

What's wrong with the Nogovan forests!?

They don't support the ViewGeo trick mentioned in the first part of the tutorial. They also don't like class forest ---> class house transformation. You can see the outcome of such a change in the picture below.

 

 

J4d5emY.png

  • Like 2

Share this post


Link to post
Share on other sites

Please enter the coordinates of this space on Nogova, i will check how it looks like at my place.

Share this post


Link to post
Share on other sites

Maybe it can be fixed if in O2light by setting "on surface" to the forests or just to some points. Also we can set the destruction type via model settings (destructno will be nice, or even destructtent with 2000 hitpoints).

20 hours ago, RozekPoland said:

How to build a proper Forest ViewGeometry (02)

The answer is: "Give me all the models that need to be fixed".

Share this post


Link to post
Share on other sites

Comparison in practice of vanilla OFP/CWA forest ViewGeo and the fixed one included in @customfix. Watch till the end as I put there a showcase of AI's 360° Quick Scope :D

 

 

 

  • Like 3

Share this post


Link to post
Share on other sites
Quote

CCS is one of the leading features of OFP/CWA @customfix mod. It allows you to transport (load/unload/move/deploy) cargo crates within a variety means of transportation including: cars, trucks, tracked vehicles, boats, helicopters and planes. Each vehicle has limited cargo space. Once a vehicle gets destroyed, the onboard cargo is lost too. An infantry unit can grab, move and deploy cargo crates (as well as static weapons) anywhere including upper floors of buildings. In comparison to other similar systems that have been developed over the years, CCS works seamlessly and it does not require any additional work as it is integrated into the @customfix's core. The system is multiplayer-compatible and performance -as well as- user-friendly.

 

 

 

  • Like 5

Share this post


Link to post
Share on other sites
Quote

CCS is one of the leading features of OFP/CWA @customfix mod. It allows you to transport (load/unload/move/grab/deploy) ammo boxes, barrels, static weapons and other objects within a variety means of transportation including: cars, trucks, tracked vehicles, boats, helicopters and planes. Each vehicle has limited cargo space. Once a vehicle gets destroyed, the onboard cargo is lost too. An infantry unit can grab, move and deploy cargo anywhere including upper floors of buildings. In comparison to other similar systems that have been developed over the years, CCS works seamlessly and it does not require any additional work as it is integrated into the @customfix's core. The system is multiplayer-compatible and performance -as well as - user-friendly.


 

 

  • Like 2

Share this post


Link to post
Share on other sites
Quote

In the video you can see on demand loading of island's original buildings / structures. Loading time depends on amount of structures on an island. It is worth mentioning that loading time of buildings in the movie was doubled because of video recording load. On original trio islands (Everon - Malden - Kolgujev) it barely takes 1 second to load. On Nogova it takes 2-3 seconds.

 

 

Share this post


Link to post
Share on other sites

Maybe it's better to make a simple "boxes" for farer LODs? What is the point?

Share this post


Link to post
Share on other sites

Sneak peak of Totally Destructible Environment. Some videos and more details soon.
 

syj8Or9.jpg

  • Like 2

Share this post


Link to post
Share on other sites
Quote

TDE (Totally Destructible Environment) - a work-in-progress feature for OFP/CWA allowing for destroying majority of the objects in the game. In this video you can see massive destruction of buildings - a subfeature of the overall TDE system. The video was recorded in sterile environment limited to structures and insignificant objects like bushes - for performance reason.

 

 

 

@prototype1479 Hopefully the video answers your question :wink_o:

  • Like 2

Share this post


Link to post
Share on other sites

Use view geometry lods to Occlude sunlight

 

As was pointed out to me recently, by hitman1987, the view geometry lods will occlude sunlight passing through a hull. I'd never used it before now. And I notice a lot of modders have done the same over the years. The lack of good documentation probably didn't help. There have been some mentions of it here on the boards. But nothing too specific from what I've read.

 

It will also occlude other p3ds. This isn't much of an issue for the cargo sections of vehicles. But for an aircraft view pilot I found you get the best results by keeping the view geo mesh inside the boundary of the view lod. That way P3ds don't disappear as they pass in front of the view geo. keep them simple.  You don't have to use simple cubes of course. But don't waste time trying to get it perfect either.

8bNPS1V.jpg

paUN0XO.jpg

It looks like an effect around the lights up front. But that's the sun poking through. And without the view geo it's visible at any point in the cockpit.

 

I haven't really tested it out to a high degree. If you make the mesh slightly too big you will see P3ds disappear completely as they reach the edge of the view geo. So it prevents them from being rendered. I don't know whether that affects frame rate negatively, or positively. It's reasonable to assume it's a positive thing. But then I'm not a programmer.

  • Like 4

Share this post


Link to post
Share on other sites
Quote

TDE (Totally Destructible Environment) - a work-in-progress feature for OFP/CWA allowing for destroying majority of the objects in the game. In this video you can see levelling of city of Montignac (Everon) by a tank. While the 4-minutes video you can see:
1. Collision of a vehicle with static objects like fences, gates, roadsigns and trees,
2. Levelling of buildings up to ruins,
3. Influence of explosive shells (HEATs) on physics of static objects.

 

 


@prototype1479
There is no @customfix part of the video because I have not decided about implementation of this feature into @customfix yet.

@hitman1987
The point of the video you referred to was to get to the point of this video :wink_o:

  • Like 2

Share this post


Link to post
Share on other sites

Wow this video is just satisfying. Too satisfying (Except the part that houses immediately disappear maybe it shouldn't be immediate)

 

But I got a question to ask : Does the bigger trees gets their physics activated even from the smallest explosion?

Share this post


Link to post
Share on other sites
2 hours ago, prototype1479 said:

But I got a question to ask : Does the bigger trees gets their physics activated even from the smallest explosion?

Yes. I have deactivated the bigger trees physics because of:
1. performance reason,
2. not satisfying physics behaviour (in general).

  • Like 1

Share this post


Link to post
Share on other sites

q88nLPk.jpg

 

I would like to shed some light on the topic of one of the oldest Real Virtuality engine bug that occurs in the whole ARMA series. It is worth mentioning that it refers to the latest version of ARMA3 too. I wish this post could be brought to BI-devs' attention (and BIForums veterans) who may provide more in-depth details on the issue and maybe some engine-side solution/fix for A3. @Dwarden and @klamacz - I am sorry guys for disturbing you :f:

Quote

it seems it has already been added to the A3 feedback tracker: https://feedback.bistudio.com/T84413


 

A bug:

Quote

Static objects such as Trees, Fences, Walls etc. which feature DestructTree value (destrType token, config class) or Tree/Fence/Wall value (damage token, model properties) are vulnerable to the bug. If such an object gets destroyed it falls over and losses/ignores all of its geometries (Geometry, FireGeometry and ViewGeometry). A player (or an AI unit) can move and shoot through this fallen object, no matter what material it is. Moreover, an AI unit, as opposed to a player, can also see through the fallen object. As a result, AI is unfairly aided what has a significant influence on the gameplay. Concealment & cover - none of fallen trees, fences or walls can provide it because of the bug.

 

 

In this video you can see an example of the bug in practice AND a showcase of a solution for it.

 


A solution:

Quote

The solution for the bug is quite simple and known because of its usage for smoke grenades issue (OFP/CWA). If a tree/fence/wall gets destroyed it deploys a box that obscures AI field of view. Thanks to the box AI cannot see anything through it. However, an AI unit can still fire through it (as AI does kind of prediction and trails enemy movement and can hear too). The solution is multiplayer & performance-friendly and easily implementable, however, it is time-consuming as it requires to build proper box models (and their setPos set-up) for each (or at least most of the) object(s).

 

  • Like 13
  • Thanks 2

Share this post


Link to post
Share on other sites

For me it's more of an oversight than a bug. I'm genuinely surprised to hear that it made it into the flagship title though.

  • Like 1

Share this post


Link to post
Share on other sites

HUD Evolution

(total overhaul of OFP/ACWA Heads-up display)



Thanks to the latest version of Fwatch 1.16 by @faguss we are provided with an astonishing never-available-before feature that makes it possible to move & scale elements of HUD (Heads-up display). Due to the fact that some elements of OFP/ACWA HUD are hardcoded in the game engine, it was impossible to modify them in any way, until now. tI0YPH7.png is the first modification that makes use of the brand new Fwatch feature so you can see what can be achieved with it. Keep in mind this is just an example and it does not reveal the whole potential of the feature. (Some elements visible on the screenshots below are not Fwatch-related and are strictly @customfix features)




FCBleKf.jpg

  • HUD elements moved to the corners of the screen for better overall visibility
  • All elements aligned with each other for better visual experience
  • Commanding bar extended to the entire width of the screen
  • Log of Radio Chat extended to 13 rows (originally there is just 6)
  • Radio Menu cropped to avoid obscuring part of the screen (Fwatch-unrelated)
  • All tweaks are compatible with OFP Aspect Ratio

 

 

 

KbzsIV4.jpg

  • Action Menu extended to 46 rows (originally there is just 6)

 

 

 

zjnofa3.jpg

  • GroupDir (also known as the group leader compass) moved to center-top for better situation awareness

 

 

 

K1Kg0Zj.jpg

  • Tank compass & Radar moved to the top and aligned (Fwatch-unrelated)
  • Background for Tank compass for better visibility of driver & commander indicators (Fwatch-unrelated)
  • Like 2
  • Thanks 1
  • Sad 1

Share this post


Link to post
Share on other sites

How to fix a broken triangle-shaped forest model

Y2SyqV0.jpg
Firing through one of the trees that are part of the broken model. A tracer round that went through the tree can be seen in the picture.

One of the models, which is a part of forests on Everon, Kolgujev and a huge number of community-made islands, is broken. Due to a FireGeometry-related bug in les trojuhelnik pruchozi.p3d, bullets (or any other kind of projectile) pass through the trees. The broken model is triangle-shaped and it is used on the corners of the forests. The bug has already been fixed in tI0YPH7.png.
 

Quote

The bug can be easily fixed via o2. It is related to FireGeometry of les trojuhelnik pruchozi.p3d. That geometry lacks component entries which can be automatically generated via Structure/Topology/Find Components

dQ3ksCo.png?1



A presentation can be seen below:

 

  • Like 3
  • Thanks 2

Share this post


Link to post
Share on other sites

How I discovered the way Forest ViewGeometry works

AjZFK0Il.jpg

You are about to read one of the most interesting (and never published) discoveries related to Forests in OFP/ACWA. To be specific - the way Forest ViewGeometry works. I would like to tell you the story of my struggle with finding it all out by myself. As the topic itself is terra incognita for most (if not all) addonmakers so for all of you it will be a nice read and some of the discoveries below may shed light on still-to-be-found features of OFP/ACWA.


Forest in OFP/ACWA has a separate class in config (class Forest) but more importantly it has its own simulation (simulation="forest"). One of the features of that simulation is that the forest class is aligned to ground which is extremely useful for slopy terrain. Otherwise, forests would levitate on a sloppy terrain like shown below, and as has already been pointed out in one of my previous posts.

J4d5emYl.png

Other important feature of simulation="forest" is an alternative way of calculating ViewGeometry. Every OFP/ACWA player must have already noted that AI behaviour in forest is different because it displays its superiority in terms of seeing other units. To name just a few issues of forest models:

  • bushes provide no concealment,
  • tree tops provide no concealment,
  • small trees provide no cover & no concealment,
  • tree trunks provide no cover & no concealment,
  • imprecise geometries (geo, firegeo) of trees

Players tend to blame bugged AI for it or the game engine in general. However, my study related to the topic proves that there is nothing buggy about behaviour of AI in forests. It simply works differently than in most cases. Though, it does not make it any better.


If you compare ViewGeometry of a forest (left) and a house (right) you can spot a fundamental difference. The house ViewGeo consists of a number of components that cover specific areas of its model so AI cannot see through walls etc.. On the opposite side you can see the forest ViewGeo that is represented by a single triangle that is so huge it covers the size of the forest model. If house requires a dozen of components to properly cover specific areas of a model then how can the forest ViewGeo work with just a single triangle? No official documentation explains any of it.
FnqyIZml.png?4iYwewsrl.png?2

What is more weird is that all the forest models in OFP/ACWA have proper Geometry and FireGeometry. Copying components from Geo or FireGeo to ViewGeo does not make it work ingame. At this point you might go down the way with one of my previous posts related to building a proper Forest ViewGeo, but it DOES NOT provide FULLY-FLEDGED SOLUTION and it also introduces some new issues that have been listed. I did not give up on it and kept searching for new ways to achieve the goal. After weeks of fiddling with forest models, configs, scripts and archives of BIForums I did something by accident that paved the way to the final discovery of fixing Forest ViewGeo.


Mc7gvHTh.png

What I did was removing all the textures from LOD2 of one of the forest models. It caused AI to be unable to SPOT. The maximum value of knowsAbout for an AI unit was 1.4. In a situation like the one in the picture above knowsAbout value should reach 4. At first I thought that messing with the model for weeks caused it to be damaged. I reverted the model to its original state and redid the trick. It worked again. I did the trick for the rest of the forest models with positive results.
If an AI unit is not able to spot me it means that there must be something in its way that is blocking the view. I removed the huge triangle component from ViewGeo and AI started to work again. It is obvious now that the AI unit was unable to spot me because it was located in the middle of that huge triangle which is a ViewGeo component.
To summarize:

  • removing all LOD2 textures of a forest model caused AI to stop spotting
  • removing the triangle ViewGeo component enables AI to spot again
     

My next step was to copy forest components from Geo to ViewGeo. I did not spot any difference in AI behaviour ingame. It is worth mentioning that the copied components were for trees only. Bushes, tree trunks, tree tops etc. did not have their components so to get the overall experience and make the test 100% legit it would be required to build them but that would be time-consuming. Instead, I created a simple box in the middle of the forest model. I made it a ViewGeo component and I copied it to LOD2 so I can see it ingame. To make the box distinguishable I textured it black (data\blck_sum.pac).

q3oKZarh.png

 

It worked. An AI unit was unable to see me. The black box was providing concealment while having properly working AI. It was a massive step because it was the first time I got a ViewGeo component working in a forest model.
I was able to introduce a working ViewGeo component in a forest model but I was unable to determine what was behind the trick with removing all the LOD2 textures of a forest model. Playing the game with untextured forests does not sound enjoying.

Disabling/Enabling original LOD2 textures of a forest model back & forth did not move anything forward. Changing the LOD2 textures to black, white or untextured did not give any hint. Then, one day, I did something by accident that moved the whole story forward. I was lucky. Again.

IXyYMmWh.png

 

I changed all the LOD2 textures of a forest model to data\clear_empty.paa. I literally made the whole forest invisible. Do not be fooled though. The logic of that forest model was still in place, including geometries. I left the black box in the middle of the forest model to have any point of reference. An AI unit was able to see me through the black box (as it can be seen in the picture above). It meant that the forest model switched back to its original way of handling ViewGeometry. A conclusion of that test was getting more and more clear to me as time was passing by. However, it was still difficult to image it in practice. It would mean something absolutely out of context in terms of anything related to OFP/ACWA addonmaking.
 

Spoiler

Forest ViewGeometry is a system based on transparency of textures.


As much as unimaginable it sounds, it is as stated above in the spoiler.
 

Quote

TO BE CONTINUED

 

  • Like 4
  • Thanks 1

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now

×