As the UnrealEd's menu says: build is needed for changes at brushes, light and paths - paths depend on NavigationPoints and Inventory items. I'm not sure if changing TriggerLight's properties need rebuild, too.But changing code or properties that are read at run time, take effect without a rebuild. Otherwise patching a map while it is loaded wouldn't be possible.

"Multiple exclamation marks," he went on, shaking his head, "are a sure sign of a diseased mind." --Terry Pratchett

Partial agree, when you do a small change to a light, you don't need to touch paths and brushes, why to screw up other "build" if you need that small light change ? Else inventories added post-pathing build are never hurt, this will prevent a crap-ton of paths added and borks created in such spots. You have an ammo initially placed in location and then post-pathing you can add more ammo preventing other InventorySpot actors added and causing pain when are too many and too close each-other WITHOUT to rebuild paths, unless you delete some Nav'Point. If replacements in mods are like in year 2000 that's another story as long as they are having only 2 options: marked or held - nothing is held when comes out of a Decoration and neither marked - lousy coding and without to copy more data needed from replaced item.As evidence is that I can attack some lights in run-time without to screw A.I. or brushes proving that light is "toucheable" with Scripting and won't hurt. I don't recall in how many maps I tweaked lights in run-time but I recall one: MH-2MuchHP - way too bright in battle arena and a lot of dark in last room when I spawned a custom light in run-time (only in client).

Edit:Perhaps I will have some inspiration in making a sort of map with an INI file where can be configured lightning here and there, and then I'll be curious how many people will complain about lightning because last time I saw an obsession for lights. You don't like lights ? Good, do your setup then: color, radius, brightness, etc. But before to do something I'll look into replication for these actors... Anyone can try this if wants something different.

Barbie wrote:As the UnrealEd's menu says: build is needed for changes at brushes, light and paths - paths depend on NavigationPoints and Inventory items. I'm not sure if changing TriggerLight's properties need rebuild, too.But changing code or properties that are read at run time, take effect without a rebuild. Otherwise patching a map while it is loaded wouldn't be possible.

Wish I knew or thought to ask years ago, I hit rebuild at every tiny thing

It's actually a good habit to have. Countless times I've moved a brush I had highlighted and wasn't aware and the rebuild showed the changes. If you catch it that fast you can easily fix it but small misalignments that you don't catch can compound over time.

"You damn kids, back in my time we made the items, maps and games ourselves with an unwieldy engine using counter-intuitive crash-prone tools and we liked it so much we built communities around this which nowadays look like cults because they're quasi-parallel societies based on the same old games." -Hellkeeper

Yes, this is a good thing to know!I figured this out years ago when I merely needed to do some changes to a few actors and creatures in some of my maps.With those edits you merely have to do Saves to the map. No rebuilding anything.Also, if you are only changing lighting or pathing, you can just do lighting rebuild or rebuild paths, as what may be the case.This has also worked well in maps where the brushes have been obfuscated. (or deleted)

I just want to point out that when you add a light, you should rebuild the BSP before rebuilding the lighting, otherwise meshes generally won't be affected by the newly added light, so they will remain completely dark in the area you added the new light on.

I don't know why is this, but there's probably a reset needed for meshes on the overall BSP and lighting that only a BSP rebuild provides for meshes to be lit up by the new lights.