NTAuthority

Some more comparison screenshots showing why 'widescreen' does not cut it: http://files.dotbas.net/img/fov-1610-default.jpg (non-widescreen, non-fixed) http://files.dotbas.net/img/fov-1610-rs.jpg (widescreen, note the lack of vertical information -- widescreen monitors are meant to have more horizontal information!) http://files.dotbas.net/img/fov-1610-nt.jpg (widescreen off, custom FOV setting, note that the vertical information remains, and more information is added horizontally. this only offers a negligible gaming advantage and as such is not a 'cheat') It likely doesn't, but that's mainly as MTA's position change code replaces it with something meant for the 640px wide default 'virtual screen', easy to change by editing MTA's source. That's likely because these values are pooled with other read-only values to reduce the size of the .rdata PE block. III/VC made every instance of a variable with the same static value have a different memory location, but SA's compiler actually pools them to be similar. To change these effects, the code using them would need to be patched, and not the hardcoded values.

Some screenshots of my FOV work (needs cleaning up and MTA integration still): http://imgur.com/n9pIW.jpg - 4:3 reference http://imgur.com/qwvAh.jpg - 16:10 stock (stretched, very much) http://imgur.com/bU8GU.jpg - 16:10 custom

I have a proper C# fix for this value and other values that are required to be changed too (not just pixel width, also 'screen size in pixels'), however, the default HUD is messed up partially if changing pixel width. I could try finding out a way to fix this (it did work in VC with weapon icon on the other side) and provide a patch if required (and converting to 'proper' C++)? Other issues happen with certain scripting functions using the GTA 'virtual screen' hardcoded to think it's 640px wide, but as MTA doesn't use GTA virtual screen functions that's likely no issue. Also, 859524 is the 'pixel height' value (1/448), while a proper fix should be 4 bytes earlier, in the 'pixel width' value (1/640). EDIT: some more explanation (14:21 CEST) Changing things vertically is not the proper way to fix widescreen issues (like GTA from III to VCS do). The proposed fix changes the vertical height to fit in with the game's vertical widescreen fix, but a proper fix would be done horizontally. Another fix I'm tracking down is a 'proper' horizontal fix to replace GTA's 'widescreen' option... I've found out how Racer_S's GTA3/VC tools fix it and the only thing I need to track down if I'm right is the 'static' FOV value, the one the game interpolates to if CCamera::Cams[0].FOV is changed. The proper fix seems to increase the horizontal FOV and change the (also set by widescreen) flag that likely configures the relation between horizontal and vertical FOV... where 'widescreen' reduces the vertical FOV instead of increasing the horizontal FOV... if anyone would be interested in having a GTA IV-ish proper widescreen patch, let me know and I'll also make a MTA patch for that.

I'm wondering, there are a lot of comments and such in the MTA source code that make me think 'who the heck wrote this? it must be somebody on the inside...' -- did any of the developers have/had a source within Rockstar? Think of code pieces like the following ones: #ifndef FINALBUILD bool bStaticFrustum; #endif // for debug keyboard stuff #ifndef MASTER unsigned char display_kbd_debug; float kbd_fov_value; #endif // MASTER -- from CCamera.h: debug cameras have never, ever, been figured out. And even more so, such constants should have been set at GTA build, not at MTA build. int m_iCheckCullZoneThisNumFrames; int m_iZoneCullFrameNumWereAt; int WhoIsInControlOfTheCamera; //to discern between obbe and scripts Same file, so you have Obbe Vermeij working for you? Not. CVector m_cvecAimingTargetCoors; // Coors to look at with Gordons aiming thing Gordon Yeoman? Another R*N employee... this is starting to get suspicious... bool bDisablePlayerEnterCar; // Script can set this so that the Enter Car button can be used to pick up objects bool bDisablePlayerDuck; // Script can set this bool bDisablePlayerFireWeapon; // Script can set this bool bDisablePlayerFireWeaponWithL1; // Script can set this - for Judith's mission where L1 is needed to pick up objects bool bDisablePlayerCycleWeapon; // Script can set this bool bDisablePlayerJump; // Script can set this From CPadSA.h, which is strange. None of these script flags are known from the community scripting documentation (except the first), and I never heard of a 'Judith' working at R*. However, the 'author' of handling.cfg is also never credited. float FOV; float FOVSpeed; float Beta; float BetaSpeed; float Distance; // 232 float DistanceSpeed; float CA_MIN_DISTANCE; float CA_MAX_DISTANCE; float SpeedVar; float m_fCameraHeightMultiplier; //used by TwoPlayer_Separate_Cars_TopDown CCam.h - the FOV flag has never been found out by anybody... and you know about TwoPlayer stuff? What does that have to do with MTA? Did R* leak .h files or something like that? Again, my question: did any of the MTA developers have a source within R*N one day? This seems too suspicious to think not. :\

Hi! I have converted a IPL file (using a custom conversion tool which also converts the quats) containing an island of 662 objects to a heap of 'object' tags in a tdm .map file. The location around the spawn area loads correctly, and stays loaded, however, when I walk around too far, in very rare cases/locations the map continues streaming -- and in one location streaming does not continue, and the floor I'm standing on is gone... so I drop to the water and have to resort to 'kill'. Is there a fix for these streaming problems, or is this hardcoded in the deathmatch library code? Thanks in advance, Bas

For me the problem was solved with BinSlayer's compatibility mode, and using the coreconfig.xml from http://development.mtasa.com/index.php? ... ing_splash