We should cache the height of terrain in TerrainMap.

This will let us avoid using Terrain.SampleHeight(), and will also be necessary for the vision code to handle elevation changes.

Turret system currently wont lock onto soft vehicle targets if a unit only has small arms weapons. The issue is in Ammo.cs, GetRangeAgainstTargetType. However it also has to do with how we currently pick targets. Ultimately the issue is that we should only pick vehicle targets if they are facing us with a <2AV side, and drop them if they stop facing in this way (currently we never really drop the current target).

Obsolete, old description:
When defining the damage types I forgot to include small arms.

We need to add a small arms option to the unit config, a small arms damage type in Ammo.cs, and a small arms formula in ArmorComponent.cs. This damage type doesnt have an explosion radius, does 10% damage against 1AV and no damage to 2AV.

Might need a heavy small arms type which follows the same rules but does 50% damage against 1AV.

Also we might need to do this with an AoE tag if we want to allow cluster..

When a buy preview is created, the platoon label briefly appears in the center of the screen before moving to where the preview should be. This visual lag should be fixed.

Currently if a unit is spotted by a third party but not in direct line of sight of a shooter, the shooter will still shoot. This should not happen.

Currently we're committing binary files like the terrain data into our repo. Instead we should put them in LFS. Care should be taken to not disrupt the workflow of non-technical users (github desktop claims first class LFS support, so it should be easy enough to make this change in a transparent way).

An issue is that we likely can't use github's free hosting service (see https://medium.com/@megastep/github-s-large-file-storage-is-no-panacea-for-open-source-quite-the-opposite-12c0e16a9a91). This means that the change will also require setting up our own LFS server.

Alternative solutions like dropbox can also be tried, but they must not complicate the setup for first-time users.

it is possible to deploy units into the river - the model ghost appears on the river bed - upon spawning, the unit sits at the spawn position not moving

With version 8fae01f , reported by MarinusTau

• Following error is becoming more common and pauses the game, now with fasttank and marines and riflemen:
  NullReferenceException: Object reference not set to an instance of an object
  PFW.Units.Component.Weapon.TurretSystem.Update () (at Assets/Units/Component/Weapon/TurretSystem.cs:103)
  --- Error possibly also came at AOE destruction of a kamaz truck?
  --- Another hunch: rotation beyond 90° seem to also cause it? <- maybe rotation around wrong axis causes error`?

DannyMcGee wrote us some unit label code but left it unfinished. To use the essential parts of it, I wrote the simple PlatoonLabel class and merged the code in commit dfac763.

The original code is still in the repo, unfinished and more complicated than our current implementation. The classes can trivially be removed, but they probably have features and design improvements that we can take over. The PlatoonLabel prefab also has a lot of stuff on it that is disabled and was originally to be used by that code. We should take over what makes sense and remove the rest.

The legacy classes/files are:
BackgroundBlur.shader
UnitLabelGFXController
ButtonGFXControl
UIGFXController
HealthBar
UIState
UIColors

Currently KE/HEAT damage is applied on shooting. Instead we should apply it when the shell hits the target, ideally also with some prediction code to ensure shells do hit moving targets.

BulletBehavior.cs picks a vertical velocity for shells so that when gravity accelerates them back into the ground, they land on target. Independently of this, Turret.cs just aims the gun at the target, or toward the sky if artillery.

In reality the relationship between vertical and horizontal velocity is determined by how the gun is angled. If a shell is fired with vertical velocity 1000 and horizontal velocity 500, that should mean the cannon is tilted up quite a bit; if the velocities are equal then it's at 45 degrees etc. If we determine the barrel angle from the velocities needed, we won't need to make a distinction between howitzer and tank cannons.

The angle X can be calculated as tan(X) = vertical velocity / horizontal velocity

We have several graphical elements that need to be drawn on top of everything - sandman's pathfinding debug lines, the targeting overlay and the vision measuring overlay (T and R hotkeys).

Previously we ensured they're drawn on top of everything using a second camera with the 'OnTop' culling mask. This was disabled to improve performance (avoid rendering everything twice). We should get those elements to show up on top of everything again by making them into UI elements or using a shader or some other solution.

Currently the hotkeys are hardcoded. Instead we should create a json file in a resources folder that we read at game start.

Stretch: The file can have two copies. DefaultSettings.json would be committed in git, while LocalSettings.json would be created if the user changes a setting in the GUI and would override anything in the default set.

In the very very far future we might want to look into generating terrain from https://www.openstreetmap.org/ and the likes

We should implement flares for team communication.

Basic:
Pressing a hotkey or clicking a UI element enters flare mode. When the user clicks the terrain while in flare mode, an 'ATTACK' (or 'help', or custom text) GUI label appears where the user clicked. Flares are destroyed after 3m, or after the owner destroys them.

Improvements:

• flare variant with custom text
• graphics for flare (just take a smoke prefab and change the color?)
• sync them (easy feature to learn networking on, since only spawn/destruction have to be synched)

The settings menu currently only uses text input fields which aren't appropriate for most of the entries.

The camera zoom/pan/etc values could be improved by representing them with a slider.

The hotkey inputs could be improved by making them listen for a keypress.

We have a lot of configuration-related json files. Currently these are read as text assets from the resources folder. This will not work in the built game as there is no resources folder in that case.

We should rewrite what we have in ConfigReader.cs to either use AssetBundles, Application.persistentDataPath or something else. We'll probably need different approaches for the editor and non-editor case. Application.persistentDataPath seems like the easiest/best choice for the release case, but it puts the files in AppData which can be inconvenient since a lot of those json files are meant to be easily editable (such as the local settings file).

The flares, spawnable with F1-F3, have some open improvement points:

• There should be a per-player flare limit (suggestion: 20)
• A sound should be played when a flare is spawned
• The custom flare spawned with F3 should open a text box that the user can type in while placing the flare

Reported by testing:
pathfinding is still a little wonky with fast move - giving a direct right click will make units zoom across fields, while giving a fast move command feels like crawling along road comparatively

Currently we don't implement the full reload systems with salvos, instead cannon.cs just uses SalvoReload as a shot reload. We should implement salvo behavior, including automatically refreshing the salvo if the unit hasn't shot in the past {SalvoReload} seconds.

Our unit config has a hierarchy of turrets which recursively can hold child turrets. Unity json util throws a warning about serialization depth limit because it can't handle recursion. We'd have to either switch to a worse config format or use a different json utility.

Until this is done we will have a warning when starting the game about serialization max depth limit being reached.

We should show the selection circles when previewing a selection too, not just when its completed.

[3:28 PM] Firestarter: ok I did some reading, we dont need a custom tool for painting terrain
[3:28 PM] Firestarter: we can export splatmaps and let Unity assign materials to the masked out image
[3:28 PM] Firestarter: however
[3:28 PM] Firestarter: you cannot import splatmaps via GUI
[3:28 PM] Firestarter: lmao
[3:29 PM] Firestarter: you need to load them from script
[3:29 PM] Firestarter: which I have no idea about
[3:29 PM] Firestarter: we dont need this now, I will hand paint this first map, but for the future its worth looking into it
[3:29 PM] fade: whats a splatmap
[3:29 PM] Firestarter: a splatmap is an RGB image with 8 distinct colors
[3:29 PM] Firestarter: each color corresponds to a terrain texture/layer
[3:30 PM] Firestarter: the terrain reads the splatmap data as input, and will paint the terrain based on the splatmap
[3:30 PM] Firestarter: like a mask
[3:32 PM] Firestarter: so we have Vegetation Spawner asset to spawn vegetation on specific terrain layers
[3:32 PM] Firestarter: and with imported splatmaps

Relevant? :
https://blogs.unity3d.com/2019/08/15/accelerate-your-terrain-material-painting-with-the-2019-2-terrain-tools-update/

• Drop height of unit labels when looking into the distance: https://imgur.com/a/pEKGywc - Since labels of closer units are closer to the model, it gives the impression that the units in the distance are further away
• Seems there is some transparency in the LOD of the bloodhound, but this might just be me getting ahead of myself in this stage of the project - https://imgur.com/a/m4AoxbV

Related issue: we should make it so the labels arent on top of the model when zoomed in really close,

Hotkey that resets targeting and stops movement. (Suggestion: 'C')

Needs to be detected in InputManager, propagated and properly handled by the units, shown in the settings panel and stored in the user hotkey settings json.

Good first issue because no Unity-specific programming is involved.

Our unit config files allow a c-style #include directive, which lets us break them up into small reusable pieces. Example:

{
    #include "DefaultMobility",
    #include "DefaultHeloArmor",
    "LabelIcon": "D",
    "CategoryKey": "HEL",
    "Name": "AH64D Apache",
    "Price": 20,
}

ConfigReader.cs has some custom code which replaces the #include lines with the content of the corresponding json files (e.g. DefaultMobility.json). This code does a lot of string operations of what will be hundreds of files, and is part of our startup loading work.

There are optimization opportunities:

• Smarter iteration over the files (currently if a file is included from two places, we will scan it twice instead of just once)
• Baking the results - for example, once the includes have been replaced everywhere, save the 'assembled' json files in a generated folder and use them for future launches. If the user changes the unit config, they will need to delete the generated folder.

Add a bar at the bottom of the loading scene/screen that shows game tips.

The following fields should be moved from hardcoded to being in the unit config:

shell explosion fx, shell explosion size
unit explosion size (maybe)
convert move speeds to a sane representation
'prefabAdditions' field that allows adding meshes to the main model, such as turrets Declined: If someone needs to do this, they will have to work with the prefab in Unity anyway. So it is easier to just have that person make a full prefab. This is a rare use case and if we were to support it it would mean extra code, lots of turret prefabs lying around unused in the project, and it won't even work that well since most turret swaps also require hull adaptations IRL (you cant just plop down the turret on a hardpoint and call it a day).

there are many more but I need to remember/have them pointed out to me

We move shells and other projectiles using a custom trajectory calculation in BulletBehavior.cs. The current implementation assumes that the tip of the arc is the midway point between target and the starting position, which only works when the target is at the same elevation.

We could also consider using unity physics here, maybe it leads to better results.

Currently connecting to an ongoing multiplayer match doesn't work, it would be nice to fix that.

Hint:
We should use the OnClientConnected callback to get the unit setup done for new clients. The ideal would be to do all post-spawning initialization through those, so we don't have to maintain two cases (initialization directly after spawning for normal clients and late initialization for reconnecting clients).

Disconnecting would be more trouble and isn't worth fixing right now.

Should/will break this down into separate entries but it's better than not marking it at all..

Issues:
General:
• Camera zooms underground facing the sky (zoom in and rotate shifts it above ground again);
○ sometimes models are gone afterwards near point of inversion

• After a fire position command, unit fires, move arrow disappears, despite unit continuing to move

Pathfinding:
• Pathfinding collision between units causes wavelike acceleration and slowing down, with units weaving to avoid each other (also on & off road), cause them to slow down
○ Fasttank, plz-8 and marines seems wonky on streets (slower?)
○ Other triples of units seem to have similar issue

• PLZ-5 vastly faster with right click vs fast move command, but only if road between current location and destination
    ○ Fasttank has similar behaviour; tested around a T-junction

--> Possibly connected to issue above

• Apache overshot turn to bridge and had to double back to cross (wasn’t able to reproduce, possible in groups of units)

Console Errors:
Incorrect use of Destroy. Use NetworkServer.Destroy instead for networked objects.
UnityEngine.Debug:LogWarning(Object)
Mirror.NetworkIdentity:OnDestroy() (at Assets/Standard Assets/3DParty/Mirror/Mirror/Runtime/NetworkIdentity.cs:494)

for example, alt+1 to open logistics tab, or something similar that makes sense to you

This seems like an easy programmer task, look for old commits where I added hotkeys for other stuff