Work in FXCode without confusing hints with tests
FXCode is the Code-OSS-based editor inside FxDK. It brings editing and development views into the local workflow; it is not a separate production runtime. Start with the FxDK platform and isolation requirements, then use this sequence to diagnose one resource.
Open a small project and verify its file boundaries
Add the runtime lab to a dedicated project. In the resource tree, identify server.js, client.js, html/app.js, the two C# projects and fxmanifest.lua. Each file belongs to a different environment:
| File | Environment | A misleading assumption to reject |
|---|---|---|
server.js | Server Node runtime | A Node I/O callback can call any native without scheduler handoff. |
client.js | FiveM client JavaScript | It has Node fs or the browser’s document. |
html/app.js | NUI browser | Its validation is a trusted server permission check. |
| C# client/server assemblies | Their respective CitizenFX runtimes | A client native suggested by a language service must also exist server-side. |
Native completions and diagnostics help find spelling/signature problems, but they do not establish the execution side, package version or artifact behavior. The official FXCode manual documents the integrated editor and language tooling. Add language definitions deliberately; do not claim a language is fully configured merely because FXCode opens the file.
Follow edit → compile → restart → observe
Make one bounded source change, such as adjusting the local timer message. Run the lab’s node build.mjs entry point or the configured FxDK build hook. Check the compiler exit and the exact DLL path, then restart only the affected development resource. Inspect both client and server consoles; a server startup error and a browser callback timeout are not interchangeable symptoms.
Open /fd_form, submit a preview, close with Escape and restart with it open. The browser must receive a callback response and the resource must release its focus. Use NUI debugging for the browser side and the profiler for measured runtime cost. Do not add an infinite polling loop merely to make the editor show activity.
Diagnose by evidence
| Observation | Next check |
|---|---|
| C# edit appears to have no effect | Compiler ran successfully; manifest loads the newly produced assembly, not an older copy. |
| Completion offers a native but runtime says it is unavailable | Correct client/server API set and selected game track. |
| UI opens but submit hangs | Correct resource name/callback path and exactly-once callback completion. |
| Works in the editor project, fails in exported output | .fxdkignore, dependencies, compiled filenames and private configuration. |
| Works alone, fails with another player | Test outside single-user FxDK with the two-client matrix. |
Save a reproduction with the resource revision, selected runtime and concise redacted errors. The example compiler and protocol tests are automated; no graphical FXCode interaction is claimed by those tests. Continue with project packaging before distributing the resource.