I’m going to bump this up because this is sorely needed for all of us not using Perforce version control (we’re on Subversion and OFPA naming is killing us).
Sorry to steer the question in another direction, I’m actually wondering how you handle those world partitionning file in perforce ? As far as i can see, they have to be read/write for unreal to save correctly, but doing so p4 doesnt see them as modified.
How do you keep the file read/write while checking them out in perforce? Other than checkouting the whole folder ? have you written a script of some kind ? I’ve tried different typemap without sucess.
That is a lockable designation. It means it’s read/write but also will be locked when modified in editor (when Source Control is connected) or when checked-out manually in P4V.
Since External Actors are just uassets, they can (and should) be treated by P4 the same as any other uasset you’re working with in your project.
Massive bump. I’m going insane trying to understand what happens in the level changes. Are there any programs or plugins e.g. for tortoise git that decipher these IDs into readable actor names??
If you rename a file in the outliner the OFPA name remains the same and the file is marked as “modified” in source control, that’s probably why they are not including it in the file name…
The file name is preserved even if you use the replace function and change the actor class completely, so you can’t even use the class default name as a name:
It works, it’s not very handy but at least it allows me to understand what the hell has been modified in a very slow way.
Remember that when we only had levels we were only able to see that the entire .umap file was modified and not which actor .
Also, if you enable “Revision control” in the outliner tabs, you should be able to easily identify which files have been modified (marked in green or yellow):
HI
do you know if those Package Short Name codes can generate duplicate names on two different PCs?
I’m using Unity Version Control (Plastic SCM) as my source control, and when we merged, we had a bunch of duplicate folder names. when we resolved the conflicts by adding _dst to the end, the actors still showed up in the level, but i’m worried that the names might duplicate, and we won’t be able to rename them to merge.
I’m sorry but I have no idea about how those parent folders work, I find them very confusing too! (Actors seems to appear anyway if you move them into different folders of the same level, so I really don’t know what they are named after)
I think that there should be a “uniqueness check” when an actor is created (and even if there wasn’t, the string is so long that it’s pretty hard to get the same value with a random generation)
Thanks for the reply.
i think we’re going to move to sub levels instead of worrying about the chances of it breaking. we’re a small team anyway but just thought that OFPA and world patrician would of been good to use.
Imagine if your regular source control told you there were 15 conflicting files, but the tool didn’t tell you the names of the files that changed (OFPA nonsense names), not without manually having to look them up one by one in a spreadsheet (outliner).
This source control tool also won’t tell you what actually changed in those files (binary uassets) without booting up an application that consumes 24 gigabytes of RAM. This application can take multiple minutes to become responsive, depending on which file (level) you had open last time you opened it, and will semi regularly crash while booting. You opened this application to perform a source control operation, but if you have this very application open when performing source control tasks externally, the source control tasks will fail because this application may be using the files. So you have to close the application that can take minutes to load in between each source control operation. Not to mention the simple act of having the application open can inadvertently mutate files.
Or perhaps you just YOLO it and clobber a day’s worth of work for someone else, who will be accidentally clobbering your day of work in a few hours.
And then you have to go through this process multiple times a day, every day because you’re madly in love with this dumpster fire.
This is what it’s like using source control with unreal engine.
When connecting the source control provider via plugin, you should be able to see the actor names resolved using the “Submit Content” button. I just tested this with UE 5.6 and the Git beta plugin.
If you’re using an external client and Git: As far as I know, Anchorpoint is currently the only one that supports showing actor names in this way (disclaimer: I’m one of the developers). It’s specifically optimized for Unreal Engine workflows.
I have never heard of anchorpoint but my interest is piqued. This is the first time I have experienced hope in a long time.
I had a quick look and couldn’t find any screenshots of how anchorpoint displays this information without unreal being open.
Can you provide some? Specifically I want to see how it works for the utter nonsense that occurs in __ExternalActors__ with OFPA.
Revision control is permanently in the disabled state in all my projects; it can’t be trusted to not do crazy things by default, like commit every time you change something in a shared collection, it slows down certain operations, and is responsible for crashes at times. Plus I don’t want to have unreal open in order to do revision control, I don’t trust it.
Can you confirm that this is definitely stuff in __ExternalActors__ ?? I don’t see the directory name in that screenshot. If you can confirm this then switching our team to Anchorpoint is a near certainty.
yes, 100%
The UI groups the external actors by map path instead of the real path, so the user will see Content/.../Isometric-Interiors/Maps/Map_1 instead of Content/__ExternalActors__/Isometric-Interiors/Maps/Map_1/0/7W
We have the whole company trying out Anchor point this week. While it’s got some minor UX nuisances, overall the system is an improvement! Thank you for making me aware of it.