# Installing a custom Vinewood sign

> Unzip, ensure, restart the server, and the two things that leave a custom Vinewood sign invisible if you skip them. A full install walkthrough.

Source: https://fam-tools.com/guides/install-a-custom-vinewood-sign · FAM Tools · published 2026-10-12 · updated 2026-10-12 · about 7 min

**Short answer.** Drop the folder into resources, add one ensure line to server.cfg, and restart the whole server rather than the single resource. The sign is streamed map data, so a resource restart leaves the old archetypes loaded and nothing appears to change.

## Key points

- The resource is pure map data: a stream folder, a manifest and no Lua at all.
- Restart the server, not the resource — type definitions are read at server start.
- A missing _manifest.ymf is the usual reason a sign places but never draws.
- If you have loaded a broken build once, clear the client cache before judging the next one.

A custom Vinewood sign is an ordinary FiveM map resource: a folder with a stream directory, a manifest and nothing else. There is no script to configure and no dependency to install, which means the whole job is three steps — and the two ways it can go wrong are both worth knowing before you start.

## What is in the folder

Open the archive and you will find a single resource folder. Inside it is a stream directory holding the drawables, the texture dictionary, the clip dictionary that drives the animation, the type definitions and the placement, plus an fxmanifest.lua and a short readme with the build id.

There is deliberately nothing else. No config file to edit, no Lua to require, no framework to match. Every choice you made in the editor is already baked into the files.

```text
pityus_vinewoodsign/
├─ fxmanifest.lua
├─ readme.txt              <- your build id, keep it
└─ stream/
   ├─ *.ydr                <- the letters or logo pieces, and the frame
   ├─ *.ytd                <- the colour strip the animation scrolls across
   ├─ *.ycd                <- clip dictionary: the animation itself
   ├─ *.ytyp               <- archetype definitions
   ├─ *.ymap               <- where each piece stands on the hill
   └─ _manifest.ymf        <- tells the game the ymap depends on the ytyp
```

## The three steps

1. **Unzip it into resources** — Copy the folder into your server's resources directory, keeping the folder name it came with. The name was generated for your build and it is referenced from inside the manifest; renaming the folder is the one edit that breaks it.
2. **Add one line to server.cfg** — Add an ensure line for the resource. Put it anywhere after your other streamed assets.

```lua
ensure pityus_vinewoodsign
```

3. **Restart the whole server** — Stop the server and start it again. Not "restart pityus_vinewoodsign" from the console — the full process. Archetype definitions and map data are collected when the server starts, and a resource restart leaves the previous set in memory.

> **txAdmin users** — The "Restart" button in txAdmin's server panel does the right thing. The "restart resource" action in the resource list does not — that is the one that makes people think the install failed.

## Why a custom sign sometimes does not appear

Two reasons cover nearly every report. The first is a missing manifest: the _manifest.ymf file tells the game that the placement depends on a particular type definition. Without it the entities are in the world but the game has no archetypes to draw them with, so you get the support frames and no letters, or an empty hillside. Every package we build ships one, so if you edited the folder by hand, this is the file to check.

The second is the client cache. If a player has already downloaded a broken earlier version, their cache still holds it. Because each build uses freshly generated file names, a rebuild normally downloads clean — but if you are iterating on the same build id, clear the FiveM cache before deciding the new one is broken.

| What you see | Almost always means |
| --- | --- |
| Nothing at all on the ridge | The resource is not ensured, or the server was not fully restarted |
| Support frames but no letters | Missing or mismatched _manifest.ymf |
| Letters, but flat grey | The texture dictionary did not load — check for a name collision with another resource |
| Letters, lit, but static | The clip dictionary did not load; send us the build id |
| The old sign is still there | An older build of the same sign is still ensured, or the client cache is stale |

## Does it clash with the stock Vinewood sign?

No. The stock sign is a separate set of props placed by the base game; your sign is placed on its own, at the position you chose in the editor. If you want the original gone, that is a map edit of its own — the usual approach is a small ymap that removes the base entities, which is covered in the guide on removing map props.

If you kept the default position, the two can overlap visually from some angles. Nudging your sign forwards or along the ridge in the editor is the quickest fix, and it costs nothing to rebuild if you still have the design open.

## Checking it worked

Fly to the Vinewood hillside after dark. You should see the letters lit and running the loop you chose in the editor. Daylight is a poor test: the emissive treatment is subtle in full sun, exactly as the stock sign is.

Look at it from a distance too. The sign is built with a long draw distance on purpose — being readable from across the map is the point of putting it on a hill — so if it pops in only when you are close, something in your own graphics settings or an entity-distance script is clamping it.

> **Keep the readme** — The readme in the folder holds the build id. It is the fastest way for us to look up exactly which assets you were sent if you ever need support on it.

## Questions

### Do I need a script or a framework for a custom Vinewood sign?

No. The sign is pure map data — drawables, a texture dictionary, a clip dictionary and a placement. It works the same on ESX, QBCore, a standalone server or an empty one.

### Can I rename the resource folder?

Not after the build. The folder name is generated for your build and referenced from inside the package. If you want a particular name, set it in the editor before you export.

### Why do I have to restart the whole server?

Archetype definitions and map data are gathered when the server starts. Restarting a single resource re-reads its scripts, not the world data, so the game keeps using what it already had.

### Will players need to download anything?

Yes, once — a few hundred kilobytes, the same as any small streamed asset. After that it is cached.

## Related

- https://fam-tools.com/guides/ymap-vs-script-signs
- https://fam-tools.com/guides/fivem-streaming-assets
- https://fam-tools.com/guides/fivem-ymap-guide
- https://fam-tools.com/guides/fivem-clear-cache
- https://fam-tools.com/guides/brand-your-server-map