Skip to content

Getting help

Something is not working. This page says where to report it and what to provide so that someone can answer you with something other than "which version?".

Where to go

Your situation The right place
The build printed a message and you do not know what to do about it Build messages
A question, a doubt, "is this normal?" VEAF Discord, #support channel
Something does not work as advertised a GitHub issue
An idea, a missing feature a GitHub issue, "feature request" form
A security vulnerability no public issue — see below

Discord is fastest for a question; an issue is the only place a defect does not get lost. When in doubt, ask on Discord: someone will tell you whether it is worth an issue.

The documentation assistant

The button at the bottom right of these pages opens an assistant that answers from the documentation. It runs on a free allowance, shared by every visitor of the site: on a busy day it can run out. The assistant will say so when that happens, and say when it comes back — the allowance refills the next morning.

Nothing is broken, and nothing is lost in the meantime: the documentation is still there, and so are Discord and the issues. The veaf-tools ask command talks to the same assistant, hence to the same allowance.

It also answers what you did not ask. A question almost always arrives wrapped in the approach you already chose — "how do I write this bit of Lua better?" — and there is sometimes a simpler route, written down in the documentation, that makes that bit of Lua unnecessary. When there is, the assistant says so first and shows it, then still answers the question as you asked it. It only does this when the documentation says so: a setting it describes as reachable only by the long route keeps that route.

Asking the bot: /ask

On the VEAF Discord, /ask answers questions about the documentation.

/ask question: how do I add a radio preset to a mission?

The bot opens a public thread under your question and writes its answer there as it comes, with links to the pages it used.

The thread is public on purpose: the answer serves the next person who asks the same thing, and anyone passing by can correct the bot — "no, since 6.19 it works differently". On a documentation assistant, that is the only correction that actually catches a wrong answer.

Asking a follow-up

One answer usually raises the next question. In the thread, mention the bot and ask it:

@VEAF Tools Bot and if I want to build a mission? are there templates?

It answers with what came before in mind, so the question can be as elliptical as that one — no need to restate the subject.

Three things to know:

  • it only reads the messages that mention it. The rest of the conversation in the thread never reaches it — not out of politeness: Discord does not hand it the text of messages it is not named in;
  • it only works in the threads it opened for an /ask. Mentioning it anywhere else does nothing;
  • each follow-up counts as one question against the quotas, exactly like an /ask.

Turning the thread into an issue

An /ask thread is often where you find out something is missing: an unclear page, an example that does not work, a feature that does not exist. To turn it into an issue without retyping it, mention the bot with a single word:

@VEAF Tools Bot bug
@VEAF Tools Bot suggest

The bot answers with a button that opens the /bug or /suggest form, already filled with the thread: your questions and its answers, the most recent first when they do not all fit. What is left to write is what you expected and how to reproduce it, for a bug, or the solution you propose, for a suggestion. You then see the draft of the issue, and nothing is published until you confirm it; dropping it is a normal outcome.

The word has to stand alone after the mention: "@VEAF Tools Bot bug in CTLD?" is still a question, and it answers it. This does not count against the quotas, since it asks the assistant nothing. For this the bot only reads what it already remembers of the thread: the messages that mention it and its own answers, not the rest of the conversation.

What to know before relying on it

  • It answers from the documentation, and from nothing else. It does not read the code, does not look at your mission, does not open your log. If the documentation does not cover the subject it says so and points you back at this page — that is an answer, not a failure.
  • It can be wrong, or a version behind. Check the pages it cites; that is why it cites them. If the answer is wrong, say so in the thread: the people around will read it.
  • A documentation gap becomes a wrong or missing answer. The fix is to write the page, not to tune the bot. So a question it cannot answer is useful: report it, it is worth a documentation ticket.
  • There are quotas. A few questions per minute per person, a daily limit, and a limit for the whole server — they protect the free allowance the website and the command line also share. When it refuses, it tells you why and when it resets.

What it does not do

It does not read the sources and does not look at your mission. If its answer does not solve your problem, though, the Report a bug button under the answer opens the /bug form with the thread already in it. The button goes away after an hour; after that, mention the bot with bug or suggest (see Turning the thread into an issue).

The same thing outside Discord

.\veaf-tools.exe ask asks the same assistant the same questions, from your own machine. See the CLI Reference.

Reporting a bug from Discord: /bug

On the VEAF Discord, /bug opens a form: what happened, what you expected, the steps, and the veaf-tools doctor block. You can attach a log, a mission, a configuration file.

The form, like the command descriptions, is shown in your Discord client's language — French or English. The bot then answers you in that same language, and the issue is written in it.

You do not need a GitHub account. The issue is opened by a bot, on your behalf: your Discord name is credited as the reporter, and nothing else about you.

What the bot makes of your form

Everything below happens without any AI — these are reads and searches, so they are exact, and they work when nothing else does:

  • it reads the doctor block for the tool version, the DCS version, the operating system;
  • if your text or your log contains an error, it extracts the file and the line, then reads the surrounding code in the repository;
  • it reduces an 11 MB log to the excerpt that matters, with whatever its catalogue recognises in it;
  • it summarises the attached mission — theatre, date, weather, group counts — without publishing its contents;
  • it compares your problem against the open issues, the recently closed ones, the lots in progress and the roadmap. If it is already fixed, it tells you and opens nothing: that is the best outcome available, and you are unblocked immediately.

Nothing is published before you click

The bot shows you the issue as it will be filed, then waits. Three buttons: file, edit (the form comes back with your answers), cancel. If you do not click, the preview expires after eight minutes and nothing is filed.

That matters because you typed three fields and about twenty lines are about to be published: the log excerpt, the code, your environment. The click is where you see the difference and can say not that.

Your personal data is stripped before publication: paths from your disk, addresses, credentials. If that filtering cannot run, nothing is published — never a fallback to the raw text. One thing escapes the filter: what you type yourself. Write your name in what happened, or call your mission mission by John Smith.miz, and it gets published.

What happens next

The bot opens a public thread — in the Discord forum channel dedicated to the tools, when there is one — and puts the issue's link in it. When somebody answers on the issue, or when it is closed, the bot reports it in that thread: you do not have to watch GitHub.

A closed issue can be reopened — that is the normal answer to a "it is still not working" written in the thread. The bot then announces it there, takes the ✅ mark off the thread and puts it back in service, then brings over what was said on the issue in the meantime. It follows a closed issue for another week; after that, write in the thread and a maintainer will pick it up.

The other direction is manual: to add something — a file you forgot, a detail — write it in the thread and a maintainer will carry it over to the issue. The bot does not write from Discord to GitHub, deliberately: that would open a write channel onto a public repository from a room anybody can join.

The automatic hypothesis

On issues filed by a VEAF member, and while the day's allowance lasts, a model adds a hypothesis about the cause: a separate comment, labelled as a machine's guess, naming the suspected file and line.

It is not a diagnosis, and its absence takes nothing away from your report: everything else in the issue is measured, quoted or parsed, never guessed. When it is missing, the issue says why.

Suggest an improvement: /suggest

On the VEAF Discord, /suggest is for asking for what does not exist yet — a feature, a setting, a command. As with /bug, you need no GitHub account.

It starts by checking whether it already exists

That is the point of the command. A good share of requests are about something that already exists and nobody found: the best answer then is the page explaining it, right now, rather than an issue that will wait for months.

So the bot checks, in this order:

  1. the documentation — it puts your request to the assistant, which answers with the matching pages. If that answers your need, you say so and nothing is opened. It only says this already exists when it can show you at least one page: a claim with no page to open is not an answer;
  2. the open issues, by meaning and not only by words — in the same question, it compares your request against the titles of the open issues. No two people describe the same need with the same vocabulary, so word matching walks straight past a duplicate a human reader would see at once;
  3. the lots under way and the roadmap — it may be planned already, or deliberately turned down, with the reasons.

Every time, the bot shows you what it found and why, and you can answer no, that is not it: your request carries on. A machine does not get to decide on your behalf that your idea already exists — and neither does its silence: if you do not answer, your request carries on as though nothing had been proposed.

If it really is the same need, your voice is added to the issue

When you recognise an issue as yours, the bot offers to add your observation to it: who you are and the need in your own words, and nothing else — the issue already holds a request.

As everywhere else, it shows you first and publishes only after your click. Recognising an issue as your own is not the same act as agreeing to write under it.

It matters: a feature request is wanted or not, and a second person asking for the same thing is the only signal of priority it will ever carry.

If the documentation says nothing about the subject, the issue records that. It is useful: if the feature does exist, this is not a feature request, it is a page to write — and the cheapest fix there is.

What it asks you, and why

The form asks first what problem you are trying to solve, before the solution you imagined. That is the field everybody skips, and the one that makes a request decidable: a solution with no problem cannot be compared with anything, cannot be met another way, and cannot be declined for a reason anyone can state.

The bot writes no technical sketch. It states your need and what was checked; where it would fit and what it would touch is the work of whoever picks the subject up.

Nothing is published before your click

As with /bug: the issue is shown to you as it will be filed, with three buttons — file, edit, cancel. With no click, nothing is filed. The bot then opens a public thread and carries back what happens on the issue.

What an issue means, and what it does not

Said plainly, because it is what disappoints people who did not read it first: an issue is a record, not a commitment. A bug is true or false and can be verified; an improvement is only wanted or not, and the project's maintainer decides that alone.

A feature request therefore has two possible futures: it is picked up in a lot, or it stays open as a report. The second is not a failure: it records that somebody needed it, and the third person to ask will weigh more than the first.

What to provide

Useful reports all look alike. Three things, in this order:

  1. What you did, what you expected, what happened. Three sentences are enough as long as they are concrete: "I ran .\veaf-tools.exe build, I expected a .miz, I got a red error".
  2. The doctor block (below). It carries the versions and the paths — exactly what is almost always missing.
  3. The files, if you have them: the DCS log, the mission, a screenshot.

Running doctor

From the folder holding the executable:

.\veaf-tools.exe doctor

Why .\

PowerShell — the default Windows command prompt — does not look for programs in the current folder. Without the .\ it answers that the command does not exist, while the file is plainly right there. In cmd.exe the .\ is optional but accepted, so it is the form worth writing everywhere.

The command first prints a readable table, then a block delimited by === VEAF-TOOLS DOCTOR BEGIN ===. That block is what you copy into your Discord message or your issue, as-is.

It is built to be published: your Windows account name is replaced by <user> everywhere it appears, IP addresses by <ip>, e-mail addresses by <email>, and passwords and tokens by <redacted>.

What is kept is the name of your missions, aircraft and payloads: those are what say what it broke on, and hiding them would leave a report that says only "it did not work". If one of those names looks sensitive to you, glance at the block before pasting it — it is plain text, you can edit it.

To get only the block, without the table:

.\veaf-tools.exe doctor --paste

Where the logs are

There are two, and they do not say the same thing.

Log Where What it holds
Tool log %USERPROFILE%\.veaf\veaf-tools.log what veaf-tools.exe did on your machine: conversion, build, injection, and the full stack trace of any error
DCS log %USERPROFILE%\Saved Games\DCS\Logs\dcs.log what happened in game: script loading, Lua errors, VEAF module behaviour

If you set the VEAF_HOME environment variable, the tool log is written there rather than in .veaf. The doctor table gives you its exact path — the safest answer, since it comes from the machine itself.

The tool log is trimmed automatically: it rolls over at 2 MB, and three older files are kept beside it (veaf-tools.log.1, .2, .3). doctor looks for recent errors in those too: just after a rollover the live log is nearly empty and the whole history sits in .1.

For the DCS log, veaf-logs opens it and shows only what matters; the raw file is often over 10 MB, which is neither readable nor sendable as-is.

When it is DCS that is wrong

If the problem is in game — a mission that will not load, a module refusing to start, a missing VEAF menu — veaf-logs can also explain what it reads, and prepare a ready-made report block. See DCS is misbehaving, written for someone who has never run a VEAF command.

Reporting a security vulnerability

Do not open a public issue. Use GitHub's private reporting, which keeps the report confidential until a fix is released. The full policy is in SECURITY.md.

Going further