Jump to content
RozekPoland

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

Recommended Posts

w1jTukIh.jpg

(How to make Forest use ViewGeometry components)



1. List all textures of forest model

As an example, let us list all the textures of one of forest modelsles ctverec pruchozi_T2.p3d

  • data\blck_sum.pac
    • non-transparent
  • data\kmen_borovice.pac
    • non-transparent
  • data\kmen1_les.pac
    • non-transparent
  • data\kmen2_les.pac
    • non-transparent
  • merged\00001&krovi4.paa
    • transparent
  • merged\00002.paa
    • transparent

Basic knowledge of texture formats let us know that .pac texture is non-transparent while .paa is transparent. However, it is always worth checking them all out by yourself.

1.1. Modify transparency of transparent texture to make it be read by OFP/ACWA Forest ViewGeometry system as non-transparent

The easiest way to do it without any harm to texture is by using Hexed.it.

1.2. Open texture in hexed.it

1.3. Change the highlighted position to F4. It always is 2nd position in 2nd row in all cases.

As an example, let us open 00001&krovi4.paa. In this case 85 has to be changed to F4.
ZdIjZ7e.png

If the highlighted position stands for FF or any value ranged from F0 to F9 then it means that the texture is non-transparent so it does not require any modification.
 

Quote

This modification DOES NOT make the texture non-transparent in practice (the texture will stay transparent in-game). It simply cheats OFP/ACWA Forest ViewGeometry system that the texture is non-transparent therefore it CANNOT be used for internal calculation based on transparency of textures. Once all the forest model textures are recognized as non-transparent the game engine will switch to use the forest model ViewGeometry components.

 

1.4. Export modified texture
1.5. Change path of modified texture in forest model

  • If model is binarized (ODOL) you have to use Hexed.it or any other hex editor
  • If model is non-binarized (MLOD) you can do it via o2 or TxtPathSwap

1.6. It is done. Forest model with modified texture(s) will switch to its ViewGeometry components in-game.

Share this post


Link to post
Share on other sites

zq0xAdXh.jpg
(How to build proper Forest ViewGeometry)

1. Open forest model in o2
As an example let us choose a model from the previous tutorial: les ctverec pruchozi_T2.p3d


2. Explore Geometry (and FireGeometry - if exists) components of the model. Decide which components (Geo or FireGeo) are worth using for ViewGeometry due to their accuracy of reflecting the forest model in general.


In our exemplary forest model Geometry and FireGeometry share the same components of regular trees but FireGeo has a few additional components that reflect tree trunks. Use of already modeled components will save us time therefore it is decided that we will use FireGeo components for ViewGeo.

XSQ1Qzy.png

3. Find out what is the height (Y axis) of the lowest vertices of the tree components that you want to use for ViewGeo.

It is worth using Select VerticesDiqqT1L.png Tool for this task.
Once vertices are selected press Shift+E or select Points/Properties... option to display Vertex Properties menu.
pKQCT0C.png?1

In our exemplary forest model the height of the lowest vertices of the tree components in FireGeo is: 10.211
yjutMav.png

4. Modify height (Y axis) of the lowest vertices of component01 in ViewGeometry to the value that was determined in step 3.

In our exemplary forest model the height of the lowest vertices of component01 in ViewGeo is: -0.222. We have to change it to: 10.211.
KRjhzef.png

 

Quote

The whole process (from step 2 to step 4) allows to achieve two goals with just one ViewGeo component. Thanks to the process the huge triangle ViewGeo components is remodeled to a dome that provides:

  • obstruction for AI view in the part of the model with the most dense foliage
    • it perfectly serves as time-and-performance-friendly solution
  • inability to spot:
    • a target that is over the dome by a unit that is below the dome
      • a unit in the forest cannot spot a helicopter flying over the forest
    • a target that is below the dome by a unit that is over the dome
      • a helicopter flying over the forest cannot spot a unit in the forest

It does introduce a change to the core of the OFP/ACWA gameplay but it definitely is worth it.
An alternative approach without usage of the dome is possible but it requires building a dozen of ViewGeo components that will properly fit measures of each foliage what is inefficient in terms of time and performance.


5. Rename component01 in ViewGeo to componentXX

6. Copy the components that were chosen in step 2 and paste them in ViewGeo

7. Identify objects in LOD2.000 that have no component counterpart in ViewGeo. All minor objects in original OFP/ACWA forests are available as separate models in data3d.pbo. (For this purpose you can use ODOL Explorer in combination with WRPTool which features 3D Objects Photo-Gallery) Such a model contains proper (if available:) Geometry, FireGeometry and ViewGeometry components. Instead of building required components all by yourself, it is highly recommended to use the already existing ones from separate models. Keep in mind the separate models may be used not only for fixing Forest ViewGeometry but also broken or missing components in Geometry and FireGeometry.

In our exemplary forest model there is a bush that can be seen in LOD2.000. It has no ViewGeo component. The bush's separate model is identified as ker listnac.p3d.
mw29Rgwh.png

The specific model contains proper ViewGeo component that can be used in our forest model.
c3V2LEy.png

 

When the ViewGeo component is pasted in our forest model, we have to manually place it in the right spot. To make it easier it is recommended to work with the component in LOD2.000 where the visual counterpart of the bush can be seen. It may be required to rotate, move up/down or (in some specific situations) re-scale the pasted component to fit the visual counterpart. Once it is done, the adjusted component has to be copied to ViewGeometry of our forest model. Before copying the component make sure that the component number is not used by some already existing component in ViewGeo components list. Avoid having components with the same number at all cost! If such a situation occurs, none of them will work! Once it is completed, remove the copied component from LOD2.000.
03HHiAzh.png


 

Quote

Copy-Paste-Adjust is the way you can build complete ViewGeometry for your forest model without exhausting work-hours. All the required resources are at your disposal.


8. Once work on ViewGeometry components is done, replace XX in componentXX with the latest number that is available so the ViewGeo components list is numerically correct

In our exemplary model the latest available number for a ViewGeo component is 45 so we rename componentXX to component45

x9cq9nr.png

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites

kOvGllN.jpg
(-benchmark)


Recently I was able to successfully traceroute -benchmark parameter which is actually one of the two unknown OFP/ACWA startup parameters. This discovery may be proved to be useful for mission-makers or anyone who wants to instantly test something ingame :exclamation:

Official OFP/ACWA startup parameters entry says:

Quote

-benchmark
Intended for automated benchmarking, but was never finished and is not working.


-benchmark parameter can be triggered manually but it does not function the way it was meant. In fact it just loads a hardcoded mission file in Mission Editor on Malden. Due to the fact that the loaded mission file is hardcoded I was able to traceroute it via OFP File Mon program in the first place.

UirQRP6.png

Launching OFP/ACWA with -benchmark parameter left an event in OFP File Mon. As I do not have test user folder in OFP/ACWA it occurred to me that the game is trying to access a very specific content that simply does not exist.

 

Quote

To launch OFP/ACWA with -benchmark startup parameter it is required to:

  1. Launch OFP/ACWA
  2. Create a new profile named test
  3. Open Mission Editor on Malden island
  4. Save a mission file named benchmark
  5. You can switch to your original profile and exit the game
  6. Launch OFP/ACWA with -benchmark parameter. You should be directly in Mission Editor on Malden with opened benchmark.abel mission file.


As a side note:

  • Any saved missions in Mission Editor will be stored in OFP\Users\test\missions
  • OFP/ACWA launched with -benchmark parameter uses settings from the original profile
  • Once you close Mission Editor the game will switch to your original profile.

 

Official OFP/ACWA Startup Parameters entry has been updated with details provided in a separate -benchmark entry.
-benchmark also appears in Arma3 Startup Parameters where it may act likewise.

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites

kD5UtWil.jpg

(Models replacement via Mission folder)


Following my recent discovery related to -benchmark startup parameter I have followed the trail of exploring files that are read by the game to find out more. Such an approach has paved the way to yet another discovery that may be even more surprising and useful than the previous one.
 

Quote

It is possible to replace models of: compass, watch, radio, notepad or gps directly in your mission folder without external addons or configs!


 

JCwwlNt.jpg

 

Quote

OFP/ACWA game engine is looking for the highlighted models in a set of specific locations, such as:

  • Users\YourUserName\missions\YourMissionName.IslandName\
    • save a mission via Mission Editor and place the replacement models in the mission folder
  • Users\YourUserName\dtaExt\
    • such a folder does not exist, you can create it and place the replacement models there
  • dtaExt\
    • such a folder does not exist, you can create it and place the replacement models there

 

Copy the new models that are named as the original ones and paste them in your mission folder (for example - Users\YourUserName\Missions\YourMissionName.Intro). The game will automatically use them instead of the original ones. This way you can customize your mission without requirement of additional addons.

Attention for models that use new textures! These textures will have to be stored in a separate pbo file to be able to be loaded (alternatively, the textures, as well as the models, can be stored in the main dtaExt folder - keep in mind to fix the paths to the new textures in the replacement models).

  • Like 1
  • Thanks 1
  • Confused 1

Share this post


Link to post
Share on other sites
20 hours ago, RozekPoland said:

It is possible to replace models of: compass, watch, radio, notepad or gps directly in your mission folder without external addons or configs!

 

20 hours ago, RozekPoland said:

Attention for models that use new textures! These textures will have to be stored in a separate pbo file to be able to be loaded 

This method still doesn't let you change models of equipment without external addons. It is possible to replace existing models with ones of different equipment (for example Soviet), however one still needs a separate .pbo with textures representing that equipment (and even then you have a side effect of big mission file size).

 

Without external addons/configs we can only replace BI stuff with something that uses the same textures (and similiar mapping), which in general limits us to the very same equipment. And making higher fidelity models of the same stuff is pointless, because BI models are OK, it's the textures that need a do-over (when it comes to binocs, compass, GPS, etc.).

  • Like 2
  • Sad 1

Share this post


Link to post
Share on other sites

tdmqHdz.jpg

FILE(s) NOT FOUND

(file paths that were not found by the game)

(bold - ACWA 1.99)

 

Quote

Regular Paths:

  • Users\UserName\missions\MissionName.IslandName\
  • Users\UserName\dtaExt\
  • dtaExt\

and

  • If SP (Single-Player)
    • missions\__cur_sp.IslandName\
  • If MP (Multi-Player)
    • mpmissions\__cur_mp.IslandName\


OFP/ACWA Main Menu

  • Specular textures:
    • data\grass_dx.paa
    • misc\waveBumpMap.paa
  • Global textures (numerized):
    • data\desta.05.paa
    • data\mesic.13.paa
    • data\more_anim.08.pac
    • data\basic.17.paa
    • data\fire.121.paa
    • data\fired.120.paa
    • data\water.07.paa
    • data\zasleh_front.04.paa
    • data\zasleh_side.04.paa
    • data\zasleh3_front.04.paa
    • data\zasleh3_side.04.paa
  • Textures:
    • biscamel\icamel2.paa
  • World cutscene detector (mission file format depends on currently loaded island):
    • anims\intro.Intro\stringtable.csv
    • anims\intro.Intro\description.ext
  • Legacy leftovers:
    • dtaExt\ofplogo1.paa
    • dtaExt\ofplogo2.paa
    • dtaExt\ofplogo3.paa
    • Game001.Intro\ofplogo1.paa
    • Game001.Intro\ofplogo2.paa
    • Game001.Intro\ofplogo3.paa
    • Game001.Intro\startup_logo_cwa_ca.paa
  • Config(s)
    • 6g30\config.cpp
    • abox\config.cpp
    • apac\config.cpp
    • biscamel\config.cpp
    • bizon\config.cpp
    • bmp2\config.cpp
    • brmd\config.cpp
    • ch47\config.cpp
    • flags\config.cpp
    • g36a\config.cpp
    • humr\config.cpp
    • hunter\config.cpp
    • kolo\config.cpp
    • kozl\config.cpp
    • laserguided\config.cpp
    • m2a2\config.cpp
    • mini\config.cpp
    • mm-1\config.cpp
    • noe\config.cpp
    • o\config.cpp
    • oh58\config.cpp
    • o_wp\config.cpp
    • steyr\config.cpp
    • su25\config.cpp
    • trab\config.cpp
    • vulcan\config.cpp
    • xms\config.cpp
    • voicerh\config.cpp
    • voicerh\stringtable.csv
  • Models
    • dtaExt\notebook.p3d

 

OFP/ACWA Edit Profile

  • Models:
    • dtaExt\hlavaw.p3d
      • male head
    • dtaExt\o\char\civilistka_head.p3d
      • female head


OFP/ACWA Mission Editor - Island Selection

  • Models:
    • anims\intro.intro\notebook.p3d
      • Replacement of notebook/computer model for Mission Editor - Island Selection. Currently loaded island determines mission file format (.intro, .eden, .abel, .cain, .noe).
    • dtaExt\notebook.p3d
      • As above but replacement works for all islands without specific mission folders for specific islands
  • Textures:
    • anims\intro.intro\_eden.paa
    • dtaExt\_eden.paa
    • anims\intro.intro\_abel.paa
    • dtaExt\_abel.paa
    • anims\intro.intro\_cain.paa
    • dtaExt\_cain.paa
    • anims\intro.intro\_training.paa
    • dtaExt\_training.paa
    • anims\intro.intro\\o\misc\_nogovo.paa
    • dtaExt\\o\misc\_nogovo.paa
  • demo\demo.wrp
    • GaR7j0j.png
    • demo.wrp is defined in config and it refers to Malden from OFP demo version (mission files saved as MissionName.demo format)


OFP/ACWA Mission Editor

Spoiler

Regular Paths:

  • Users\UserName\missions\MissionName.IslandName\
  • Users\UserName\dtaExt\
  • dtaExt\
  • Textures:
    • notasa.pac
    • notasb.pac
    • notasc.pac
    • notasd.pac
    • notase.pac
    • notasf.pac
    • bourka.paa
    • podmapa.pac
    • zatazenosl.paa
    • bourkasym.paa
    • jasnosym.paa
    • eastsym.paa
    • westsym.paa
    • azimut.paa


OFP/ACWA Mission Editor - Preview

Spoiler

Regular Paths:

  • Users\UserName\missions\MissionName.IslandName\
  • Users\UserName\dtaExt\
  • dtaExt\
  • Models:
    • kompas.p3d
    • kosei.p3d
    • vysilacka.p3d
    • blok.p3d
    • karta.p3d
    • gps.p3d
  • Textures:
    • podmapa.pac
    • sipka_left.paa
    • sipka_right.paa
    • equip\w\ (+ multiple files)
    • equip\m\ (+ multiple files)
    • equip\ (+ multiple files)


OFP/ACWA Mission Editor - Debriefing

Spoiler

Regular Paths:

  • Users\UserName\missions\MissionName.IslandName\
  • Users\UserName\dtaExt\
  • dtaExt\
  • Models:
    • blok_selmis2.p3d
    • desky.p3d
  • Textures:
    • debr_star.paa

 

OFP/ACWA Singleplayer - Mission Selection

  • Models:
    • anims\intro.intro\blok_selmis2.p3d
    • dtaExt\blok_selmis2.p3d

 

OFP/ACWA Singleplayer - Briefing

  • Textures:
    • data\kasna_voda.07.paa
    • data\m1_passide_anim.07.pac
    • data\night_sum.06.paa
    • data\bmp_anm.06.pac

 

OFP/ACWA Multiplayer - Lobby

  • Textures:
    • anims\intro.intro\misc\gamespy.pac
    • dtaExt\misc\gamespy.pac
    • anims\intro.intro\misc\sipkad.paa
    • dtaExt\misc\sipkad.paa
  • Like 1
  • Thanks 1
  • Confused 1

Share this post


Link to post
Share on other sites

x1MU1kG.jpg

Recently I discovered a security flaw in OFP/ACWA that can be exploited by hackers/cheaters to use modified versions of original game files without being detected at any point by any available measure. I would like to provide you details how to prevent usage of the hack.

 

The hack is oriented around the files listed below:

Quote

RESPAWN-related

  • scripts.pbo
    • onPlayerKilled.sqs
    • onPlayerRespawnAsSeagull.sqs
    • onPlayerRespawnOtherUnit.sqs
  • onPlayerRespawn.sqs
  • onPlayerResurrect.sqs

OTHER

  • init.sqs
  • description.ext

 

A hacker/cheater can use modified version of the aforementioned files with them NOT being detected as modified by checkfiles server mechanism.
To make the hack unable to work, each mission has to have all the listed files in its mission folder. The files can be even empty inside but they have to be present there with the exact names.
Keep in mind that depending on type of respawn in a mission, such files as:

  • onPlayerKilled.sqs
  • onPlayerRespawnAsSeagull.sqs
  • onPlayerRespawnOtherUnit.sqs

can influence the way respawn works in a mission. It is recommended to copy the three files listed above from original DTA/scripts.pbo and paste them in a mission folder.

  • Like 1
  • Thanks 2

Share this post


Link to post
Share on other sites

t23Dv0P.jpg

 

 

Due to my recent study focused on security measure of OFP/ACWA Dedicated Server I have done some research on checkfiles[]={}; array and its practical use.

Quote
  • CHECKFILES
    • List of files that should be checked for each player connecting.
    • List of files to check for integrity with crc check. Possible to check pbo files or files inside pbos. Beware checking large files, which takes serious processing on the server and can cause various issues.

Thanks to checkfiles, it is possible to make sure that each player that connects to a server is compatible with it in terms of content of the game.

 

There are two ways of "checking" files via checkfiles.

Quote
  • Path-finding
    • Do checkfile on a file in its defined path
    • example:
      • "addons\bizon.pbo",
    • Good for checking proper mod(s) synchronization across client-server. It is also fast.
  • Content-finding
    • Do checkfile on a content of a defined file
    • example:
      • "bizon\config.cpp",
      • "bizon\bizon.p3d",
      • "bizon\bizon.wss",
      • "bizon\bizon_1d.paa",
    • If there is a folder with the same name (as the defined file of the defined content) in the main OFP/ACWA folder, checkfile gets its priorities.
      1. It checks the defined content of the defined file.
      2. If found nothing there, it checks the defined location (the Path-finding way).
    • Good as an anti-cheating measure. May be slow if the checkfiles array is too long.

 

It is possible to checkfile any pbo file (and its content) as well as any other file that is located in OFP/ACWA game folder.

Quote

Keep in mind that including such a list in server.cfg will make connecting to a server extremely long and unstable. It is meant for testing purpose only.

 

To make it more performance-friendly and robust at the same time, I have prepared a basic list for checking the crucial content of OFP/ACWA. It is a good starting point for a vanilla (no-addons) server.

Quote

 

According to my latest discovery from the previous post, it is highly recommended to add these lines to checkfiles array.

Quote
  • "scripts\camera.sqs",
  • "scripts\death1.sqs",
  • "scripts\deathDefault.sqs",
  • "scripts\onPlayerKilled.sqs",
  • "scripts\onPlayerRespawnAsSeagull.sqs",
  • "scripts\onPlayerrespawnOtherUnit.sqs",
  • "scripts\startup.sqs",

 

If server uses custom addons/mods then it is recommended to include them in checkfiles array. It is worth the effort not only because of security issues but also for keeping 100% of synchronization between clients and server.

Quote
  • Some of the most popular addons that are in use on the public OFP/ACWA servers:
    • "baracken\config.cpp",
    • "cti_markers\config.cpp",
    • "editorupdate102\config.cpp",
    • "mfcti1.16\config.cpp",
    • "usmcsymbols\config.cpp",

 

It is worth mentioning that It is also possible to do checkfile ON-DEMAND on server by server admin.

Quote
  1. Connect to server
  2. Log into administrator
  3. Type #debug checkfile file-to-be-checked
    • example:
      • #debug checkfile dta\data3d.pbo
      • SOURCE

 

  • Like 1

Share this post


Link to post
Share on other sites

Make sure to use

 

"Addons\4ecf739.pbo",

"DTA\4ecf739.pbo",
 

to identify TKC users

 

And also this checkfile trick won't work well if the cheater joined before everyone else joined the server so #debug would work pretty well but the catch here is it requires logged in admin

  • Like 1

Share this post


Link to post
Share on other sites

BlWr5Un.jpg

 

As recently OFP/ACWA turned 18, the game is mature and far beyond EOL (End-Of-Life), I decided to reveal the ways which hackers/cheaters have been using in OFP/ACWA.
 

Such a decision may be doubtful, especially in context of morality, because the reveal can be used against players & communities that still play the game. To avoid any unnecessary collateral damage the revealed knowledge may cause, this post is limited to the very basics that are crucial to understand the entries hackers/cheaters have been using. I would like to emphasize that my post exposes the modus operandi of hacks/cheats that have been in practical use since the golden age of OFP.
It is the OFP/ACWA community that can finally understand the way those hacks/cheats were being injected into the game. This post, as the whole thread, is strictly technical, and this is how I would like to keep it.

 

Quote

CPP Hijacking is a method that has been used by hackers/cheaters to take control (modify) of content files (PBO) to gain advantage over other players in multiplayer sessions. Once the method is properly applied the modified content is UNDETECTABLE by any available means. Each PBO file that is loaded from AddOns folder (original or mods) is vulnerable to be CPP-Hijacked. The method takes advantage from openness and moddability of Real Virtuality 1 engine.

 

Due to complexity of the idea behind CPP Hijacking, it can be executed in two ways.

 

 

WAY 1 - Folder Disguise

Quote
  • The game engine, once it loads an addon, looks for a folder with the same addon name in the main OFP/ACWA game directory
    • The idea of this method is to place a modified config.cpp in a folder named the same as an addon that is meant to be modified
      • If an addon (that is meant to be modified) contains config.cpp file then it is VULNERABLE to this way of CPP Hijacking
        • If an addon does not contain config.cpp file then it is not vulnerable to this way of CPP Hijacking
  • kozl.pbo is an official addon that introduces famous Kozlice gun
    • The pbo file of the addon includes config.cpp
      • Due to that fact, the addon is vulnerable to be CPP-Hijacked
        • All that has to be done is:
          1. Create a folder named kozl in the main OFP/ACWA directory
          2. Copy the original config.cpp of the addon (or create a new one) and paste it in kozl folder
            • That config.cpp file will be used by the game instead of the original one from the addon pbo file

 

The serious issue is when it comes to detect such a hack/cheat in multiplayer on a dedicated server. For this purpose let's make a use of the checkfiles template I shared in my previous post.

Quote

"addons\kozl.pbo",

"res\addons\kozl.pbo",

 

"kozl\config.bin",

"kozl\config.cpp",

  • It turns out that it is IMPOSSIBLE to detect such a hack/cheat via Checkfiles array due to technical limitations
    • It is because checkfiles method focuses on:
      1. in the first two entries of the template
        • server compares its pbo file with client's one
      2. in the two last entries of the template
        • server compares config.bin & config.cpp from its pbo file with client's one(s)
    • The checking process will not come across any problems as the addon pbo file was not modified in any way
      • It is the game engine that loads config.cpp from a separate location into memory
      • As the outcome, no modified data message shows up and a modified config.cpp located in a folder named the same way as an addon STAYS UNDETECTED
    • Content which is WAY-1 CPP Hijacking vulnerable
      • original addons:
        • ch47.pbo
        • humr.pbo
        • kozl.pbo
        • su25.pbo
        • trab.pbo
      • community-made addons:
        • all pbo files that feature config.cpp

 

 

WAY 2 - Addon Disguise

Quote
  • Any PBO addon file that is delivered to the game is vulnerable to modification via extra pbo addon file
    • The method takes advantage of non-working access token in addon's config
      • access
        • Determines the manipulability of the class
          • 0 ReadAndWrite additional values can be added

          • 1 ReadAndCreate only adding new class members is allowed

          • 2 ReadOnly no modifications enabled

          • 3 ReadOnlyVerified no modifications enabled, CRC test applied

          • All BIS classes are ReadOnlyVerified and can only be inherited into a new class

          • SOURCE

        • In practice

          • access token (protection) works for the main OFP/ACWA config classes

            • access token (protection) DOES NOT work for classes added via addon pbo file

  • bizon.pbo is an official addon that introduces well-known Bizon weapon class and Spetsnaz Bizon Operator class
    • The addon, as well as 26 other official addons, is vulnerable to WAY-2 CPP Hijacking
      • All that has to be done is:
        1. Create a new addon that will modify the Bizon addon
          • the name of the new addon does not matter
        2. Prepare CfgPatches section in the config of the new addon
          • requiredAddons token allows to make "a reference" to any addon by using or modifying its content
            • Use of requiredAddons[]={"Bizon"}; allows to make a reference to the addon that is meant to be modified
        3. The new addon is hooked to the Bizon addon, so is the Bizon addon's content which can be modified

 

Let's see how does the situation with the modifying addon look like in multiplayer. Again, let's use the template shared in my previous post.

Quote

"addons\bizon.pbo",
"res\addons\bizon.pbo",

"bizon\config.bin",
"bizon\config.cpp",

  • As it is impossible to determine a name of the modifying addon, it is NOT POSSIBLE to detect its usage in multiplayer
    • The original Bizon addon was not modified in anyway so there will be no "modified data" detection
      • It is the new modifying addon that introduces changes to the Bizon addon's content but the game engine differentiates them as separate
        • Similarly to WAY-1 CPP Hijacking, checkfiles mechanism is helpless in such circumstances
  • Like 2

Share this post


Link to post
Share on other sites

THE OLDEST OFP BUG!

 

Qatwyzg.png

 

Not really, but... how you guys could have missed it through all these years? :don9:

  • Confused 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

×