Problems others have already ran into

From Torch Wiki
Revision as of 21:58, 12 March 2020 by LordTylus (talk | contribs) (→‎Namespaces to get managers from Torch)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search


Every day developers are working on either torch, or plugins for torch or just write mods for the game.

In any of these cases you may encounter problems, that may cause problems you sent hours on googling, talking to people on discord and trail and erroring till you finally got the result you are looking for.

This is what this page is for.

If you have found any weird things in the game, you spent long on to get a hang on you may add it to this page to help other developers who the don't have to annoy people with the same questions you did when they run in the same problems.

Object Builders and the Main Thread

In order to create any Block, Grid, even Planet you need to work with Object Builders. Every Entity can create its ObjectBuilder for you. However creating an ObjectBuilder is quite expensive from a performance stand point. So you may attempt to do it on a separate Thread to not block the UI Thread for too long.

However ObjectBuilders have to be created on the Main thread. If you don't do that you run in concurrency problems where someone on Main Thread changes blocks of a grid for example while you grab its ObjectBuilder. There are two possible outcoms. Either you crash with a ConncurentModificationException, The Main thread crashes with the ConncurentModificationException or neither of you crashes but the validity of the created ObjectBuilder cannot be determined. So it is potentially broken.

If you just want to get one ObjectBuilder is fine, if you want to get a reference of many ObjectBuilders make sure to grab them in batches so that one Update-Cycle only has to create one or two of them. And not reduce the simulation speed by that much.

Simulation speed calculation and impact

Basically Simulation speed is an anti proportional calculation.

Simspeed of 1.0 means everything was updated in 16.66 ms or less. If your simulation speed is below 1.0 you can figure out how long your update took by dividing your simspeed from 16.66

Example: 16.66ms / 0.6 = 27,766ms

The game itself seems to be unable to keep itself on 1.0 if the world is filled with many players. So your plugin shall not add any overhead to that. Especially Networking: Never do Networking on the Main thread.

even if its just 5ms for the request. Its 5ms that could a server running at 1.0 simspeed down to 0.7 for a tick.

Everything in the game affects the simspeed. Especially the following have huge impact

  • Update of grids (which can be improved using Concealment plugin)
  • Phsyics updates (which cannot be improved currently)
  • Ingame-Scripts (PBLimiter Plugin and Concealment can improve it)
  • Mod Updates (Appear in Profiler if too slow)
  • Plugin Updates (Cannot be monitored at the moment)

Since Plugins cannot be monitored its hard to pinpoint them being the problem for bad simspeed. So you always have to make sure your impact is minimal.

Namespaces to get managers from Torch

A simple call like:

PatchManager patchManager = Torch.Managers.GetManager<PatchManager>();

will cause Visual Studio to recommend you to add Torch.Session to your namespaces.

However that is not enough. It will then start to complain about GetManagers not being generic and therefore not compile.

To fix that you have to manually add:

using Torch.API.Managers;

to your namespaces in order to get your code to compile.