Issue to track the migration to Visual Studio 2010. Right now #1 is the main roadblock that we face.

Success get into 3D environment, but can't see cockpit and middle LOD with map

Have anybody go through this?

And I see this topic. #13

@PeterMeyer say he can use Free Falcon 5 to load.

But now day I hardly to find this version (FF5.0) on internet, have anybody have copy or download link?

Sometimes this assertion fails, sometimes it doesn't. The file that it is trying to read is at art/ckptart/autofont/16x12font.rct in the FF install directory. The contents of str on the pass where it fails is "3 43 234 10 18 1\n"- only 6 numbers, when there should be 7 or more. It appears to reach the EOF one-off.

I can't exactly pin down the cause of this- it seems to crop up whenever it feels like it, and disappear whenever I try to observe it.

Assignment operations to it's member variables are not done correctly, some of the variables are not even showing up in the debug watch. Never seem anything like this before, not sure if it's compiler's error or there's something wrong with the code, not sure how to fix.

Fix the Wix Toolset.
Fix the links to our forum.
Fix the path to the RELEASE build.

Right as the first plane is lit up on the loading screen, there are two assertions that fail. Both message boxes pop up at roughly the same time, so let's look at these first.

One of them occurs in this switch. m_eSurfFmt is set to D3DX_SF_UNKNOWN at this point, and the switch falls through to the default case where there's a rather stupid way of erroring out (ShiAssert(false)? WTF).

The other simultaneous error is from this assertion here.

Accompanying these is this message on the console:

Texture: Failed to create texture  (Code: 80070057)

Right now weather Module will not initialize correctly after FFViper was compiled
correctly. This has to do with General overrides. The Problem is known and is
not solved read.

Topics: FRead Problem, past bug in VC++ Compiler.

The ShiWarning() in this method is being triggered on startup- the next roadblock on our way to working code.

The current code loads the terrain textures here

Since the FF6 installer comes with terrain files with "H" in front an not with "L" nothing gets loaded at all.

Changing the "L" to "H" (res is 0) leads to a crash when it tries to load the first mipmap

Can freefalcon-central be built with MSVS2013 and directx9 or directx10?

I just compiled the updtodate source from the Repo. In debug/Release i get a new critical Error:

Debug Assertion Failed

The Debugger falls back into this Code in
C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\crt\src\dbghook.c\dbghook.c

__declspec(noinline)
void __cdecl _CRT_DEBUGGER_HOOK(int _Reserved)
{
/* assign 0 to _debugger_hook_dummy so that the function is not folded in retail */
(_Reserved);
_debugger_hook_dummy = 0;
}

Expression Stream != Null

The Line of crash is in the Method: int DisplayOptionsClass::LoadOptions(char *filename)
in F:\Projekte\GitHub\freefalcon-central\src\falclib\dispopts.cpp Line:62 "fclose(fp);"

Maybe this is an sideeffect of the registry changes we had?

There are a few lines of code, made by the old Coder Fred Balding (Baldeagle) wich makes
some Copyprotection checks,

File: F4find.cpp

    // FF protection
    static int Done = 0;
    sprintf(path, "%s\\sounds\\files.dir", FalconDataDirectory);

Ranger reported me via EMail about this a few month ago.

Happens due to DirectInput joystick loop.
If I disable it than that screen works.

All weapons are shown as white, without any textures.
Helicopters are shown with a rotating square instead of a rotor.

When trying to run the code in Windows 8, I get the following warning:

Requested unavailable resolution 1024x768x16

The warning is coming from this bit of code.

Peter is also getting this issue on a Win8 install. It looks like it's whining about having to load 16-bit colours. This warning can't be ignored to continue to the UI- the sim crashes upon continuation.

FF6 does boot on this computer as I have it installed, but it doesn't run when compiled in debug mode on VS2010, so I'm adding this to the migration milestone.

So is this basically dead then? No activity for a long time...?

The main UI screen has a FF5 texture that needs to be edited to remove the 5.
The exit screen has a FF6 texture that needs to be edited to remove the 6.
The version number now works OK so no need to put it in a texture.

Drag the MASTER VOLUME slider to maximum (fully right).
Click OK.
Re-enter the SOUND tab.
The MASTER VOLUME slider will be almost at full, exactly as its default.

Hi all. I'm here with my alternative nick, because as seems my official one (Jackal) is kept here yet.

Also given that the old FreeFalcon forum has suddenly closed, would someone kindly help me with this issue?
When I'm in FF6, ITO2 theater last released version opened, and most of all when I'm in MP, the sim crashes after a few minutes of flight - it freezes and I'm obliged to close the sim with the hard manners using the manager (pressing the keys CTRL+ALT+CANC and closing the program not responding any longer).

To me, it's not a MP issue, or not only related to MP, but more anyway it's somehow related to the graphic side - I use Win7 Ultimate on a system equipped with a nVidia GTX660Ti graphic card, 32 Gb of RAM and an Intel I7-3820 @3.60GHz.

Here is as follows the last crash log:

"FFViper.exe caused a EXCEPTION_ACCESS_VIOLATION in module FFViper.exe at 0023:0065D42C, ObjectiveClass::GetRadarType()+60 byte(s), g:\cobradev\ffviper\campaign\camplib\objectiv.cpp, line 1569+25 byte(s)
Exception handler called in SimLoop Thread.
Read from location 00000067 caused an access violation.
Code: 0f bf 40 24 eb 02 33 c0 8b e5 5d c3 cc cc cc cc 
Stack dump:
Stack: 0023:0065D42C (0x00000000 0x12E08000 0x2528E728 0x006ADB4F) FFViper.exe, ObjectiveClass::GetRadarType()+60 byte(s), g:\cobradev\ffviper\campaign\camplib\objectiv.cpp, line 1569+25 byte(s)
Stack: 0023:008FAB3C (0x12E08C30 0x2528E728 0x00000000 0x0556F728) FFViper.exe, ALR56Class::GetLethality()+76 byte(s), g:\cobradev\ffviper\sim\rwr\alr56.cpp, line 32+14 byte(s)
Stack: 0023:007168A9 (0x12E08C30 0x12EC5128 0xFA5EFC84 0x4D05A19A) FFViper.exe, PlayerRwrClass::IsFiltered()+41 byte(s), g:\cobradev\ffviper\sim\rwr\playerrwr.cpp, line 1006+15 byte(s)
Stack: 0023:00714F0E (0x2523AE48 0x12EC42F0 0x00000000 0x2528E728) FFViper.exe, PlayerRwrClass::Exec()+910 byte(s), g:\cobradev\ffviper\sim\rwr\playerrwr.cpp, line 224+12 byte(s)
Stack: 0023:0077011B (0x00000000 0x00772DAF 0x00000800 0x00010000) FFViper.exe, AircraftClass::RunSensors()+395 byte(s), g:\cobradev\ffviper\sim\aircraft\aircraft.cpp, line 2550+21 byte(s)
Stack: 0023:0076DEEF (0x2520FC78 0x12EC42F0 0x085A24A6 0x0556FE50) FFViper.exe, AircraftClass::Exec()+9567 byte(s), g:\cobradev\ffviper\sim\aircraft\aircraft.cpp, line 1808
Stack: 0023:0072E550 (0x085A24A6 0x0556FE2C 0x2520FC78 0x0556FEB8) FFViper.exe, SimVuDriver::ExecModel()+32 byte(s), g:\cobradev\ffviper\sim\simlib\simvudrv.cpp, line 91+14 byte(s)
Stack: 0023:006ACDA2 (0x085A24A6 0x12835F08 0x0556FEA4 0x2520FC78) FFViper.exe, VuMaster::Exec()+50 byte(s), g:\cobradev\ffviper\vu2\src\vudriver.cpp, line 307+15 byte(s)
Stack: 0023:0078C2E4 (0x00000003 0x12BF3E10 0x00000000 0x00000000) FFViper.exe, SimulationDriver::Cycle()+836 byte(s), g:\cobradev\ffviper\sim\simdrive\simdrive.cpp, line 662
Stack: 0023:0071BEE1 (0x00000000 0x00000000 0x00000000 0x00000000) FFViper.exe, SimulationLoopControl::Loop()+1393 byte(s), g:\cobradev\ffviper\sim\simloop\simloop.cpp, line 504
Stack: 0023:0071B674 (0x00000000 0x0556FFD4 0x77279EF2 0x00000000) FFViper.exe, SimLoopWrapper()+68 byte(s), g:\cobradev\ffviper\sim\simloop\simloop.cpp, line 116+5 byte(s)
Stack: 0023:764E33AA (0x00000000 0x721D7CFC 0x00000000 0x00000000) kernel32.dll, BaseThreadInitThunk()+18 byte(s)
Stack: 0023:77279EF2 (0x0071B630 0x00000000 0x00000000 0x00000000) ntdll.dll, RtlInitializeExceptionChain()+99 byte(s)
Stack: 0023:77279EC5 (0x00000000 0x00000000 0x00000000 0x00000000) ntdll.dll, RtlInitializeExceptionChain()+54 byte(s)
EAX=00000043  EBX=00000000  ECX=03D70CA8  EDX=00000001  ESI=00004D15
EDI=00000000  EBP=00000000  ESP=0556FFF4  EIP=00000000  FLG=00010212
CS=0023   DS=002B  SS=002B  ES=002B   FS=0053  GS=002B
Error occurred at 1/24/2013 20:08:42.
C:\FreeFalcon6\FFViper.exe, run by Giove.
8 processor(s), type 586.
0 MBytes physical memory.
OS: 6.1 build 7601 platform 2 Service Pack 1
FreeFalcon: 6.0  *  FFViper: 2.3.3.44
Card: DXContext::Init - DriverInfo - "nvd3dum.dll" - "NVIDIA GeForce GTX 660 Ti", Vendor: 4318, Device: 4483, SubSys: 293802160, Rev: 161, Product: 0, Version: 0, SubVersion: 0, Build: 0
Game is Tactical Engagement type Networked
DX Model ID : ffffffff
Texture ID  : ffffffff"

So, what do you think?n Is anyone there who could give a help to solve this?

Thanks a lot in advance for yor attention and best regards.

JagHond

I'm getting the following two lines of seemingly related error output in the console:

ERROR: BID_FILE_DIS already in Index
ERROR: WIN_ADD_SQUADRON already in Index

They may or may not be harmless, but it'd be best to kill everything reminiscent of an error, eh? 😃

The problem occurs in C_Resmgr::LoadIndex() on this line. There are several spots in that method where an "already in Index" error could be printed, but both are from this line, so it's at some point in that while loop that they occur.

I just got the Info out of the Community, thadt our Friend Fred BaldEgale has done
some nasty things in one of the most used tools for modding (LODEditor) wich has its
Counterpart in FFViper.exe See the text below.

In the Contribsection there is some Code of LODEditor Maybe we should check the
code and tell our Userbase not working with the blackboxed, harmfull LODEditor
Version.

LODEditor 7.0.2.4 and later

Commandline switches:

-dxl -ffdev

-ffim
-hires
-dxl
-ffdev
-adm1n
-unlkdb
-qed
-debug

-hisw

Menu: Dev Utilities "Lock DB", "Unlock DB" and "Check DB Status" functions.

The current security DB status has a check mark next to Lock DB or Unlock DB.

To lock and unlock the DB or check its status, use LE with "-ffdev" commandline switch
and the Dev Utilities "Lock DB", "Unlock DB" and "Check DB Status" functions.

d:\FFalcon\files.dir

moved to:

d:\FFalcon\Sounds\files.dir

d: = FF install drive

• FalcLib\F4Find.cpp (code here)

RedViper.* and FFViper Config Editor.exe are zeroed out when FFViper.exe is run.

• FalcLib\F4Find.cpp (code here)

• FalcLib\Entity.cpp & Classtbl.cpp (code here)

For FFViper KoreaObj.dxh Parent record nDOF and nSwitch variables were put in
variables that can hold bigger values. When KO.dxh is "Locked", Falcon 4 versions
other than FFViper, will crash due to the original nDOF and nSwitch variables being
set to zero. "Unlocking" KO.dxh copies the new nDOF and nSwitch variable values
to the original variables.

d:\FFalcon\terrdata\objects\Falcon4.* files (except Falcon4.phd and Falcon4.pd)

The number of entries (records) in the file is moved to the end of the file
and zero is put in the number of entries position (first 2 bytes).

FFViper.cfg must have "set b_gFFDBC 1" for FFViper.exe to work. All other exe's
will error out. (This method will be used for release of FF 5.x).

Added "safe" DB access (detects the DB status) for LE and FFViper.
(This method will be removed for release of FF 5.x).

To lock and unlock the DB or check its status, use LE with "-ffdev" commandline switch
and the Dev Utilities "Lock DB", "Unlock DB" and "Check DB Status" functions.

End of File

Let's assume that we have a sort-of-working version (i.e. able to go into 3D environment for 90% of the times, in both debug and release version, and is functioning the way it was in FF6) of the code, what's the next step? Who's capable of/going to do it?

Our next problem is here.

The problem is that ppn->sizeStages somehow jumps way up to some obscenely high number after a few of what appears to be normal iterations of that On block.

I put in a bit of test code to send the value of that to a file so I could observe its pattern, here are my findings: https://gist.github.com/53d3e98c47848414e4e6

The bit of code that I had there commented out does stop the crash, but I feel like that's a pretty bad thing to do? We should probably find out why the value of ppn->sizeStages suddenly jumps way up to 1064514355 and stop it from doing that.