New lighting for old maps

So i've recently started my journey into 'customization' and boy has that cut into my actual TF2 playtime. I'm the no. 1 fan of pyrovision, though somewhat disappointed that i've only realised you could enable it on all maps just now. Ive also replaced sky_goldrush_1, sky_hydro_1 and sky_trainyard_01 with the frag-friendly sky_harvest_night_01. So yeah, pyrovision and a purple hazy skybox, what else could anyone ask for right ?

That's where my question comes in, i believe the lighting is attributed to the .bsp files in teamfortress2/tf/maps/ and has nothing to do with the materials/skybox/ vmt's and vtf's.

With 0 experience in hammer, I've tried going into properties of 'entities' > 'light_environment' of a decompiled map but my nerdgasm was cut short 2 minutes in because two out of the 4 Hammer windows just displays a purple and black square texture. I have no idea what i did or am doing in hammer right now. I hope you bear with my noobness, sorry here's TLDR

1.) Is the Koth_Harvest_Event_01 map lighting different compared to say goldrush,badwater and degrootkeep lighting if you've only added vmt's and vtf's to your custom/yadayada/materials/skybox/ folder ? I see a dark tint on harvest event.

2.) How do i go about getting that tint on goldrush/badwater and degrootkeep short of opening the maps in hammer and editing it ?

Lightmap data (every surface of every part of the level has a lightmap associated with it, which is what controls lighting in Source Engine) is compiled at the same time as the map, meaning it can't really be changed aside from:

1) hacking into the lightmap lump of the bsp and mass editing it (good luck with that)

2) decompiling, editing in hammer, recompiling

Both of these will also cause a mismatch map error (Map differs from server's version), so I wouldn't recommend them. Your next best bet would be some sort of color correction, but I'm not 100% sure how to go about it. This might be a good spot to start researching.

Should be noted that decompiling and recompiling is far more annoying than it seems, since you will have to go through and redo the optimization. When a map is decompiled, the hint brushes and stuff get cut along the vis leaves, if I remember correctly. So that needs to be redone. Area portals might get messed up and then those will have to be redone. So it becomes a huge under-going if you plan to rebuild/recompile maps.

The error happens even on sv_pure 0 servers. The engine enforces this in order to ensure synchronization capabilities. A different brush could drastically change the result of a player action. It's infeasible to attempt to find a rule for what changes are safe, so they are all considered sync unsafe.

The only guy who cares about the difference between a material and a texture.

I suspect that if you just wanted to make a new version of an existing map that just changes the lighting, you could do it without resorting to decompiling or editing the lightmaps by hand. Compiling a map involves three steps, each performed by a different program: Creating a BSP file, calculating the visibility and adding that data to it, and adding the lighting. I do not know if VRAD gets its light-entity data from the BSP file itself or if it has to load up the VMF to get it, but I suppose in theory you could decompile the map, edit the light_environment, and then (with the original BSP file copied to the /mapsrc/ folder) run just VRAD by itself to make it burn new lighting into the already-compiled map.