커뮤니티 Q&A

Audiokinetic의 커뮤니티 Q&A 포럼에 오신 것을 환영합니다. 이 포럼은 Wwise와 Strata 사용자들이 서로 도움을 주는 곳입니다. Audiokinetic의 직접적인 도움을 얻으려면 지원 티켓 페이지를 사용하세요. 버그를 보고하려면 Audiokinetic 런처에서 Bug Report 옵션을 사용하세요. (Q&A 포럼에 제출된 버그 보고는 거절됩니다. 전용 Bug Report 시스템을 사용하면 보고 내용이 담당자에게 정확히 전달되어 문제 해결 가능성이 크게 높아집니다.)<segment 6493>

빠르고 정확한 답변을 얻으려면 질문을 올릴 때 다음 팁을 참고하세요.

  • 구체적인 내용을 적어주세요: 무엇을 하려는지, 혹은 어떤 특정 문제에 부딪혔는지 설명하세요.
  • 핵심 정보를 포함하세요: Wwise와 게임 엔진 버전, 운영체제 등 관련 정보를 함께 제공하세요.
  • 시도한 방법들을 알려주세요: 문제 해결을 위해 이미 어떤 단계를 시도해봤는지 설명해주세요.
  • 객관적인 사실에 초점을 맞추세요: 문제의 기술적 사실을 중심으로 설명하세요. 문제에 집중할수록 다른 사람들이 더 빠르게 해결책을 찾을 수 있습니다.

0 투표
I'm trying to set up Plastic SCM to use exclusive locks for non-mergable file types. It's my understanding that most/all wwise files are not mergable and should be exclusively locked when a developer is working on them.

What are all the wise file types that require exclusive locking? A list of extensions is perfect.
General Discussion Eric C. (100 포인트) 로 부터

1 답변

0 투표
.wproj and .wwu extensions are the only project files aside from the .wav sources which need version control.  All other file types may be recreated by an audio build from Wwise.

.wav files are binary and therefore not mergable in the textual sense.  .wproj and .wwu files are xml and therefore possible to merge in most cases.  It really depends on the user operations that occurred in the change.  Typically a resolve/merge conflict will only arise if two users editing the same workunit perform incompatible changes, for example if user A sets a mix volume on a sound that user B has deleted in their change.  If user A and user B are just adjusting existing settings that don't overlap, their changes may be merged without conflict.

IMO, If you set the .wproj or .wwu files as exclusive check-out, then you are going to create more difficulty for a team using Wwise than you will solve.  Certain regular operations for a few specific files require simultaneous check out and merge or it will prevent other team members from accomplishing tasks while they wait on file locks to clear and then re-sync and reload the Wwise project.

For example, user A and user B both want to create a new workunit in the root of the Actor-Mixer Hierarchy. In order for their workunits to be added, the .wproj file must be checked out and edited by each user.  The change to add a reference to each new workunit in the .wproj file is usually mergable with no conflict.  However if under exclusive lock scenerio after user A has the .wproj file open and locked, user B will not be able to save their work or proceed until User A checks in and User B syncs and reloads the project at which time some of their work may be lost if they didn't get to save yet.

Second example, for the Master-Mixer Hierarchy if both users are attempting to mix or edit effects of different busses in the heirarchy, they will both need to be able to check out the Default Workunit there in order to work independently at the same time, because this is the only workunit that loads into wwise.

For all other workunits  - they exist as a means to split up work so a team can collaborate without getting in each other's way.  Adding more workunits according to the organization of assets in the project helps reduce cases where merges are required from users working simultaneously in the same .wwu files.

Coordination among the team using Wwise is necessary for them to avoid non-mergeable operations to the .wwu files but it is better than being locked out of accomplishing any work.
Jason C. (150 포인트) 로 부터
...