Metal Gear Solid 5 Ground Zeroes/Phantom Pain g0s archive

[unknown123]

Btw I'm using Gztools, can I edit the un-named fpks then repack them as un-named again?

I am pretty sure you can, nothing stops you.

[nasanhak]

@unknown123 and @Tex

EquipDevelopConstSetting(Const file)
New Entries:

Code: Select all

TppMotherBaseManagement.RegCstDev{p00=900,p01=TppEquip.EQP_None,p02=TppMbDev.EQP_DEV_TYPE_Handgun,p03=0,p04=0,p05=65535,p06="cmmn_wp_none",p07="cmmn_wp_none",p08="/Assets/tpp/ui/texture/EquipIcon/ui_dev_dummy_alp",p09=65535,p10="cmmn_wp_none",p30="cmmn_wp_none",p31=0,p32=0,p33=0,p34=0,p35=0,p36=0}
TppMotherBaseManagement.RegCstDev{p00=901,p01=TppEquip.EQP_None,p02=TppMbDev.EQP_DEV_TYPE_Assault,p03=0,p04=0,p05=65535,p06="cmmn_wp_none",p07="cmmn_wp_none",p08="/Assets/tpp/ui/texture/EquipIcon/ui_dev_dummy_alp",p09=TppMbDev.EQP_DEV_GROUP_Assault,p10="cmmn_wp_none",p30="cmmn_wp_none",p31=0,p32=0,p33=0,p34=0,p35=0,p36=0}
TppMotherBaseManagement.RegCstDev{p00=902,p01=TppEquip.EQP_None,p02=TppMbDev.EQP_DEV_TYPE_Shotgun,p03=0,p04=0,p05=65535,p06="cmmn_wp_none",p07="cmmn_wp_none",p08="/Assets/tpp/ui/texture/EquipIcon/ui_dev_dummy_alp",p09=TppMbDev.EQP_DEV_GROUP_None,p10="cmmn_wp_none",p30="cmmn_wp_none",p31=0,p32=0,p33=0,p34=0,p35=0,p36=0}
TppMotherBaseManagement.RegCstDev{p00=903,p01=TppEquip.EQP_None,p02=TppMbDev.EQP_DEV_TYPE_GrenadeLauncher,p03=0,p04=0,p05=65535,p06="cmmn_wp_none",p07="cmmn_wp_none",p08="/Assets/tpp/ui/texture/EquipIcon/ui_dev_dummy_alp",p09=TppMbDev.EQP_DEV_GROUP_None,p10="cmmn_wp_none",p30="cmmn_wp_none",p31=0,p32=0,p33=0,p34=0,p35=0,p36=0}
TppMotherBaseManagement.RegCstDev{p00=904,p01=TppEquip.EQP_None,p02=TppMbDev.EQP_DEV_TYPE_Submachinegun,p03=0,p04=0,p05=65535,p06="cmmn_wp_none",p07="cmmn_wp_none",p08="/Assets/tpp/ui/texture/EquipIcon/ui_dev_dummy_alp",p09=TppMbDev.EQP_DEV_GROUP_None,p10="cmmn_wp_none",p30="cmmn_wp_none",p31=0,p32=0,p33=0,p34=0,p35=0,p36=0}

All new entries to this file need to be added at the end. Otherwise dev flow, equip menus, sometimes even the sortie prep screen exit breaks. So order of this file matters. But it matters for a very specific reason I haven't figured out yet - maybe never will.

-------------------------------------------------------------------------------
EquipDevelopFlowSetting(Flow file)
New Entries:

Code: Select all

TppMotherBaseManagement.RegFlwDev{p50=876,p51=0,p52=0,p53=0,p54=0,p55=0,p56=0,p57=0,p58="",p59=0,p60="",p61=0,p62=0,p63=0,p64=0,p65="",p66=0,p67="",p68=0,p69=0,p70=0,p71=0,p72=0,p73=0,p74=0}
TppMotherBaseManagement.RegFlwDev{p50=877,p51=0,p52=0,p53=0,p54=0,p55=0,p56=0,p57=0,p58="",p59=0,p60="",p61=0,p62=0,p63=0,p64=0,p65="",p66=0,p67="",p68=0,p69=0,p70=0,p71=0,p72=0,p73=0,p74=0}
TppMotherBaseManagement.RegFlwDev{p50=878,p51=0,p52=0,p53=0,p54=0,p55=0,p56=0,p57=0,p58="",p59=0,p60="",p61=0,p62=0,p63=0,p64=0,p65="",p66=0,p67="",p68=0,p69=0,p70=0,p71=0,p72=0,p73=0,p74=0}
TppMotherBaseManagement.RegFlwDev{p50=879,p51=0,p52=0,p53=0,p54=0,p55=0,p56=0,p57=0,p58="",p59=0,p60="",p61=0,p62=0,p63=0,p64=0,p65="",p66=0,p67="",p68=0,p69=0,p70=0,p71=0,p72=0,p73=0,p74=0}
TppMotherBaseManagement.RegFlwDev{p50=880,p51=0,p52=0,p53=0,p54=0,p55=0,p56=0,p57=0,p58="",p59=0,p60="",p61=0,p62=0,p63=0,p64=0,p65="",p66=0,p67="",p68=0,p69=0,p70=0,p71=0,p72=0,p73=0,p74=0}

After much, much testing, order of Flow file does *not* matter - confirmed by rearranging entries. As long as EquipDevelopConstSetting has new entries added at the end, then order makes no difference in this file, at least with initial testing. p50 IS IMPORTANT and has to be unique. *p50* corresponds to the order entries are made at in the Const file, meaning:
Entry 1 in Const file is related to the Flow file using p50=0
Entry 236 in Const file is related to the Flow file using p50=235
Entry 700 in Const file is related to the Flow file using p50=699

Setting additional entries with p50=0 breaks the dev flow in a very subtle way:
What the first pistol should look like: https://imgur.com/cF9DB9e
What it looks like if additional entries have p50=0: https://imgur.com/bbvRS9X

Look at the grade info and the star replaced by a dash. Ignore the low GMP for how it should look due to my modded files.

In fact, since the "entries" are nothing more than function calls, if you add additional entries with p50=0, then it is pointless as the p50 id 0 belongs to this pistol and all additional Flow info that you really want to be adding is actually being defaulted by the game

-------------------------------------------------------------------------------
This next part puzzles me:

These file are not really called line by line, that was just an incorrect impression.

Do not know how the two files are linked together however - as in how the game decides that okay this is the 1st entry in the Const file. If the Const file is called in one go, then what difference does it's order make? But all our testing confirms that the Const file order does matter. So how and where is it called from?

1. It is called during the game's bootup phase where all Lua code is compiled. I can confirm this by having used print statements at the end which are printed before the auto save popup.

2. But how is the Const file called then? Does the game store all TppEquip items in a call table(CT1 for example) using a predetermined index, then iterate over this file in order of the index using p01 as a match? If that were the case then any new items would have to be added to CT1 as well and we would not be able to add in the EQP_None items(or any additional items) at all because the game would not even be looking for them correct. Not to mention newlines make no difference.

-------------------------------------------------------------------------------
Observations:

Rearranging entries in the Const and Flow files similarly breaks dev flow.
Adding new entries to Const at the top breaks dev flow.
Adding new entries to Const and Flow files at the top and then setting the Flow file to start new entries with p50=0 and incrementing all existing entries accordingly breaks dev flow.
Incrementing/changing p50 in Flow file alone breaks dev flow.

So, the game EXPECTS the entries in the Const file to be in a particular order. How and why - no idea. There is definitely a third table somewhere but maybe not in the available code.
-------------------------------------------------------------------------------
Why the hell does the Const file order matter?!

[unknown123]

EquipDevelopConstSetting(Const file)
All new entries to this file need to be added at the end. Otherwise dev flow, equip menus, sometimes even the sortie prep screen exit breaks. So order of this file matters. But it matters for a very specific reason I haven't figured out yet - maybe never will.

They are tied to hardcoded values in exe. TppEquip is a C class after all and all weapons (not development entries!) are hardcoded into it from the beginning. You can run strings.exe on executable to get a list of them - https://technet.microsoft.com/en-us/sys ... rings.aspx

EquipDevelopFlowSetting(Flow file)
After much, much testing, order of Flow file does *not* matter - confirmed by rearranging entries. p50 IS IMPORTANT and has to be unique.
*p50* corresponds to the order entries are made at in the Const file
Entry 1 in Const file is related to the Flow file using p50=0

Because they are assigned to the C table - indexing in C starts with 0.

Setting additional entries with p50=0 breaks the dev flow in a very subtle way:

My bad, I totally forgot that p50 has to be unique. Was so excited to finally have empty slots, that I forgot about wu pistol completely.

These file are not really called line by line, that was just an incorrect impression.
Do not know how the two files are linked together however - as in how the game decides that okay this is the 1st entry in the Const file. If the Const file is called in one go, then what difference does it's order make? But all our testing confirms that the Const file order does matter. So how and where is it called from?

They are called line by line. First, game iterates over const file, creating parent-child relations to make a development table with dev entries. Then it calls flow file line by line adding entry costs, grades and everything else using p50 as index. I believe that breaking parent-child relations is the cause of broken game - ie some weapon has a parent that hasn't been registered yet. Best way to check it would be to leave like 2-3 entries in both files and make some tests on them.

Does the game store all TppEquip items in a call table(CT1 for example) using a predetermined index, then iterate over this file in order of the index using p01 as a match?

Of course no, p01 is just an index for development entry, not a weapon itself.


Honestly I think that ordering is not that interesting as long as everything works. What bothers me more is p* keys - some of them are still a mystery.

[nasanhak]

They are tied to hardcoded values in exe. TppEquip is a C class after all and all weapons (not development entries!) are hardcoded into it from the beginning. You can run strings.exe on executable to get a list of them - https://technet.microsoft.com/en-us/sys ... rings.aspx

Well yes I did know the weapons, ammo, receivers, suit(only one entry), support items, item items, tools etc are already defined before hand. This makes it much clearer however. Still does not explain why the order matters. We can add new entries because like you said the development tree is what these files are defining.

Because they are assigned to the C table - indexing in C starts with 0.

Of course But what I meant was that the order of the Flow file does not matter as long as p50 is 1 less than the order number of the item you want it to refer to from the Const file.

They are called line by line. First, game iterates over const file, creating parent-child relations to make a development table with dev entries. Then it calls flow file line by line adding entry costs, grades and everything else using p50 as index. I believe that breaking parent-child relations is the cause of broken game - ie some weapon has a parent that hasn't been registered yet. Best way to check it would be to leave like 2-3 entries in both files and make some tests on them.

I had exactly this in mind, what I meant was that the files were not called one line at a time *together* for a particular development entry. As for breaking the parent child relationship, well if you mess around with the things I have mentioned, the development trees "shift". You can tell that the costs, grade, etc jump around to weapons/items before or after depending on how you mess with the Const file.

Does the game store all TppEquip items in a call table(CT1 for example) using a predetermined index, then iterate over this file in order of the index using p01 as a match?

Of course no, p01 is just an index for development entry, not a weapon itself.

Well not quite. p01 is unique and refers exactly to the hard coded weapon entry - check your/my dumps. TppEquip.EQP_WP_10102 has a value associated with it and this is important for all references to the weapon/item. The index that does not matter is p00 - this, although unique, can be whatever but the game must then refer to the same p00 id in code if it wants to refer to a particular weapon/item.

Basically, the code uses p00 and p01 in certain places depending on func calls.

Since the order of the file matters, and if weapons, items, suits, support items, item items and tools are all mixed together then there is obviously some way the game knows which entry corresponds to which item/equip development tree. If p01 alone were responsible, then changing order would not make any difference but that is not the case here.

Honestly I think that ordering is not that interesting as long as everything works. What bothers me more is p* keys - some of them are still a mystery.

Well yeah I know everything works but what I would like to do is to add the "None" slots to the top of the ASSAULT, SHOTGUN, GRENADE LAUNCHER, HANDGUN and SMG menus in the sortie screen. For p* keys, a way to figure them out would be to test with a save file that has not developed everything and is relatively early in the game.

I tried this to find p31, p34 and p35 but no luck yet. Still that should be the way to go about it.

[Ashtails]

Excuse me but how would I go about taking Huey's model and nulling everything except for the hair and replacing one of the avatar hair styles with it?

[unknown123]

Made a huge post about cosmetics and models - https://unknown321.github.io/mgsv_resea ... etics.html. No, there is no clear solution for simple porting hats from mgo to tpp (yet), but I think I've found stuff that leads to it.

[nasanhak]

Made a huge post about cosmetics and models - https://unknown321.github.io/mgsv_resea ... etics.html. No, there is no clear solution for simple porting hats from mgo to tpp (yet), but I think I've found stuff that leads to it.

Very nice read. And depressing. You are a good writer however

[Ashtails]

Made a huge post about cosmetics and models - https://unknown321.github.io/mgsv_resea ... etics.html. No, there is no clear solution for simple porting hats from mgo to tpp (yet), but I think I've found stuff that leads to it.

So you are getting close? And your definition of porting mgo hats is the free toggle of the hats rather than having to replace a model? That sounds pretty hard but you make it seem like it might be possible. Shigu did a video where he put the scarf and goggles on snake through what seems like coding but he said it frequently caused crashes

[unknown123]

And your definition of porting mgo hats is the free toggle of the hats rather than having to replace a model? That sounds pretty hard but you make it seem like it might be possible. So you are getting close?

Yes, like in sortie prep screen. Game does that already, so we should be able to do the same. But I am out of ideas, stuck - that was the reason for publishing all of that. I don't like to post unfinished stuff, but this has to be an exception.

Shigu did a video where he put the scarf and goggles on snake through what seems like coding but he said it frequently caused crashes

Link? I'd like to take a look.

[Ashtails]

And your definition of porting mgo hats is the free toggle of the hats rather than having to replace a model? That sounds pretty hard but you make it seem like it might be possible. So you are getting close?

Yes, like in sortie prep screen. Game does that already, so we should be able to do the same. But I am out of ideas, stuck - that was the reason for publishing all of that. I don't like to post unfinished stuff, but this has to be an exception.

Shigu did a video where he put the scarf and goggles on snake through what seems like coding but he said it frequently caused crashes

Link? I'd like to take a look.

https://m.youtube.com/watch?v=CcicEW4IHLk

Another question I have is would it be possible to replace the model of the capture cages with the plushies? I never use them sooooooo.....

[unknown123]

https://m.youtube.com/watch?v=CcicEW4IHLk

I totally forgot about glasses-scarf. Looks like he is applying fv2 files since model is not reloaded. I assume that game crashed because wrong fv2 was applied.

Another question I have is would it be possible to replace the model of the capture cages with the plushies? I never use them sooooooo.....

Models - sure, you just need to find them in tpp and mgo and make a swap. Not a big deal. Of course they wouldn't work as MGO plushies, their behaviour is coded straight into exe. Theoretically it could be possible to add a trap(trigger) with huge radius around placed plushie and stun/put to sleep enemies if they walk in, but it will work only in missions where you add that trap. Best code example for traps would be "recover volgin body" quest - https://github.com/unknown321/mgsv_lua_ ... q99040.lua.

I cannot work on it yet because I am still occupied by models (and later it will be weapons), sorry.

[Ashtails]

https://m.youtube.com/watch?v=CcicEW4IHLk

I totally forgot about glasses-scarf. Looks like he is applying fv2 files since model is not reloaded. I assume that game crashed because wrong fv2 was applied.

Another question I have is would it be possible to replace the model of the capture cages with the plushies? I never use them sooooooo.....

Models - sure, you just need to find them in tpp and mgo and make a swap. Not a big deal. Of course they wouldn't work as MGO plushies, their behaviour is coded straight into exe. Theoretically it could be possible to add a trap(trigger) with huge radius around placed plushie and stun/put to sleep enemies if they walk in, but it will work only in missions where you add that trap. Best code example for traps would be "recover volgin body" quest - https://github.com/unknown321/mgsv_lua_ ... q99040.lua.

I cannot work on it yet because I am still occupied by models (and later it will be weapons), sorry.

Maybe he was trying to apply the ashes on snakes face, but the game loads a different snake head to do it. And yeah I know replacing the model won't replace the effects but I just wanna do it to take screenshots with it or to give Paz some new toys to play with. Also would it be possible to force the game to let snake use the railgun on d walker without him using code?

[Higus]

Shigu did a video where he put the scarf and goggles on snake through what seems like coding but he said it frequently caused crashes

Shigu here- The answer to how I did that mod is not very exciting. FV2 modded the scarf, then script modded in the gas mask and model swapped it with the goggles before vertex editing it into place.
The scripting for the gas mask wasn't air-tight, I was having trouble with the gas mask permanently hiding itself, conflicts with night vision goggles, disappearing between loadings, and general unexplained crashes.

Modding over the gas mask is still great in concept though, it just needs to be scripted properly. I'm not sure if/how Tex might've done it in IH, but I'm sure he could be capable of writing a stable version of what I tried.

[unknown123]

Shigu here- The answer to how I did that mod is not very exciting. FV2 modded the scarf, then script modded in the gas mask and model swapped it with the goggles before vertex editing it into place.

FV2 modded? Were you applying fv2 files directly like

Code: Select all

Player.ApplyFormVariationWithFile("/Assets/tpp/fova/chara/sna/sna0_main1_v01.fv2")

or via GameObject.SendCommand?

The scripting for the gas mask wasn't air-tight, I was having trouble with the gas mask permanently hiding itself, disappearing between loadings, and general unexplained crashes.

I assume you addded fpk with gas mask to TppMissionList.lua then loaded corresponding mission and called Player.AttachGasMask, right? If I am wrong and you've found a way to dynamically load fpks anywhere, that would be great.

Modding over the gas mask is still great in concept though, it just needs to be scripted properly. I'm not sure if/how Tex might've done it in IH, but I'm sure he could be capable of writing a stable version of what I tried.

The problem is vertex editing model into place. You can attach models/effects into the right places easily by specifying bones and connect points - that's how it is done in mgo. I am pretty sure you have seen that already since you digged a lot of .parts files. If only we knew the right function, that allows us to specify all parameters; Player.AttachGasMask is just a wrapper over it.

[CantStoptheBipBop]

Another lng dictionary update. I haven't been keeping track of the ones I added so no fancy entry counts. There are still some additions I didn't get around to removing in it. I'd prefer not having the "technically correct" ones in it. I'll put it on GitHub eventually.

I also optimized the script I've been using. The changes are mostly just localizing globals and using "for i=1,#table do" loops instead of ipairs/pairs. I've had some luck with using an english dictionary from some site I can't seem to find again, but I'm mostly at the point that I'd need to leave it running for a few hours doing two-word generation and then sift through the crap entries it generates.

edit: messed up something when I pasted the script

edit2: left some old stuff in. Set used words/phrases to variables at top for convenience and so the script didn't waste time generating/concatenating the same strings each iteration.

Code: Select all

local t,tD,math_random,os_time,os_execute,io_open,dL,file={},{},math.random,os.time,os.execute,io.open;file=io_open("newDict.txt");math.randomseed(os_time());math_random()
local __,w1,w2,w3="_","announce_destroy_","",""
for line in file:lines() do
	t[#t+1]=line
end
file=io_open("dictList.txt")
for line in file:lines() do
	tD[#tD+1]=line
end
dL=#tD
os_execute[["type nul>lang_dictionary.txt"]]
os_execute[["for /r %G in (*.lng?) do (LangTool.exe "%G")"]]



local function table_count(argTable,argEntry)
	local count=0
	for i=1,#argTable do
		if argEntry==argTable[i] then
			count=count+1
		end
	end
	return count
end

local function table_unique(t1,t2)
	local t3,indice={},#t2
	for i=1,#t1 do
		indice=indice+1
		t2[indice]=t1[i]
	end
	indice=#t3
	for i=1,#t2 do
		if(table_count(t3,t2[i])==0) then
			indice=indice+1
			t3[indice]=t2[i]
		end
	end
	return t3
end


local function runLangTool()
	local m,indice,file={},0,"tempIdComp.txt"
	--os_execute[["for /r %G in (*.lng?) do (LangTool.exe "%G")"]]
	os_execute[["LangTool.exe tpp_announce_log.eng.lng2"]]
	--os_execute[["LangTool.exe tpp_fob.eng.lng2"]]
	--os_execute[["LangTool.exe tpp_common.eng.lng2"]]
	--os_execute[["LangTool.exe tpp_menu.eng.lng2"]]
	os_execute[["findstr /r "LangId" *.xml>tempIdComp.txt"]]
	file=io_open(file)
	for line in file:lines() do
		indice=indice+1
		m[indice]=line
	end
	for i=1,#m do
		m[i]=(m[i]:match("LangId=.([a-z,A-Z,0-9,_]*)"))
	end
	m=table_unique(m,t)
	return m
end


local function bruteForce()
	local string_char,count,indice,file,tASCII,a,b,c,d,e,f,g,s=string.char,0,0,io_open("lang_dictionary.txt","w"),{"",_}
	for i=97,122 do
		indice=indice+1
		tASCII[indice]=string_char(i)
	end
	for i=1,indice do a=tASCII[i]
		for i=1,indice do b=tASCII[i]
			for i=1,indice do c=tASCII[i]
				for i=1,indice do d=tASCII[i]
					for i=1,indice do e=tASCII[i]
						for i=1,indice do f=tASCII[i]
							for i=1,indice do g=tASCII[i]
								s=w1..a..b..c..d..e..f..g
								file:write(s,"\n")
								count=count+1
								if count==14e5 or s==w1.."zzzzzzz" then 
									count=0
									file:flush(); file:close()
									local m=runLangTool()
									file=io_open("newDict.txt","w")
									for i=1,#m do
										file:write(m[i],"\n")
									end
									file:flush(); file:close()
									file=io_open("newDict.txt")
									t={}
									for line in file:lines() do
										t[#t+1]=line
									end
									if s==w1.."zzzzzzz" then
										os.exit(exit)
									end
									file=io_open("lang_dictionary.txt","w")
								end
							end
						end
					end
				end
			end
		end
	end
end


local function dictionaryAttack()
	local startOfScript,file=os_time(),io_open("lang_dictionary.txt","w")
	while true do
		if os_time()>=startOfScript+1 then file:flush(); file:close(); break end
		local a,b--,c
		a=tD[math_random(dL)]
		b=tD[math_random(dL)]
		--c=tD[math_random(dL)]
		file:write(w1..a..__..b,"\n")
	end
end


while true do
	dictionaryAttack()
	--bruteForce()
	local m=runLangTool()
	local file=io_open("newDict.txt", "w")
	for i=1,#m do
		file:write(m[i],"\n")
	end
	file:flush(); file:close()
	file=io_open("newDict.txt")
	t={}
	for line in file:lines() do
		t[#t+1]=line
	end
end