#Help understanding how ENV Objects are configured in EVTs
1554 messages Β· Page 2 of 2 (latest)
well it's incorrect then 
yes
struct gfdEnvironmentLight_tag
{
gfdBool active;
gfdLightType type;
gfdRGBAFloat ambient;
gfdRGBAFloat diffuse;
gfdRGBAFloat specular;
gfdLightAttenuation attenuation;
__attribute__((aligned(16))) VmathPoint3 position;
VmathVector3 direction;
};
huh. so I wonder why both templates have got it the wrong way round :/
so i ramped up the values for the fields for the CM section, so if I understand correctly: the red one is AMbient Red, and the green one is diffuse Green
ok so
for characters diffuse color mainly controls rim light
and ambient color tints the whole model
which is the opposite to what the field name shows above, and therefore its the wrong way round in the template (y)
so ambient first, diffuse second, same as everywhere else 
also lol
struct gfdLightAttenuation_tag
{
gfdFloat kC;
gfdFloat kL;
gfdFloat kQ;
gfdFloat dS;
gfdFloat dE;
gfdFloat theta;
gfdFloat phi;
};
so back to the shadow then, they now match ocrrectrly, alhtough I couldn't get the bias to work if that's the case
what values did you try
i dont have the template idk what it is π
maybe you tried editing cascades split ratio
{0.32: 1229, 0.15: 337, 0.001: 316, 0.02: 78, 0.05: 30}
so i limited it to between 0 and 0.32
since that's whats used in the ENV files across the game
might have been better to find a different map
(to simplify, most games actually calculate multiple cast shadows, and blend between them based on distance to camera, so that shadows that are closer to camera are higher resolution/sharper, and ones that are far away are lower resolution)
p5/r uses 3 cascades
(the reason I assumed it's bias is it comes after the path range)
(in the translated UI i mean)
you can try editing it on futaba palace entrance
this area looks so funny without cast shadows
thats with a value of 3
will set it to 0 nw and see
Value of -3
i dont see a difference ther, so no idea what that field is doing π
not bias then!
so epsilon maybe?
I might come back to it :/:
Field 2A0 it quite subtle as well, but only have 2 values (value of 6 and value of 14 - so maybe some kind of flag - most maps havea value of 6)
flags are in the struct
there are also a bunch of booleans coming up that I can see, which also might be flags
also, juust wanted to say thanks @left whale, it's been really helpful thus far.
ofc ofc, np 
@pliant mural and to think this all started off because ryuji couldnt afford shoes π
shadows
Increasing the shadow's far clip distance in any game causes shadows to become lower res. That's because the shadow map is just a texture with a limited resolution, so when it has to cover a larger area, there's less details it can fit.
so this is labelled near clip, so it would be the shadows would be rendered between two clip panes right (near and far)? so by increasing the near clip, that would decrease the range? or have I messed that up
Here is the "near clip" with different values
yeah that looks about right i think
It looks like it walked out of Deviantart (not all fields are released equally, quality wise...)
I don't understand most of this, but it's fascinating to see how much work is put into giving the fields the lights, shadows, etc it has in the end product
this is from the dancing game but yeah
So altering the Field Shadow Darkness level is interesting. Anyone want to take a guess what value I put in to get this
it's -2, which suggest this is more likely to be Field Shadow LIghtness
of the next few flag fields, the first three, Field2AC, 2AD, and 2AE, I can't see nay visible differences
however!
The Flag at Field 2AF (labelled as 2AC[3]) does do something (and I suspected it might, as it was the only one that had a value of True across all the ENVs).
(Look at the wall)
I don't see much of a dif between 1 and 0 π€·ββοΈ
My gut it telling me there is, but it's so subtle it's hard to see
side by side, can you see the fence?
yea
What do you mean? The fence is p clear in both pics
The left is probably a bit darker
If you look at the concrete below it
Itβs sharper,in one
Oooh. Goddamn, this is the toughest game of Spot The Difference I've ever played....
Probably why it looked darker to me
When it's blurred, there'd have to be less of the dark gray, giving off a lighter look
mipmap levels?
could be useful for a performance mod maybe, though the most demanding part is not textures but rendering a lot of geometry
The next few fields are FieldShadowColour, and they work like the other colour fields (thouhgh again the alpha aeppears to do nothing), and negative values are (subtractive?)
Then the colour correction section: labelled differently in each of the templates, but probably more correct in the one using CMY. These again work as you'd expect, although they cap out at -1 and +1 (cyan 10 is the same as cyan 1)
The fields afterwards are labelled dodge and burn. And the values used in the game are from 0 to ~0.6.
However 1.0 seems to be the maximum positive value they can take, after that they break. But weridly, they can go beyond -1 and work fine.
Next up is labelled LightMapR, LightMapG, LightMapB, LightMapA and I cannot see what these values do (if they're even used). All 4 fields have a value of either 0 or 0.2
this is the only reference related to lightmap i saw in the shader
and it's commented out
it's not rgba though
atestref is the clipping point for materials that use alpha clip/cutout mode (easiest example is leaves on trees and bushes)
hmm weird one.
the next few field are labelled outline.
EnableOutline must be set to 1, 0 causes a crash
OutineRange has 8 distinct values across the ENVs (and they vary from 0 to 9000), but I cannot see what they do
crash is probably due to missing shaders
probably
OutlineWidth is the next field and it only has 1 value across every ENV (value of 1.01)
tried changing it but couldn't see any difference
so is that deffo a difference, rather than the movementof the model?
it's for thin character outlines that are added as a post-process effect
its so subtle!
yeah it depends on resolution
if you set resolution scale to 0.5 and then check persona models in your stock, the outlines will be thicc af
ah gotcha
so you can see that they're thicc here
ah let me load the outline width in a low res screen then (y)
there should also be outline brightness somewhere
yes that one is the next field
it's easier to see them if you set it to 0
mostly on the straps
lol phrasing
futaba palace entrance 
so for outline width, you saying set the brightnesss to 0 and ten crank up the width on the futaba palace map?
sure
because of the way these models are set up there's always an outline on characters faces
yep, I can definitely see that
which is good, because initially i was sceptical
giant ryuji for some reason
oh he's on stairs :p
so i set the outline width to 5
is that it on the face?
yeah but i have no clue if it's just how it always looks on lower resolution or if that's because of the edit
there's a difference for sure
actually no joker just wasnt as close to the camera in the previous screenshot
that's 0
yeah no it looks the same width to me
yeah i was gonna say I whacked into PPt and I cant see a difference either
anything in the shader for it (fingers crossed :p)
no!!!!!!!!
we also don't have the source for outline shader
so all i can give is this
oh discord doesnt even embed it lmao
oh god assembly!
jumpscare
this might be useful though, idk
cbuffer GFD_PSCONST_OUTLINE
{
float fadeRange; // Offset: 0 Size: 4
float brightness; // Offset: 4 Size: 4
float projectionZ; // Offset: 8 Size: 4
float projectionW; // Offset: 12 Size: 4
float2 outlineShift; // Offset: 16 Size: 8
}```
and this is what chatgpt spitted out when i asked it to generate a shader based on the assembly
though it doesnt look even remotely similar
great minds lol
For the final 3 fields in this section:
Field27F, Field284, and RefelctionHeight:
- Field27F can be either 0 or 100
- Fied284 can be either 0 or 150
- The two fields are either 0 0, or 100 150
- When the two fields are 0, Reflection Height is also 0
- When the two fields are 100 150, ReflectionHeight ranges from -2000 to 4800
I'm not sure what type of reflection it relates to, the maps for the max value are things like Shido's Palace - Pool Deck so I wondered if the height was because hat has two levels (you go down stairs to get to the pool I think)
planar reflection
these
(extracted from this scene with renderdoc)
but yeah i guess the height is literal height of the reflection plane
whats field id for shido pool
renderdoc is refusing to work π
oh it doesnt even have any reflections here
i cant find the draw call with reflections π
would be easier on a field with real reflections
Try Shidos palace entrance. Thatβs also got a large value
height value doesnt mean anything
Also which joker costume is that?
gekkoukan high
what
that's just the height of the reflection plane
maybe this will help
it is used, just on fields with real reflections
oh wait i just remembered mod menu can force weather
i dont see anything related to height specifically because it's handled by exe i guess (telling the shaders where and what and how to draw)
this is in material i think?
not env
Ah, I hadnβt through about rain, I had wondered if it was for reflective objects like shop windows.
Do you reckon the values before (the 100 and 150) values are flags/switches, or related the actual reflection properties itself?
idk 
So I tried using the RGB values in the CSV sheet by using the hex code to find the HSV numbers. And this is what I got. Please do note, however, that I am a complete noob. I'm positive this can be recreated much better by somebody far more experienced than myself. I lowered the rim light so it wasn't visible in the night time pictures, as I plan to experiment with said rim light using the XYZ coordinates found in the CSV sheet
Filmic
Standard
The hex code of the field's RGB numbers
the hex code of the character's RGB numbers within the field
rim light version coming soon, if I can pull it off...
seeing as the entries say 'unsure'
No coordinates on the park just yet, but here is what Maruki looks like with the XYZ coordinates on the spreadsheet. This is filmic
In standard
EDIT: I totally overlooked the emissive alpha, so that'll be adjusted
so yeah....here we go
Note that the emissive alpha on the character model could be wrong, as @ornate heron was not sure whether the one I took the emissive alpha number from actually belonged to the character emissive alpha.
The 'toonLightColor Alpha' is turned down to 0 as well, but overall it seems that field has an emissive alpha of 0 while the emissive alpha of the character model is still unsure/unconfirmed.
Unfortunately turning down both the emissive alpha and toonLightColor Alpha wiped out the rimlight.
But, as I said at the beginning, i am only a noob. There are likely things I'm getting wrong that aren't obvious to me, due to my inexperience.
https://www.mediafire.com/file/r35nyhju7lnqlsa/lighting+test.zip/file
there are a few in this folder, but 'Inokashira Park (5)' is the final result
what version of MM are you ising (and did you build from src)?
some dusty ass old ps4 version π
i dont even remember
i just manually extracted files from whatever release was latest at the time of pc release and then never updated it
ah fair enough
also yeah the ENV ReflectionHeight values I got working now, with the rain
but those two fields before hand don't seem to affect the reflections as far as I can tell
does the water seciton on the beta tool give any hints?
π
(it's just height and a toggle to display the reflection on the screen for debugging)
cant tell if the distortion changes because of the timing or the value
(distortion values are specified by the material, and I don't think anything from env modifies them)
then its probably just a timing issue with those screenshots - in which case no idea what those fields do (of the major areas in the game, shinjuku has it set to 0, and the fishing pond)
i assume the only reflection related value in env is the reflection plane height
the only thing left now is physics i think
yeah,perhaps the fact those fields seem to be set when reflectionheight is some leftover
well you found everything else from this by now, i think
actually
wtf is dirty
it appears a lot in beta symbols, but i've never seen it in shaders
oh maybe it's some term that's used for something else and not literal dirty effect
well the next section is the physics section
oh yeah it is, nvm https://wiki.c2.com/?DirtyRectangles
this is 
I'm not sure what it affects tbh. I tried changing the value and didn't see anything obvious
do physics testing on ties
joker p2 dlc tie, ryuji phantom thief suit tie
other physics stuff (like hair) is usually stiff af
silly old bear
and that has helped confirm that flag gvalue too
*flag value
is just an enable (which was assumed but good to know)
why ties of all things?!
because they don't have baked physics for those!
joker/violet long coats physics are all just pretty animations
meanwhile small stuff like ties or hair, or p5d dlc scarves uses real time physics
they used the most basic constraint type ever so real time physics look either too simple (just drag, no bouncing or anything) or too stiff
idk how to explain physics things properly, ESL moment
no i get it from your explanation
ok good!!
default values
ζεΉ (Enabled)
ιε (Gravity): -9.80
ζεΉ (Enabled)
εΌ·γ (Strength): -0.050ο½0.150
ε¨ζ (Period): 01.000ο½03.000
ζΉε (Direction)
η©ηγͺγγΈγ§γ―γ葨瀺 (Display physical object) (debug)
second part is wind
From ENVs:
Gravity: 'num_of_unique_values=2', 'min=-9.807', 'max=-9.8'
EnableWind: num_of_unique_values=2', 'min=0', 'max=1'
WindDirectionX: 'num_of_unique_values=2', 'min=-0.346', 'max=1.0',
WindDirectionY: 'num_of_unique_values=2', 'min=0.0', 'max=0.857',
WindDirectionZ: 'num_of_unique_values=2', 'min=-0.381', 'max=0.0',
WindPowerDatums: 'num_of_unique_values=5', 'min=-0.05', 'max=1.75',
WindPowerRange: 'num_of_unique_values=6', 'min=0.2', 'max=1.65',
WindCycleDatums: 'num_of_unique_values=4', 'min=0.0', 'max=3.96',
WindCycleRange: 'num_of_unique_values=3', 'min=0.98', 'max=3.64',
so could be likely that WindPowerDatums is the Strength
and Wind Cycle Datums is the Period
is wind likely to be a global thing, or again more likely to be visible with a model that supports it?
the latter π
particles react to physics as well btw
but it's probably still easier to test with the same models
models themselves have a wind multiplier btw
which, i don't think ever goes above 1 (and is mostly below it)
but setting it to 5 or 10 does make it stronger
hmm so would the P2 outfit work again with the tie? (obviously gravity will be set back to normal never fear)
ta
just a quick follow up to gravity - it's odd when it is set to positive
i'm not sure why the tie goes crazy - i was expecting to be pointing straight up! (no jokes please :p)
erect..
but anyways it's because there's always an additional dummy bone at the end of every physics bone chain that doesnt ever move
(probably because of that anyway)
lol bone
but ah ok, so that dummy bone doesn't have any properties
or rather isnt affected by them so it just causes weirdness
(forogot to mention the you are correct re: the tie working for wind). its quite....amusing :p
yup seems to be
im curious to try out the next two fields (Y and Z) to see how they look
well for Y (everymap is basically 0)
makes sense
the most annoying this is his character model idle pose, never sotps moving!!!
but yes there is "wind" "Y"
bro is restless
you can check with sumi's long hair
you mean mary sue(mi) :p
you'd need to replace joker though i guess
thats easy
actually
i wonder if i still have a model for joker that's just fully real time physics
do you knw what the wind power level was set to
i had to crank it up to see anything
hmmm i guess so
oh multiplier
sorry misread
ignore thast last statement
i was being dumb
0.15 - 0.4
yeah
why does this sync up actually
γQRT of DniweTamp (@dniwetamp):γ
'@megayike π€·ββοΈ'
π 16 π 5
so for the I'm using nowthe windpowerdatums (which i think is the wind strength) I've set to 1.75 just so i can have a strong wind blowing
Directionality for Wind Labels X, Y, and Z
x is the side angle one, y is the hair bounce up and down, and z is the weird left to right one (back facing view)
-ve just stops it all, so <0, the wind stops
but!
if i set the X Y and Z to 1
and set the powerdatum to -1
then it does go in the reverse direction
so they both seem to control the magnitude i guess?
i set it 100 100 for both
and the tie went to the same place
then i set the powr to 0.1 the tie went to the same place, but other parts of the model were less affected
v weird
but yeah
WindPowerRange also seems to be a power modifier. I'm not sure if its a cental point that grows larger (thus making the wind affect more things), but again, the lower the number, the more damping it seems to do (until 0), and vice versa (till about ~1.75)
WindCycleDatum is the time taken for a cycle (I think in seconds). Setting it < 0 wraps to 0 behaviour, but its quite amusing π
So I think WindCycleDatum is for the cycle for the fast part, and WindCycleRange is the cycle time for the slow part.
When i set windcycle range to 10 and WindowCycleDatum to 1, the initial wind effect takes time to start, and is quite slow, but then in the next part of the cycle, its very fast to blow out and return to nromakl, and then the cycle seems to repeat
final section is the sky section - whuch looks pretty small
proper name would be clear color (as in, what color to use when you're rendering a frame but there's no geometry)
you know how in source games if you get out of bounds it gets all trippy and game just doesn't remove stuff from the previous frame
clear color is used to prevent that
yeah, when I go out of bounds i see the colour. I'm assuming the sky dome itself is just a texture that wraps around the map?
yep makes sense
all the sky (colour) fields work as expected, except for the alpha
Sky Alpha
['num_of_values=1990',
'num_of_unique_values=1',
'min=255',
'max=255',
'value_range=0',
'mean=255',
'stdev=0.0',
'cv=0.0',
'mode=255 (1990 items)',
'raw data rounded to 3dp']
like with the other fields labelled alpha doesn't seem to do anything, probably some default field generated from their tooling
and therefore that is the end of the ENV file
i'll go through everything and summarise my findings, and then probably add it to wiki
probably be quite useful to try and line it up with the shader stuff too (baby steps tho)
just to make sure I am 100% not misrepresenting what's been said
the first picture is ambient lighting, and the second if diffuse?
(this is Red set to 1, and G,B set to 0)
i think so yea?
those are two different fields I've edited there
the first pic is from a field labelled field diffuse lighting, but is actually ambient
the second pic is from a field labelled field Ambient Lighting, but is actually diffuse
(so as you said the tempalte needs to swtich the names around)
yes
ambient should be first, diffuse should be second
oh i meant to ask, is there support for actual Field emissive lighting in the game? In every ENV file, all of the emissive light settings are to 0 for R and G and B? I think i remember you showing me the struct and there was no emissive, but I can't remember if I've made that up
h
thanks!
im guessing it's just attenuation
it being all 0s makes sense because it's a directional light therefore there's no attenuation 
is that the distance the light would travel?
for point/spot lights, yes
directional lights don't use it
so if its set to 0 across all the ENVs, what would use it ?
see the gfdLightType there?
yh
ig they wanted to make it possible to use not just directional light
im guessing thats controlled outside the ENVs and some other system handles it?
well idk 
all i know is that they always use just directional lights in env
one for character, one for field
that's it

any additional lights are in fields themselves
ah well, it just confirms my suspicion that most games are held together with plasters and elastic bands haha
yes that is true
the shader technically supports up to 3 light sources at the same time, so if you use the same struct you can add them in any order
though only one directional light is ever used, and they have a separate deferred pass for all point/spot lights and just pass that as a texture
that's how most games did it i think
either full deferred or something similar to this
looking at that tag - do you happen to know if any Attenuation and position values are set? I'm theorising that at least some of the unknown fields in the section might have been used for that (Field42 for attenutation and Field46, Field4A and Field4E) for position - all of these fields in teh ENv are set to 0, for every ENV butif that's potentially linked to LightType stuff (which they might have decided not to do) it would make some kind of sense
they don't matter for directional lights
think of it as a sun in the sky
no matter how far away it is, you'll see it
yep
its always there
so if those fields are set to 0 across the ENV - could they correspond to those fields in the shader - but because this is directional lighting, it owuld have no effect anyway?
shader doesnt have position lol
ah, so whats this attribute in teh struct? attribute_((aligned(16))) VmathPoint3 position;?
(sory for the questions, just trying to understand)
im guessing the game calculates all important info like for any other regular object
in the exe
all shader has is this
you can just match the names in your notes to beta symbols though
then god knows that those field is in the ENV are π
attenuation is an odd one - since that doesn't seem to be labelled in teh template anywhere (same for spot), but could be an unnamed field
it's for light objects in gmds
In the FM section, these are the only unlabelled fields
i didn't observe anything when I changed them either
First section done. Question about the lighting, I'm not sure the labels are correct, because I cant visualise where the light source is in my mind (in order to generat the shadoows),
Dniwe - there's one field in the character model section that has a lot of values across ENVs, but I can't see any effect - was wondering if there was something on the beta screens that might help or any ideas -
It seems to range from ~14.0 to 75 and the majority of ENVs have it set to 50 - any thoughts?
can you give some specific example
with field id
preferably metaverse
though any would work 
you sure it's not from camera? default FOV value is 50
14 is very close wow
the slider resets back to 50 after you let go btw π
It's just labelled on teh template as Field188, but its around the character model light X Y Z labels, and just before the near and far clip settings
futaba palace entrace ok?
so field 155_001 has a value of 60
------ Field188 ------
['num_of_values=1990',
'num_of_unique_values=69',
'min=14.0',
'max=75.0',
'value_range=61.0',
'mean=50.546',
'stdev=7.198',
'cv=14.24',
'mode=50.0 (908 items)',
'raw data rounded to 3dp']
on this field slider resets back to 60 
saywut!?
im not seeing any difference when changing it
which I noted before actually checking my notes
f153_008 is another map with a low value (value of 35)
I wonder if its something baked in the field somewhere?
(or handled by the exe)
it could also just be broken in multiplatform version π
like texture filtering always being set to linear (on ps3 you could set it to nearest in material, useful for minecraft imports)
guess it's different in royal
Iβll label the field in my notes but with a note that not seeing any effect. Might check the maruki palace map see if they are set to something
Maruki maps all set to 60 - so it is what it is
Updated to Character Model Section. When double checking things, i did note that the near clip plane seems to have some kind of minimum distance, since even when setting it to 10 or 20, things were rendering behind the camera. Although I will say, i do wonder what "units" are being used#
hmm metres would make sense

In the fog section, is there a) a flag/switch to set fog on off/visible/invisible, and then an alpha channel or opacity channel?
Field195 (which comes after the enable flag) seems to have some secondary control behaviour on Fog
interesting - what are the option types where it says Linear? (and i tried to translate that first checkbox but it didn't make any sense to me)
hmmmmmm
so from the looks of it, the Disable Fog is actually the use near and far plane toggle there
which makes me wonder if Field195 and 196 are the implementations of the fog type
(and Field195 ignores/not affected by Field196) - maybe?
oh ffs the descritions didnt save! pic 1 is Fog on, Field195 off, Field196off, pic 2 is Field195On, Pic 3 is Field196On
Can someone explain (in simple terms) what a ToneMap is and what Bloom is? The field is labelled differently depending on the template - but I'm not sure I understand what is happening when it's enabled
tonemap = when image go bright, make image not bright
bloom = when some parts of image are bright (above threshold), make those parts bleed around the edges
so in these two images, when its 0 that weird effect around the light sources, and when its 1, you don't
so reading your definition, would that be bloom?
since when its disabled, the light is bright, and whens its enabled, the bloom effect applies?
(sorry realised it was a crappy picture)
(left is disabled, right is enabled)
yeah there are three fields linked together:
Enable HDR OR Enable Graphical Output
Enable ToneMap OR Enable Bloom
Enable StarFilter OR Enable Glare
in the screenshot - i've got HDR/GO set to 1, StarFilter/Glare set to 1 and ToneMap/Bloom set to 0
just writing up the outline section - i'm wondering if the outline fields are outline transparency/opacity/darknesss and outlineWidth - i know we discussed it before with the width (and I think that one is correct), but we kind of glossed over the former
Because outlinerange is an odd name for a field
The outline on the chars as the value increases - looks the same thickness of the sleeve all along, but changes colour from white to black
The more i play with and write up what I find, the more I learn about video game environments, the crazier and cleverer and complex the whole thing seems π
Dwine - on the beta menu for DOF - are the plane settings defined/independent of each other? Just realised in the ENV both the near and far planes are the same value
yeah - its odd. they've set every near plane and far plane to the same value
this is true default values btw
didnt load any field or env
opened the menu on boot screen that shows up before even title
interesting
i can check some specific field
would you be able to see what the values are on shujin gates morning?
id..
f2002_001
full env id...
lol
in royal - its set to 99.6666663, 100 100, 71.64, 0.89, 1
which i dont undetstand as a concept, since that would mean the FocalPlane, and the blurplanes are both 100
the blur limit is 70
and the blur strength is 0.89
i cant even edit the values to make just the distant objects blurry
gaussian mode 1
it's either full screen or nothing
i assume you ticked the box?
what's the setting on that latest picture?
interesting
yep dont get anything like that in Royal - must have made some major changes
im just gonna see what the settings are for the new fields
like kichijoji
yeah looks defaulted
100 100 100 across the board
Finished putting into a doc - its pretty large due to all the images. I'm not sure the terminology used but hopefully its clear what I mean in places!
hope it makes sense!
I've also been working on a little parser for the ENV files that will spit out either a json or a csv - ive done the csv part for the moment, and will get a json done in a while.
https://github.com/bladekey88/simple-P5R-ENV-Parser/releases
i'll also stick this up on wiki, though I doubt i'll be able to include teh images since they're numercvous and large, and probably overkill anyway
that's ambient

same for characters
swap ambient and diffuse
did you send an old pdf
color correct is still rgb instead of cmy too
oh wait no i was looking in the wrong section
anyways i told you, ambient first, diffuse second, always, everywhere
no, that's the most recent version
those are the names in the template - ive added my comment there, but i dont own that template
(as in the ENV template)
hence my comment in bold
no need to come in swinging so hard
But thinking about it I might swap it round in the summary and note that the templates are the wrong way round, so that the summary is correct and ambient comes first
Created a json output for ENV (with the corrected field names for Ambient and Diffuse)
its a WIP but i'm using the children field to nest structs, and then the field field for the actual field values. For some fields, I've converted the value to RGB as well.
https://amicitia.miraheze.org/wiki/Persona_5_Royal/ENV/Structure
I've also stated to add it to wiki so thats its available and easily editable - i've updated the field names to be what I think they should be
I've completely updated that page and I think for now that's everything done. On the /ENV page I've also put the research on how the ENV iteration works for in-game and for event envs. I'm going to update the PDF, and probably stick it on a google drive somewhere and link it when its done.
I was going to upload the pictures to Imgur, to illustrate the fields on the wiki page, but it wants my phone number when I make an account so I wont be doing that!
Separately, I'm thinking I'll write some code to deserialise the output json I created so that it can be converted back to an ENV file making it easy to edit without using 010 editor/templates
Not sure what/where the best place is to go update the templates, I assume a pull request somewhere?
thanks
done
just the pdf to update, and then i'll post it here, and close this. I'll open a new topic for the json deserialisation
Really good work on this! It's amazing to have someone around who both can and actually WANTS to document in detail 
π thanks. i love persona 5, i love technology, and i like learning new things
Updated, including changing the field names to what I had initially suggested - being bold! The wiki page is also updated with this.
Also added some info for the footer and the two missing fields before the CM and FM section
I think I've also fixed the json so that it adds teh missing fields that aren't in the original template (includes the footer). The only issue with it now is there is no key at the root level, so the json structure techically is two objects at the root level, but apparently that is valid json
(marked as solved)

i think it's probably better to leave this open for a little bit still
just in case
That sounds ominous 