UI considerations
Thoughout the editor, there are interactions that might at first not be apparent. Context menus and tooltips were used liberally; try hovering and right-clicking on various elements to see whether there are any additional possibilities. If a certain text label changes background on hover, it is bound to have a context menu. Entries in list and tree structures also usually have context menus.
Leftside (game data area) and rightside (editor instruments area) both have draggable borders through which they can be resized; note that dragging is active only when areas are maximized. Click on any tab in the area will maximize/minimize it.
Layer system basics
Before jumping in the workflow, it will be beneficial to get a rough idea of how the data is structured in the editor.
Main editing unit in this project is a layer. Layer consists of graphical (sprite) and functional (points and features) information, contained together as many sub-entities in one big layer entity.
For example, ship layer starts with a sprite file. Without sprite file already present, no hull or skin files can be loaded onto layer. The sprite file serves as a visual base for functional data from hull file - namely, bounds, weapon and engine slots, etc.
Next slice is a skin file, which acts as a data mutator for hull file and also can override sprite itself.
Final slice of data for ship layer is variant. It behaves a bit differently from sprite and hull files - variant selection is loaded continually from game data panel each time layer is selected. In other words, provided you did load respective game data to the leftside data panels, all existing variants for hull ID will be automatically available for any layer with matching hull ID.
This effectively means that "Remove" button in the "Variant: Data" tab will altogether remove only variants that were created in the current session; variants loaded from files will be only reset to their state at load.
At this point a curious reader might inquire: why such a seemingly overcomplicated system of integrated data was chosen? Long story short, this achieves immediate visual cohesion: in one layer, you can see and access all of the needed data of ship without having to jump between different modes (you might jump between editing tabs, but there are options for visual data to stay visible) just to see where exactly this or that point actually was. Such a design also attempts to mimic the data handling process of the game itself.
Game data panel
Start your workflow by right-clicking "Game data" panel and selecting "Reload game data". This should launch a walker that will inspect game's core folder and each mod folder, then fetch all data of interest to the game panel itself. Alternatively, you can fetch individual data types by selecting data tab and pressing "Reload data" button located on the top panel.
Data of interest includes ships, weapons, hullmods, wings, shipsystems, hull styles and engine styles. Of those ship data entries are of note - they are comprised of hull file, skin and variant files and CSV row data. You can switch any ship entry between base hull and skin, if those exist for a ship.
For majority of entries, there's info about their files displayed on the right panel. For example, hover on "Hull file" label to see the full path to it; right-click and select "Open source file" to immediately open this hull file. There are also options to open folder that contains the file, and option to open the parent package of file.
Ship and weapon entries also can be immediately loaded from game data panel to main viewer: right-click entry in the tree panel and select "Load entry to layer". This should automatically initialize sprite, hull file, and all existing skin files (which you can later select from "Skin: Data" editor tab) to the new layer.
There is an even faster option for ship entries - simply double-clicking on entry will launch the same layer loading process outlined above.
Info about the files that are currently loaded to layer can be found in the tooltip to layer tab; this is sprite, hull and skin files for ship layer, and sprite and spec files for weapon layers. Note that weapon sprite files usually have 2 versions, hardpoint and turret.
Viewer area basics
When handling layers in main viewer, you can pan the viewport by mousewheel-click and drag; alternatively, mousewheel zooms to the position of your cursor, which can also be used for viewer traversal.
You can hold Control and mousewheel in order to rotate the viewer; alternatively, Shift and mouse move will rotate the selected layer. Note that these rotations are purely visual, unlike weapon and engine angle rotations.
You also can hold Shift and drag to move the selected layer around; note that points of the layer might change their displayed position in that case, which brings us to coordinate systems.
Viewer area has 4 different coordinate systems to choose from, selectable in context menu of bottom panel's mouse position widget.
- World coordinates have their 0,0 at coordinate axes guides (those are toggled in view menu). These coordinates are absolute and shared between all layers, they do not have any binding on point positions in result data that is saved to files.
- Sprite center coordinates have their 0,0, exactly at the middle of selected layer sprite. This is determined by sprite dimensions and is independent for each layer.
- Ship center anchor coordinates have their 0,0 at the bottom left corner of selected layer sprite. This is primarily used to work with a position of ship center point (said center is saved with these coordinates to result file), and is not much useful beyond that.
- Ship center coordinates have their 0,0 at the designated ship center point. This is the default, and primary coordinate system you will be working with when editing bounds, weapon slots, engines and other data points of the ship. These coordinates are independent for each layer and are the ones that are saved to result file.
Relevant to this info is the fact that serialized ship coordinates appear in the files as they are rotated 90 degrees rightwise. Preceding editors took this for granted, but, in order to achieve visual consisency with the game itself, this editor rotates the hull data coordinates back to where it should be when the layer loads.
Ship editing workflow
Whether you loaded existing ship entry from the game data or simply created new hull data (such an option is located in "Layers" section of menubar) on a sprite you opened, you'll notice that various widgets in editing tabs are now enabled.
Usually, hull creation starts with ship center point and collision radius - this is important, because designated ship center point also serves as mirroring axis anchor for other points such as bounds and slots.
For example, if your center sits right on the left boundary of the sprite, mirroring mode will put counterparts to the created points well outside of sprite itself.
Center and shield points are moved via simple mouse drag, while their radius is adjusted with hotkey press and mouse move.
After the center, collision and shield are configured, pay attention to bounds editing. This has 2 creation options: insert and append. Insertion places bounds between two closest points, while appending connects created points to the last ones in the bound list.
It is important to remember that bound points are linked via an ordered list; the last bound is linked to the first one. Relatedly, you can directly manipulate bounds order by dragging entries in the list, if the reorder checkbox is selected.
For creating brand new bounds polygon, prefer append with mirroring turned on - insert will not work if there are no bounds to insert between. Should any unfortunate inconsistency with bound linkage arise, turn mirroring mode off and adjust points, then wiggle them up with maximum point linkage value to achieve perfect mirroring again.
If working with points that are closer than 5 pixels to center mirroring axis, setting automatic linkage distance to 0 might prevent unintended snapping.
To be continued...
