Jump to content

Search the Community

Showing results for tags 'gluon'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • Plastic SCM
    • General
    • Installation and configuration
    • Unity 3D
    • Unreal Engine
    • Plastic SCM on Mac
    • Plastic SCM on Linux
    • Gluon
    • Git interop
    • Integrations
    • Community Edition
    • Branching and merging
    • Announcements
  • Plastic SCM 4.0 Beta (Closed)
  • Plastic Cloud
    • General
    • Configuration
  • SemanticMerge
    • General
    • License
    • SCM's configuration
    • Share your experience!
    • External Parsers
  • GitJungle
  • Method History for Subversion
  • PlasticX Early Adopter Program's General Feedback
  • PlasticX Early Adopter Program's Issue Reporting
  • PlasticX Early Adopter Program's Feature Requests
  • PlasticX Early Adopter Program's Announcements

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start





Website URL







Found 9 results

  1. Hi! I'm new to PlasticSCM and am setting up a new repository on the cloud service. I'm a developer using the PlasticSCM client proper, which is working fine... but when I set up Gluon for our artist, I'm getting weird errors. Several hundred files appear to be locked and checked out to the artist. The Check In option isn't available. And when we try Check Out, there's an error message saying "These items are exclusively checked out by [artist name]." Is there anyway to reset the checkouts on these files? Thanks, Brian
  2. Hello, We would like to know what the proper/ideal workflow would be that would allow the following situations: Developers work with the regular Plastic GUI Our developers are the ones actually working in the main scene in Unity, so they need to know when models are ready. Artists work with Gluon Artists edit the .blend files, but we want to use only the exported .fbx files in Unity (for lower import times since we work with tens of thousands of files). So we have another location on another plastic repo where these source (blend/substance/indesign etc) art files are stored. They edit these, export them as fbx / image files and then check them in the unity project repo. (Its a seperate repo because we reuse many assets in different projects, therefore no cloaked folder outside the unity project) When we have interns or new artists, we want senior modellers to be able to review their work before their .fbx gets updated in the unity project. For example to make sure there is no wrong normals, proper material/texture names, applied locations etc. Since these would mess up prefabs if the corresponding .fbx would be wrongly updated. Ideally we want to use the gluon system of checking out and locking models so everyone in the team knows which files not to touch. And every changeset can be seen by all members of the team. However, as far as i know this does not allow proper reviewing. Meaning if our game-designers/developers would notice an update was made to a file, they might think it's ready to be used. Ofcourse we use a ticket based system, which keeps track whether a model is 'in progress', 'testing' or 'done'. And artists could add the status in a changeset, but it's not ideal that the developers will have to keep checking those to keep track of model status. If we would let the reviewing happen on the art source location, we lose a part of the overview on all the models. Only artists will be able to see the actual status of models, since only artists are part of this repo. And since the model will only be placed on the unity repo once it's finalised, the changesets developers can see in their repo will contain jumps from, for example v1.0 -> v2.0 instead of v1.1 -> v1.2 etc. And if all senior modellers are ill or on holiday, developers cannot easily take over the reviewing as they will need to 'pull' the entire art folder or learn and use Gluon. Which just does not seem ideal. Can we for example let the intern check in the changes while keeping it locked, but manually/automatically transfer this lock to a senior artist, so they could review it first and then release the lock if the review was passed? Meaning a developer would try to use a model and see it's locked, it's not to be used and if it's not locked, it's free to use. How would we set something like this up? Thanks in advance.
  3. Hello! I was hoping someone could help clarify this for me. What exactly is the difference between clicking "Check out" and "Lock and check out"? Looking through the Gluon documentation it says that "By selecting the Checkout option, the files you selected will lock and nobody will be able to edit them until you check them back in." If that's the case then the files you check out are locked anyway. It sounds like the only difference between the two is whether the lock takes place, before or after checking out the files. If so, what are the benefits of doing it one way over the other? Thanks! -Miranda
  4. I recently installed Gluon and created a repository for testing out the software. In doing so I'm running into some issues trying to submit files. The "checkin changes" button doesn't seem to actually push files to the cloud server. Going through the guide I've not been able to make it work either.
  5. Since Gluon defaults to have no files/folders added to your workspace, and seeing as there's probably a reason why someone is adding a workspace (i.e. to get files/folders), why not put you right into the configuration screen? This has stumbled a few people who didn't know why they weren't pulling any files and it's annoying to resolve it remotely since you have to go step-by-step verifying everything they've done.
  6. I made some bad commits, so using Plastic SCM on Workstation "A ", I deleted the changesets and updated my workspace to an earlier point. Working in Unreal Engine, I had to update thousands of binary assets, so I turned off version control... Unfortunately, when I went to SCM to check my files in, Workstation "B" happens to have many of these same assets checked out from one of the deleted changesets in Gluon. Now I can't checkin my changes on "A" because they're locked on "B" and I can't undo my changes and checkin the files on "B" because the changeset is gone. If I try to do an "Undo" in Gluon on the changed files, I get a message that the file can't be downloaded, was "probably" replicated with --nodata and is not in the repository. How can I force Workstation "B" to check in files it can't find in the repository in Gluon? Is there some way that I can abandon the workspace on "B" and re-create it? Thanks in advance! -Donald
  7. Hi, Is there a way to change the repo connection string in Gluon so that if a server moves to a different machine or if we need to rename a repo we can do that without rebuilding the workspace? We need to use different URLs to reach our Plastic server depending on if we're connecting on the local network or over the Internet. This makes it difficult to use Plastic for mobile users. I'm looking for a way to configure the name and address of a repo in Gluon. Thanks! -Donald Newlands
  8. Hiho. We're trying to use a workflow where users should start off with a workspace containing only parts of the repository, but can update to a full copy if they wish. I'm guessing Gluon is exactly the tool for such a scenario? However, we have some usability concerns for our scenario, which is as follows: In our scenario we have a Unity project with many (>=100) 3D models, which usually consist of the model itself (an .fbx file), and several/many texture files for each one. The problem with the textures is, it can take VERY long for Unity to import them after an Update. So the idea is to have a workspace that only shows/contains the .fbx files, to be able to get a quick overview, but if the user wants to he can download the associated textures from the repository into his workspace. However, in Gluon it seems I can "only" load/unload specific directories, not wildcards and/or filetypes or similar. As in our scenario we usually store each model in a separate directory, which has its own subdirectory "tex", containing the associated textures, the user would have to first DESELECT >=100 directories named "tex", located in each model directory. And once he decides he now needs the whole repository, he would again go through the whole hierarchy and SELECT >=100 directories named "tex" (although it seems this step could be simplified by selecting the parent, which hopefully will recursively select all files/directories which are currently unloaded?). This is of course not feasible - and would probably take even longer than just letting Plastic download all textures in the first place, and letting Unity import them... Are we missing something, is there another way/workaround/trick? For example, to use wildcards or relative paths or something like that? EDIT: Hm, we don't really use the Unity-Plastic plugin (although we always connect our projects via the plugin), as the client is so much more powerful than the plugin. But maybe when using Gluon one can use the filter/search field in Unity's "Project" tab to quickly select all "tex" directories for example, and maybe then can Gluon-load/unload these all at once? EDIT2: I just realized, this thread probably belongs in the "Gluon" section... Thanks a lot! Cheers, Wolfram
  9. I was hoping to run plastic and gluon in a mixed environment. Where users would use gluon for day to day needs and then use plastic when extra functionality was needed. But the two applications use different workspace formats. This makes it less seamless to switch between one and the other. Is using a common workspace format something that is in the roadmap?
  • Create New...