Metal Gear Solid 5 Ground Zeroes/Phantom Pain g0s archive

CantStoptheBipBop · **Posted:** Sun Jan 01, 2017 10:55 pm

unknown123 wrote:

More info about it?

I deleted the save a few days ago, but it came about from messing with Const/Flow lua files. I set everything to auto-develop (p62=1) and may have changed a couple of other things, but that's the gist of it. It created a slot in the secondary and primary (hip) weapon choices that essentially worked like the NONE slot when choosing a primary (back) weapon. The name and info displays both just had " --- " as their entries. I'll mess with it some more and share if I find out any specifics for duplicating it.

You can make the ads go away by registering

unknown123 · **Posted:** Sun Jan 01, 2017 11:01 pm

CantStoptheBipBop wrote:

unknown123 wrote:

More info about it?

I deleted the save a few days ago, but it came about from messing with Const/Flow lua files. I set everything to auto-develop (p62=1) and may have changed a couple of other things, but that's the gist of it. It created a slot in the secondary and primary (hip) weapon choices that essentially worked like the NONE slot when choosing a primary (back) weapon. The name and info displays both just had " --- " as their entries. I'll mess with it some more and share if I find out any specifics for duplicating it.

Ah, that's just a mod of mine that got ported into IH, see https://github.com/unknown321/mgsv_research/blob/gh-pages/mods/good_subsistence/good_subsistence/Assets/tpp/motherbase/script/EquipDevelopConstSetting.lua#L17747. New entries have ids 900 and 901, empty slots for handgun and primary. Probably you tried it at one point and forgot to remove.

CantStoptheBipBop · **Posted:** Sun Jan 01, 2017 11:21 pm

unknown123 wrote:

that's just a mod of mine that got ported into IH

Oh I didn't know about that, it would explain why I'm having trouble replicating it. Thanks for letting me know. I probably would have been at it for a couple of hours trying to repeat the impossible.

morbidslinky · **Posted:** Mon Jan 02, 2017 8:51 am

@tex

It seems that using IH's "startOffline" toggle also restricts me from developing/equipping the cosmetic DLC's.I tinkered with the init_sequence.lua, and I believe I have a solution.
This is a quick revision I made to init_sequence.lua: https://drive.google.com/file/d/0B4HIOk1QhmKAdThQSnFNYUNhLUU/view?usp=sharing. TL;DR I rerouted CreateOrLoadSaveData() to Seq_Demo_CheckDlc, Instead of Seq_Demo_Init. Then, I rerouted Seq_Demo_CheckDlc to Seq_Demo_CheckPatchDlc. Otherwise, the DlcAnnouncePopup appears every time I start the game offline.

I hope this was useful to you.

@everyone,

I recently created a discord server for MGSV modding community. I know that the MGSV Xentax community is geared more towards research, but maybe you guys might be interested nonetheless.
Here's a link: https://discord.gg/6kf9cJZ

Anyway, Happy New Year!

nasanhak · **Posted:** Mon Jan 02, 2017 4:42 pm

CantStoptheBipBop wrote:

Was playing around with devFlow/Const lua files and got the console dlc to remain usable after being developed by changing their p69 values in devFlow to 0. The exceptions being player fatigues. The dev icons will still display but won't pop up a message about needing to be in Sortie Prep to equip them while in the ACC and do not appear as options in the field. Any ideas why that is?

Paul44 and I looked into enabling DLCs. Can't be done via code. While you'll unlock the dev trees by setting p69=0, the guns show in the Equip/Supply drop menus but outfits do not. There is an exe function hiding them I guess. If you start the mission with the DLC guns, they are removed. You can however supply drop them in.

The exception to this are the two D-Horse tacks - they work just fine.

So there is an exe level check hiding outfits from the Equip/Supply drop menus plus an exe level check that removes the DLC guns. There is an additional safety check in the exe that resets the outfit to Olive Drab for when you move a save file from a game with any DLC outfit equipped to a game that doesn't have them. This safety check also was not present prior to v1.006. These exe checks work with info from the Steam API.

TppTerminal has a AcquireDlcItemKeyItem function that prior to v1.006 was tasked with unlocking DLC. But at the time DLC wasn't present in the game. After v1.006, manipulating this function correctly only unlocks the Gold Bionic Arm (and maybe the GZ Sneaking Suit but not 100% sure about this) but not any of the other DLCs.

So, it is impossible to unlock the DLC via code. It is possible to unlock it via a particular Steam related hack.

CantStoptheBipBop wrote:

Also apparently there are "none" weapon slot options for primaries and secondaries that let you just not equip anything. Having that as a permanent toggle option for those two weapons is pretty convenient.

Tex added the extra NONE slot definitions to start2nd.lua. So not sure how you managed to get the extra slots by editing the Const/Dev files! You may have been tinkering with some other modded file.

CantStoptheBipBop · **Posted:** Mon Jan 02, 2017 6:34 pm

nasanhak wrote:

So, it is impossible to unlock the DLC via code. It is possible to unlock it via a particular Steam related hack.

It kind of makes me wonder why they bothered setting up checks for the console dlc since they refuse to take my money by offering them individually or as a pack, rather than exclusive to people willing to buy the same two games again.

Anyway can you share what you know about the Steam method of getting them?

nasanhak wrote:

You may have been tinkering with some other modded file.

Probably something like that. I think I may have disabled Snakebite's compatibility check or something while IH was already installed.

unknown123 · **Posted:** Mon Jan 02, 2017 6:41 pm

CantStoptheBipBop wrote:

Anyway can you share what you know about the Steam method of getting them?

Exe makes a call to steam services using steam_api64.dll checking if you own corresponding dlcs. You can change this behaviour by using dlls from pirated versions and fiddling with settings, but this will make the game illegal.

nasanhak · **Posted:** Tue Jan 03, 2017 3:46 pm

CantStoptheBipBop wrote:

Anyway can you share what you know about the Steam method of getting them?

Against forum rules! Piracy(even if DLC) and any kind of hack related discussion is off limit. You can find the info you are looking for via Google and Reddit easily enough though. Valve doesn't seem to care much about the hack itself

CantStoptheBipBop · **Posted:** Tue Jan 03, 2017 7:13 pm

unknown123 wrote:

Exe makes a call to steam services using steam_api64.dll checking if you own corresponding dlcs. You can change this behaviour by using dlls from pirated versions and fiddling with settings, but this will make the game illegal.

Thanks for the info. I figured out what to look for from that.

nasanhak wrote:

Valve doesn't seem to care much about the hack itself

That seems to be the consensus from random messages I read in my search. Anyway I guess it does fall under pirating so I'll just stop discussing it.

I found out the one thing I was really curious about with the console DLC. Black Ocelot really does get a nighttime camo bonus. I tried it out on a few different surface types at night and guard suspicion range never raised from 15m when crouch walking while the guard's vision cone was baited towards me via decoy. The player camouflage bonus lua file only deals with surface decals and models so I'm not sure how you'd go about giving a uniform a nighttime bonus.

Aside from that I've been experimenting with vehicles and damage/blast parameters lately. Not too much to share about the vehicles since that last time I talked about the physics files, just that I'm getting them a little more fine-tuned. Or perhaps usable is a better word.

Code:

|*.veh|
<"PhVehicleAxisParam">
    <"maxBreakTorque"> <!--max braking power each axle-->
        <value>1234</value>
    </>
</>

<"PhVehicleNormalEngineParam">
    <"specPointAngularVelocity" arraySize=7> <!--factor in speed each gear-->
         <value>1234</value>
    </>
    <"specPointTorque" arraySize=7> <!--engine torque each gear-->
         <value>1234</value>
    </>
    <"specPointBreakTorque" arraySize=7> <!--seems to be braking power each gear-->
         <value>1234</value>
    </>
</>


|fpkdName.fox2| <!--sets weapon params, ui, vehicle index, instance counts-->
<"TppVehicle2WeaponParameter">
    <name="attackId" type="string"> <!--TppDamage.ATK_[string]; check EquipParameters.lua-->
        <value>ATK_Tankgun_30mmAutoCannon</value>
    </>
    <name="bulletId" type="string"> <!--TppEquip.BL_[string]; EquipParameters.lua-->
        <value>BL_Tankgun_30mmAutoCannon</value>
    </>
    <name="fireInterval" type="float"> <!--rate of fire; E=60\x where x is the desired RoF-->
        <value>0.12</value> <!--500RPM-->
    </>
    <name="minPitch" type="float"> <!--turret max depression angle-->
        <value>-0.04</value> <!-- -4 degrees-->
    </>
    <name="maxPitch" type="float"> <!--turret max elevation angle-->
        <value>0.6</value> <!--60 degrees-->
    </>
    <name="rotSpeed" type="float"> <!--turret rotation speed in degrees per second-->
        <value>0.3</value>
    </>
</>

You can also tweak vehicle performance by changing tire friction and vehicle body mass but it causes the physics to start acting funky, mainly when it comes to tire friction. Vehicle weapon number value types that are floating points apparently need to stay as that. It doesn't seem to matter if the value you're entering falls under uint8 or not.

The stuff I did with blast parameters is related to the vehicle tweaks. Namely you can make anti-tank missiles and HEAT tank shells behave like you'd expect them to (realistically you'd pretty much have to get hit directly with a HEAT round). Peace Walker did this pretty well so no idea why it changed in TPP, but I'm getting off topic.

Code:

EquipParameterTables.lua
BlastParameter={0,
    {TppEquip.BLA_[name], blastFlag, p2, p3} -- p2 seems to always be the damage/effect/warning range; p3 doesn't appear to change anything
    {TppEquip.BLA_ms00, 4, 0.1, 0} -- GROM-11 modified to only damage on direct hits
}
SupportWeaponParameter={0,--[p0==name, p1==ammoTotal, p2-3==check below, p4==grade]
   --[[Category
      [grenade]:    p2==fuse,             p3==effectDuration
      [mine]:      p2==triggerDistance,   p3==triggerConeDegrees
      [mineEMN]:   p2==triggerDistance,   p3==effectDuration
      [bait]:      p2=? aiAudioDistance or effectDistance,   p3==effectDuration
      [decoy]:   p2==durability
   ]]
    {TppEquip.SWP_[p0], p1, p2, p3, p4}
    {TppEquip.SWP_DMine, 6, 2.5, 120, 3} -- [mine]
}

nasanhak · **Posted:** Tue Jan 03, 2017 7:38 pm

CantStoptheBipBop wrote:

I found out the one thing I was really curious about with the console DLC. Black Ocelot really does get a nighttime camo bonus. I tried it out on a few different surface types at night and guard suspicion range never raised from 15m when crouch walking while the guard's vision cone was baited towards me via decoy. The player camouflage bonus lua file only deals with surface decals and models so I'm not sure how you'd go about giving a uniform a nighttime bonus.

I had an exchange with jvarnes over from Nexus in March 2016 and here's what he had to say:

Quote:

So I can't find any of my MGS stuff (grrrreat). Here is what I can tell you based on my faulty memeory:

I never figured out *exactly* which number mapped to which specific ground texture (except maybe red Dirt since it was the only texture in that camo that was affected), but you can kind of figure out which "groups" of textures they are based by the camo iteslf. i.e. Golden Tiger only works on one terrain texture - the red dirt texture, Square works on all kinds of concrete/metal/flooring, Wetwork on the African marshy textures, Woodland/Olive drab on all the grass/bush textures, etc.

There is no entry for darkness/night time/shadow. My best guess is this is designated somewhere else. Splitter also has all zeros for it's terrain so either it simple doesn't work (couldn't 100% confirm) or again this special ability (camo while in a vehicle or mounted gun) is set elsewhere.

Camos were (hope I get this order right and hopefully they've added the new camos to the bottom of the list):

Olive Drab, Splitter, Square, Tiger Stripe, Gold Tiger, Desert Fox, Woodland, Wetwork, Gray Urban (same mappings as Square), Blue Urban (same mappings as Wetwork), ADP (desert fox + woodland)

Dunno where black ocelot falls, but I suspect it's one of the many zero ones on the end which most likely map to things like raiden, ninja, etc. since none of those costumes give a terrain camo bonus. If i had to guess Black ocelot is the very next value after ADP. BTW dunno how far this file has changed in the newer patches because I have even looked at the game in a few months. Based on the prior additions my guess is either they tacked the new camos to the end or they filled in some of those lines which were orginally zeros.

The camo numbers act as some kind of negative % penalty to the AI's notice check, but they make these checks so frequently that is almost useless when moving or when they are staring directly at you. The only real effect is has is to add an extra meter or two to distance you can be crouched or prone on the matching terrain type. Carboard Boxes work so much better than any camo does. You might try raising these numbers very high (above 99) to see if you can increase the effectiveness but my testing didn't really show much conclusive beyond I could crouch approach a few meters closer if the numbers were very high (over 60).

To give a camo the benefits of another one just carefully copy the numbers from one camo to another. Like I said these appear to be grouped into related textures.

In the end the changes I made to camo were the least impactfull because well in my testing camo has the least effective use. In nearly every situation the box, shadows, weather, etc. are far more effective means of not being noticed since they actively reduce the amount of meters that vision cones and hearing radius reach out to.

Anyway that's the best I can offer. Like anything with modding it takes a lot of trial and error and testing to find results. If you uncover more you may want to include your discoveries in a readme or what not so future modders like yourself can benefit. I clearly should have added more nuts and bolts data to mine

Good luck with the modding and hope you are still enjoying the game!

PS - I think it's a fantastic stealth and open world game. I just can't stand the story and campaign mode any more. I beat the game and that's good enough for me.

From my own experience, soldier sight works on an update function which likely updates every frame. There's a chance for the soldier to see you that is calculated every update. This is evident by the fact that while standing still within the 60m radius a soldier will see you all of a sudden when he couldn't a few seconds earlier. Likely this is an exe thing which is what would be needed for a real time system anyway.

Apart from camo indexes, all suit properties are part of the exe - the noise(again real time) they make as well as any special properties like the nigh time bonus or the higher healing rate of the Sneaking Suit or the damage resistance of the Battle Dress.

It's obvious there's no Lua for these and maybe a fox2 is responsible for assigning properties.

I do remember that after the v1.006 update The Boss and Naked Snake Sneaking Suits had broken sound elimination. An exe update is what fixed those.

Also, great work identifying the vehicle properties as well as the missile blast params.

CantStoptheBipBop · **Posted:** Tue Jan 03, 2017 9:28 pm

nasanhak wrote:

There's a chance for the soldier to see you that is calculated every update.

edit:Assets\tpp\pack\location\afgh\pack_common\afgh_common_fpkd\Assets\tpp\level\location\afgh\block_common has a lot of interesting things that sound like they should modify the effects of camo index. afgh_common_terrainMaterial.fox2 has collisionMaterialName properties with values that assign materials under the entity class GeoxTextureMaterialRegister. So for searching for what the material is assigned to like I mentioned further down you'd just preface the material with MTR_ (MTR_TURF_A). The properties under entity class ObjectBrushPluginBushDataElement in afgh_common_objectBrush.fox2 are also pretty interesting. camoufDensity, camofRadius, camofHeight properties may have something to do with the bushDensityThresold value in Soldier2ParameterTables.lua.

/edit

The special suit properties are probably all exe stuff like you were saying though. The most convincing part being what you said about an exe patch fixing sneak suit step noise. I've tried diving into different suit fpkd files before but didn't see anything that seemed connected to abilities. Those files seem to be mostly for handling the player model. I may as well share what I researched about the player camo file awhile back. I'm pretty confident about the material and fatigue names being accurate. You can look up the material name (MTR_IRON_A) in the location fpkd files to see what objects have been assigned it, and then check the texture files to see what it looks like. The unused materials in the camo file seem to mostly be small shit not worth bothering with anyway (tents, buckets, stuff like that). The material name order was acquired from RecoilMaterialTable.lua. EVA outfit is one of the greenery/desert mix camo types between PANTHER and C23.

Code:

|player2_camouf_param.lua| -- 78 table entries

this.fieldClothings={--o50050_sequence.lua 
   PlayerCamoType.OLIVEDRAB,
   PlayerCamoType.SPLITTER,
   PlayerCamoType.SQUARE,
   PlayerCamoType.TIGERSTRIPE,
   PlayerCamoType.GOLDTIGER,
   PlayerCamoType.FOXTROT,
   PlayerCamoType.WOODLAND,
   PlayerCamoType.WETWORK,
   PlayerCamoType.ARBANGRAY,
   PlayerCamoType.ARBANBLUE,
   PlayerCamoType.SANDSTORM,
   PlayerCamoType.BLACK,
   PlayerCamoType.MGS3,
   PlayerCamoType.PANTHER,
   PlayerCamoType.C23,--table 37
   PlayerCamoType.C24,
   PlayerCamoType.C27,
   PlayerCamoType.C29,
   PlayerCamoType.C30,
   PlayerCamoType.C35,
   PlayerCamoType.C38,
   PlayerCamoType.C39,
   PlayerCamoType.C42,
   PlayerCamoType.C46,
   PlayerCamoType.C49,
   PlayerCamoType.C52,
   PlayerCamoType.C16,--table 49
   PlayerCamoType.C17,
   PlayerCamoType.C18,
   PlayerCamoType.C19,
   PlayerCamoType.C20,
   PlayerCamoType.C22,
   PlayerCamoType.C25,
   PlayerCamoType.C26,
   PlayerCamoType.C28,
   PlayerCamoType.C31,
   PlayerCamoType.C32,
   PlayerCamoType.C33,
   PlayerCamoType.C36,
   PlayerCamoType.C37,
   PlayerCamoType.C40,
   PlayerCamoType.C41,
   PlayerCamoType.C43,
   PlayerCamoType.C44,
   PlayerCamoType.C45,
   PlayerCamoType.C47,
   PlayerCamoType.C48,
   PlayerCamoType.C50,
   PlayerCamoType.C51,
   PlayerCamoType.C53,
   PlayerCamoType.C54,
   PlayerCamoType.C55,
   PlayerCamoType.C56,
   PlayerCamoType.C57,
   PlayerCamoType.C58,
   PlayerCamoType.C59,
   PlayerCamoType.C60,
}

        -- /U==urban    /D==desert    /W==swamp/farmland    /R==redsoil    /M==mountain/rocky    /G==greenery
   {--82 materials
      0,--IRON_A      /U
      0,--IRON_B      /U
      0,--IRON_C
      0,--IRON_D
      0,--IRON_E      /U
      0,--IRON_F      /U
      0,--IRON_G      /U
      0,--IRON_M      /U
      0,--IRON_N      /U
      0,--IRON_W      /U
      0,--PIPE_A      /U
      0,--PIPE_B      /U
      0,--PIPE_S      /U
      0,--TIN_A
      0,--FENC_A      /U
      0,--FENC_B      /U
      0,--FENC_F      /U
      0,--CONC_A      /U
      0,--CONC_B      /U
      0,--BRIC_A
      0,--PLAS_A
      0,--PLAS_B
      0,--PLAS_W
      0,--PAPE_A
      0,--PAPE_B
      0,--PAPE_C      /U
      0,--PAPE_D
      0,--RUBB_A      /U
      0,--RUBB_B      /U
      0,--CLOT_A
      0,--CLOT_B
      0,--CLOT_C
      0,--CLOT_D      /U
      0,--CLOT_E      /U
      0,--GLAS_A
      0,--GLAS_B
      0,--GLAS_C
      0,--VINL_A
      0,--VINL_W
      0,--TILE_A      /U
      0,--TLRF_A
      0,--ALRM_A
      0,--COPS_A
      0,--COPS_B
      0,--BRIR_A
      0,--BLOD_A
      0,--SOIL_A      /D
      0,--SOIL_B      /D
      0,--SOIL_C      /W
      0,--SOIL_D      /W
      0,--SOIL_E      /W
      0,--SOIL_F
      0,--SOIL_G      /R
      0,--SOIL_H      /W
      0,--SOIL_R      /D
      0,--SOIL_W      /M
      0,--GRAV_A      /D
      0,--SAND_A      /D
      0,--SAND_B      /D
      0,--SAND_C      /D
      50,--LEAF      /G
      0,--RLEF
      0,--RLEF_B
      50,--WOOD_A      /G
      50,--WOOD_B      /G
      50,--WOOD_C      /G
      50,--WOOD_D      /G
      50,--WOOD_G      /G
      50,--WOOD_M      /G
      50,--WOOD_W      /G
      0,--FWOD_A
      50,--PLNT_A      /G
      0,--ROCK_A      /M
      0,--ROCK_B      /M
      0,--ROCK_P
      50,--MOSS_A      /G
      50,--TURF_A      /G
      0,--WATE_A
      0,--WATE_B      /W
      0,--WATE_C
      0,--AIR_A
      0--NONE_A
   },

CantStoptheBipBop · **Posted:** Mon Jan 09, 2017 12:28 am

So update on the camo stuff. I've made a ton of progress on it and have the important stuff figured out. All of the lua tables are now ID'd aside from six that don't receive bonuses (Sneaking Suit (NS) is one of those). The associated textures and models for bonuses are ID'd as well with the exception of greenery model bonuses and urban bonuses. I've also written a lua file to write a customized version of player2_camouf_param.lua. It's pretty self-explanatory just change the camoParam.materialAssignment values to a different material table key if you want to change it or create a new table within material with a string(s) from material.nameToIndex.

Wet/Swamp soil
Rocky soil
Red soil
Greenery soil
Desert soil and models

ROCK_B covers basically every rock model, including the ruins where you fight quiet.
Desert: stone AFGH buildings are SOIL_A, sandbags are SAND_B.

The lua file I linked has comments in the material table with a little more info. I just don't feel like writing it out again. I did a recount of the entries and there are 91 tables, not 72 or whatever I said. The camo notes were kind of old.

Anyway here's a lua with default values that's commented with fatigue names before each table.

I tried out a mod with lower values than 50 but at <32/40 (can't remember what I set it at) guard suspicion range jumped up to 70m when standing on the appropriate surface in daylight. Above those numbers it was a flat 45m. So I'd say the way camo affects AI vision is by player camo index being in x-y range. e.g. 100-150=45m, 0-99=70m.

Tex · **Posted:** Tue Jan 10, 2017 11:57 pm

nasanhak wrote:

@Tex
I saw some problems with my start on foot LZs for MB and realized that vars.mbLayoutCode is not always 3 and does indeed change with time.

I mentioned this on Nexus back in May lol, but I only came across it myself because I was following up another bug back then (and I probably have missed a bunch in your messages myself so no worries)

nasanhak wrote:

vars.mbLayoutCode changes with each Command plant built. The overall MB layout depends on the Command cluster layout. The surrounding clusters attach to command and as a result, their position offsets change as more Command plants are built

Ah, that makes sense, good info.

nasanhak wrote:

vars.mbLayoutCode has not incremented by the time ReservePlayerLoadingPosition is called

Nice catch, thanks, doesn't seem to be any clear workaround, can't find any other variables with accurate equivalent info.
TppMotherBaseManagement.GetMbsClusterGrade seems to be updated at the same point as mblayout, other stuff is based on those rather than being independent.
So I guess the fallback is to shift the player back to the actual position on map start if they're out of bounds (the game already does this for a couple of situations, but it's at a point before mblayout is updated)

morbidslinky wrote:

@tex
It seems that using IH's "startOffline" toggle also restricts me from developing/equipping the cosmetic DLC's.I tinkered with the init_sequence.lua, and I believe I have a solution.

Nice fix, thank you.

CantStoptheBipBop wrote:

So update on the camo stuff..

Neato. You could probably roll the camo modding code into player2_camouf_param itself.

Still trying to pull out of change of year busyness, but going ahead I don't think I'll be developing at the same pace. Even though the IH TODO remains endless.

IH r197 also allows alternative loading of most scripts from MGS_TPP\mod\<normal assets script path>, for those that want to do some slightly more rapid experimentation of with the existing game scripts.

HeartlessSeph · **Posted:** Wed Jan 11, 2017 7:15 pm

Hey everyone, got a new script for all of you to play around with. This lets you edit UVW maps on models. It is unfortunately a lot more tedious to work with since I'm too lazy to have these scripts search through the models and auto inject. First of all the link to what you need: https://www.dropbox.com/s/n9uhcxipglt19 ... g.zip?dl=0

Okay first things first, you'll need to import the model you're going to be UV editing using the MGSV Import script that I provided in the link. You HAVE to use that one unless you know the size of the Vbuffer. Immediately, open up the MaxScript Listener and it will list (multiple times) the value you need to use. Now open up Inject UV Maps.ms toward the bottom of the file it will show:

fseek f 0x1C #seek_cur
--Write the value that 3ds tells you over 1C

Just write what 3DSMax value was shown over 0x1C. Now, go back to 3DS Max and go to the models you are going to edit the UVW maps of and use the OutputUV.ms script on one mesh at a time and save them so you know it's the original file for those objects. We'll be using Object000original.UV. Now do any UVW map edits on anything you need to edit, and make sure that it's collapsed on the model (aka: Make sure that you have no modifiers.)

Here comes the annoying part: Open up your UV file, Object000original and highlight the first four bytes in the file and search for that in the model you were editing. Now that that value is highlighted inside of HxD or whatever Hex Editor you use, copy down the Address that the value is located at. Now you back into InjectUVMaps.ms and you will see this line:

fseek f 0x30E4C #seek_set
--Write the Offset where the UV Maps begin over 30E4C

Write down the offset/address that you copied over 0x30E4C. Now you can save the script and go back into 3DSMax, select the mesh that you made the UV edits to and open the InjectUVMaps.ms file. It will ask you to open up a file, go to the FMDL file that you imported from the beginning and open it. Finally, after that point all of the newly edited UV Maps should be put into your model.

I know this isn't exactly the best description of how to use this but I kind of suck at explaining stuff. If there is any confusion I will try to clear it up. At some point I'm planning on making edits to all of my scripts so that it's an auto inject into the file anyway but once again I'm a very lazy person so it might be a while.

nasanhak · **Posted:** Thu Jan 12, 2017 5:39 pm

Tex wrote:

I mentioned this on Nexus back in May lol, but I only came across it myself because I was following up another bug back then (and I probably have missed a bunch in your messages myself so no worries)

Totally remember but always thought it was unrelated lol! There was this nagging feeling at the back of my head that kept telling me to check MB LZs with a new save file. But (4 LZs*7 Clusters*4 Layouts) always seemed like a pain in the butt.

Tex wrote:

TppMotherBaseManagement.GetMbsClusterGrade seems to be updated at the same point as mblayout, other stuff is based on those rather than being independent.
So I guess the fallback is to shift the player back to the actual position on map start if they're out of bounds (the game already does this for a couple of situations, but it's at a point before mblayout is updated)

From all my testing mbLayoutCode is finally updated in TppMission.Load() and only applied during the load. Since on foot position is decided before that point in TppMain.ReservePlayerLoadingPosition, there is no way to fix it at load time.

I used a warp at TppMain.OnMissionCanStart the same as you. My warp only activates if the layout code has changed. Which means it may run only 4 times MAX instead of every time unlike yours(albeit with a -9 height posY check) but there doesn't seem to be a clean way to fix this.

Also and this is interesting, since I am using a fake heli gimmick, the heli actually uses the PullOutRoute for MB. When the MB layout changes, the heli route is still the same but the heli spawn point is correctly over the new LZ co-ords. This means that routes may be pos based?

The PullOut route is nothing but the Drop Route with a different suffix:
DropRt: ly003_cl00_30050_heli0000|cl00pl2_mb_fndt_plnt_heli_30050|rt_apr
PullOutRt: ly003_cl00_30050_heli0000|cl00pl2_mb_fndt_plnt_heli_30050|rt_tkof

For MB, only the two roof LZ PullOut routes do not follow this convention so have used StrCode32 numbers for those instead.

Also since we are already on the topic, and since this has been bugging me about your LZs code for a while, the tables in TppLandingZone are misleading:
aprLandingZoneName is actually the LZ name
drpLandingZoneName is actually the drop route. "_drp_" is simply added between the "lz" and actual name part

There are proper approach routes for each free roam(non-MB) LZ present which can be used by replacing "_drp_" with "_apr_" if I remember correctly. These are used by default when the heli is called from stand by to an LZ.

I could not figure out the names for the take off routes for free roam so ended up using the integer values lol. Yes lots and lots of deployments and pullouts.

EDIT:
Almost forgot and this is interesting lol. After you pointed me to init.lua for your InfLog, I decided to do the same myself. Loading Settings, InfInspect, Log and Startup luas in init and I now see you have done the same

And it seems Init(missionTable) as well as OnReload(missionTable) functions are required when creating a messageExecTable in a _requireList Lua table. Otherwise if the message is tied to a "sender", it will not work. It will work without these functions provided a sender is not present. This is weird behavior but I haven't debugged as to why this is

Forum rules

Metal Gear Solid 5 Ground Zeroes/Phantom Pain g0s archive

Who is online