> For the complete documentation index, see [llms.txt](https://wiki.thescriptersguild.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://wiki.thescriptersguild.com/knowledge/ugc/guides-and-info/handling-level-files.md).

# Handling Level Files

While it may not always be reasonable to adhere to all of these, the more that you do, the safer your project is from file corruption issues.

### Axioms

* Have a file with everything you need on it to test the technical aspects of the project, including minimum spawn requirements, this is your build file.
  * This is also what would become a template for building more levels for the same mode, etc, when you are complete.
* Have a separate geometry build file for the actual level(s) you are going to install the project on.
* Never put scripts on your geometry build file(s).
  * If you intend to add scripted environment elements, I would do that on a copy of the geo file so you always have a geo file that has never had scripts placed in any version.
* Save a copy of your geometry file for testing in actual gameplay and put scripts on that by pasting in prefabs, this is your test file.
  * When you can, avoid making changes directly on the test file unless they would be easy to mirror back to the build and geo files.
  * Mirror any updates made on the test file on the build and geo files.

This ensures you can't end up with a corrupt file from scripts on your geo that you can't recover from and it's easier to deal with ghost scripts if you don't have to jump back a bunch of versions while you're testing. You just copy the scripts to a prefab and paste it on a copy of the template file. Once you know the script works at all on the most resource intensive target level, or at least on something as budget heavy as Argyle, I'd say you are safe to hand it off to the public to install on their own stuff.

You can roll back to get out of holes, but it isn't as fast as just copying to a clean build file and some holes aren't gonna get filled no matter what if the file corrupts or you have an ownership break, etc.\
\
\# Contributors\
Captain Punch


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://wiki.thescriptersguild.com/knowledge/ugc/guides-and-info/handling-level-files.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.