2dea177909
Three separate defects, all the same class: a per-mech image is looked up by string, the lookup misses, and nothing says so. Two were pre-existing and live; all three would have been inherited by the six V4H chassis. 1. The atlas was full, so mech id 64 showed another mech. HSH_CreateMFDTextures built a 1024x1024 texture holding one 128x128 tile per chassis, 8 per row, indexed by mech id -- 64 tiles for 65 names. Zeus (id 64) addressed y=1024. On write, DrawBitmapToSurface blits through a GDI DC, so the blit fell outside the clip rect and was discarded. On read, DrawTexture2 divides by tw/th, giving v = 1.000..1.117; the MFD device never sets D3DTSS_ADDRESS so it is D3D7's default WRAP, and that range wrapped to 0.000..0.117 -- exactly tile 0. Targeting a Zeus therefore displayed the Annihilator: not garbage, not black, a clean picture of the wrong mech, which is why it went unnoticed. The atlas is now 1024x2048 (128 tiles). Tile origins are unchanged and the draw derives UVs from pixel coordinates over tw/th, so the taller surface re-normalises automatically: all 64 other chassis sample byte-identical regions, and only Zeus moves -- from the Annihilator's pixels to its own. CreatePixelFormatTexture returns NULL on failure and SetTexture(0,NULL) renders untextured rather than crashing, so on a card that caps texture dimensions at 1024 an unguarded change would have silently blanked all 65 images. It now falls back to the original size, which restores exactly the previous behaviour, and says which size it got in gos-displays.txt. The granted height travels on the device as m_nMechAtlasH because mode 4 gives each of the two panels its own IDirectDraw7 and swaps the texture between them. A capacity guard now logs and skips a tile past the end instead of writing it off-surface and reading back someone else's picture, so this cannot recur silently when the roster grows. 2. Assassin II had no target image at all.5813aeb6renamed hsh/MFD/assassinii.bmp to assassin2.bmp to match texturename[], but mechnames[] is a separate list and still said "assassinii", so the tile was never written and the mech showed whatever the freshly created texture happened to contain. mechnames[5] is now "assassin2"; the two arrays agree on all 65 ids. 3. Behemoth II's cockpit doll texture was missing, and that one is fatal. texturename[12] is "behemothii" but the texture was named behemoth2. It was absent from the loose tree, from textures.hint and from the packed textures.mw4. HUDDamage::Reset -> AddTexture -> MLRTexturePool::Add -> ResourceImagePool::LoadImageGOS resolves content\textures\hud\behemothii.tga, and on a miss LAB_ONLY substitutes a placeholder while Release does STOP("Texture ... could not be found!"). m_MechID there is the player's own mech, so flying a Behemoth II in a Release build should have been a hard stop -- masked in Profile by the placeholder. Three of the four layers already said "behemothii", so the texture was the outlier: behemoth2.tga is renamed to behemothii.tga and its hint page follows. The art is unchanged; it is byte-identical to behemoth.tga, since Behemoth II deliberately inherits Behemoth's doll. Also removed the orphans left by5813aeb6-- hsh/hud/assassinii.bmp, hsh/radar/hud/assassinii.bmp, Content/textures/HUD/Assassinii.tga and the [hud\assassinii] pool page. Nothing referenced them. The two stray dolls were not identical to the assassin2 pair (0.5% and 9.5% of pixels), so coord.cpp row 5 was scored against both first: identical results (MFD 0.925, Radar 0.934), i.e. same component geometry with faint re-encode noise. hsh/Mechs/assassin ii.bmp is deliberately kept -- portraits are keyed by the localised display name, not by texturename[]. Verified: every string-keyed per-mech art lookup now resolves for all 65 chassis -- mechnames[] into hsh/MFD, and texturename[] into hsh/hud, hsh/radar/hud and Content/textures/HUD -- with zero disagreements between the two arrays. The other behemoth2 entries in textures.hint are the mech skin and footstep pages and are untouched; a global rename there would have broken the skin. Needs a Release and Profile rebuild for the code, and a textures.mw4 repack for the hint and art changes. Worth confirming on hardware by targeting a Zeus and an Assassin II, and by flying a Behemoth II in the Release build. Co-authored-by: Claude Opus 5 (Anthropic) <noreply@anthropic.com> Co-authored-by: GitHub Copilot <copilot@github.com>
The binaries directory is where your plugins get put when you compile them. This is not the directory to use if you want to check in a binary of your plugin. This directory is in sourcesafe to assist in setup of 3DSMax2 development. Standard debug levels for 3DSMax2 are : rel - no debug - no debug memory hybrid - debug - no debug memory debug - debug - debug memory The now 3 levels for Stuff Armor and there corrilation between max are : Release - - rel max - Fully optimized, no debug, not LAB_ONLY Profile - - rel max - Fully optimized, some debug, LAB_ONLY Debug - - debug max - Varying level of armor, full debug, LAB_ONLY, When you compile the 3ds project the plugin will go into either the debug or rel directory, whichever is apporpriote to the copy of 3DSMax you must run it under. When you compile a plugin if it has been built in the directory it will be overwritten by the new dll. (IE: if you compile a Release and then a Profile only your Profile will exist since they share directories) Plugins must not be mixed. If the plugin is for the Release version of 3DSMax2 you must not run it under the debug version of 3DSMax2. -------------------------------- Setup For Existing Workspaces: -------------------------------- 3DSMax2 setup: I recommend installing max *without* the sdk ( all the sdk is included in the MW4 source control ). I also recomend installing the debug version *next* to the regular verson of max off of your root drive. example: c:\3DSMax2 c:\Maxdbg20 Under your release copy of max: File|Configure Paths|Plugins Tab|Add.. {driveletter}:\mw4\Code\3DSPlugins\Binaries\Rel Under your debug copy of max: File|Configure Paths|Plugins Tab|Add.. {driveletter}:\mw4\Code\3DSPlugins\Binaries\Debug Setup For project: Project|Settings|Debug Tab Choose the version from the "settings for" combo box for release and profile set the "Executable For Debug Session" to: {driveletter}:\3DSMAX2\3dsmax.exe for debug set: {driveletter}:\Maxdbg20\3dsmax.exe Once this is done everything should work as usual for compiling and debuging. --------------------- Adding a project --------------------- When adding a project make sure to copy the debug levels from other projects. Make sure to *NOT* specify any libries by adding them to the resource tree. Instead type the names into the : Project:Settings:Link Tab:General Object/Library Modules Just type the library names in with spaces seperating them and no paths. This way it will use the appropriate libraries ( debug, release ). Here is all the info needed for creating a new project. These are 3DSMax2, MFC, Stuff Defines Project|Settings|C/C++|General|Processor Definitions release WIN32,NDEBUG,_WINDOWS,_USRDLL,_WINDLL,MULTI_PLAYER,USE_PROTOTYPES,STRICT,TEST_CLASS=50 Profile WIN32,NDEBUG,_WINDOWS,_USRDLL,_WINDLL,LAB_ONLY,MULTI_PLAYER,USE_PROTOTYPES,STRICT,TEST_CLASS=50 Debug WIN32,_DEBUG,_WINDOWS,_USRDLL,_WINDLL,LAB_ONLY,MULTI_PLAYER,USE_PROTOTYPES,STRICT,TEST_CLASS=50 Project|Settings|Link|General|Object/Library Modules debug build must have NAFXCWD.LIB Project|Settings|C/C++|General|Warning level is 3 for all 3dstudio compiled programs. Project|Settings|C/C++|General|Optimizations is maximize speed for release and profile, disabled for Debug. Project|Settings|C/C++|Code Generation is PentiumPro for all configurations. Project|Settings|C/C++|Code Generation Runtime Lib is Multithreaded for rel & prof and multithreaded debug for debug. Project|Settings|C/C++|C++ Language|Enable Run-Time Type Information is set for all configurations. Project|Settings|C/C++|Optimizations|Inline Function is set to Any Suitable for rel & prof and disabled for debug. Project|Settings|Link|General|Generate Debug information is set for profile and debug and disabled for profile Project|Settings|Resource|PreProcessor Definitions NDEBUG for rel and profile and _DEBUG for debug