MF
"All true. Then again, you can reverse engineer pretty much anything with modern tools."
I apologize if i'm misreading your point.
You can forward engineer anything with modern tools too. If you have years and years.
Question is the difference of difficulty when it comes to RE for whole of the project. Because reality check, we'd derive every game's source much quicker (seconds) as opposed to (years and years) if everything was managed code. Before il2cpp this is what using Unity meant. Code obfuscators are a joke, unless you know how to custom-build one. Remember its seconds and some junior programmer could begin passing off their frankenstein as yours thanks to a .NET reflector.
It's about inflicting cost upon the would be reverse engineer, their time and/or their money. Let me be clear i'm not saying you can't get lucky and decode this or that class structure in a day. It's about protecting *YOUR* source code not some shadow of it the compiler produces. Nor is it about some delusion that anyone with a hex editor and some RE knowledge could'nt reverse any part of the game.
"You can use git difs or something like the Steam API to partially patch. It's not very elegant, but it works."
My point is partial patching as you say, isn't built-in and is UNDOABLE by any clever invocation of Unity API or C#.NET API. (note: yes i’m aware of run reflection, it doesn’t scale as patching mechanism if you have many classes)
The UnityScene cannot be ignored, and so if an update happens and a script is now attached to this as opposed to that, your partial patching options are nill.
I'd file this under worth knowing. There is no built-in way to partially patch the scene. I'm sure there's some unity script bundle from its store that addresses this, I don't care. That's some i got too much time on my hands to figure out
unity's own scene representation format bullshit.
"I think you've been using the editor objects wrong if that's an issue."
Unity GUIDs are not static, they're just relatively unique to every other ID.
Even if a GUID appears static in some context that's likely the hashing of an asset (maybe among other things), so when the asset changes, you've lost a reliable upgrade path. When Object/Asset X changes, so does its ID after that point. Thus you can't do a reliable save game upgrade.
You need a reliable way of identifying game-objects at the very least, but even if you do that how
can you be certain of initialization order if starting pool of game-objects (determined by the editor) change?
Fact is you need the editor itself to keep static id assignments to have any certainty at all.
"Not sure what you're getting at here. A GameObjects position fields are Vector3 types."
Preferring to use GameObjects to store info about position data, means you drag and drop a marker once.
This is superior to updating the coords fields directly, because with the gameobj the coords update automatically when you move the marker (the game object).
"Layers are not for finding stuff in the editor, layers are for bitmasking raycasts and camera culling."
Wrong you can arbitrarily set the layers in the editor. You can create custom layers too.
A game-object layer info is available for edit and viewing in editor mode but also when running the game via script access.
It does serve as a way to further classify what a game-object is. And yes raycast can be sensitive to specific layers.
You can use knowledge of what layer something is on to organize how your scene breaksdown. You might create a layer
that is labeled "Offscreen". There could be game objects that are on this layer, but also tagged GameEntity.
By tagged I don't mean named, I mean the tags it has. There may be many GameEntities, some named bob or sally, but all tagged “GameEntity”.
Anyway when you do a raycast, you may wish to detect GameEntities but only on certain layers.
But you can also use layer info when doing game object finds. Suppose you create a giant list of all GameObjects tagged GameEntity. Ok but what if you want just those that are on a certain layer? Well camera culling and raycasting are irrelevant computations to knowing that. Just read the layer property and sort.
"You can easily manage your seats and add a new machine in the portal. Has been the case since at least 2016."
In my case it was the dev machine itself that changed. How can you add a "seat" for a machine Unity doesn't know exists until you repair/assemble it?
Telling a portal anything sounds just as annoying as regrabbing the license itself. How about not revoking our damn license in the first place?
In regard to the OP, I am reminded of few other important facts.
1) GameObjects in unity if disabled, can no longer be found. You have to keep your own reference or it's lost forever. LOL.
2) GameObject find commands are slow. The most important class of all has a soft spot on being located in memory. LOL.
3) Certain properties like position/scale/rotation “lie” if a game object is a child of another, and there's no display of their true absolute values in the editor. This means you're in for quite a ride if you write a script not accounting for the object's parent(s).