mirror of
https://github.com/1dot13/source.git
synced 2026-08-05 14:00:23 +02:00
d683cdeb64
* prepare gamedir for running the game * Stop telling installers to overwrite the vanilla game The release no longer contains anything that lands on a vanilla file: its base data lives in Base, so unpacking it over the game directory and copying the game's Data into the release now amount to the same installation. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * Give the mod's base data its own VFS profile Its files ship in Base now, so that a vanilla Data directory can be copied in whole without a single collision. Mount Base right above the vanilla dirs in every profile stack — the slot where the installer's overwrites used to end up. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * Mount Base in the language overlays' VFS configs too Assembling a release copies a <Language>_Version directory over gamedir, its own copies of the configs included, so without the same Base profile every non-English release would mount nothing from Base. Their libraries move along with the rest of the base data: each language slf, and the Russian data.slf that shadows the vanilla Data.slf by name. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * Ignore a vanilla Data directory dropped into gamedir Running the game here needs one copied in, and it is an untouched copy of somebody's retail install — nothing this repository should track. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * Ignore only the player profile directory, not every Profiles The unanchored pattern also swallowed Base/TableData/Profiles, the mod's soldier profile XMLs, which are tracked and belong in a release. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * move gamedir/Data to gamedir/Base * move gamedir-languages' Data to Base --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
39 lines
2.1 KiB
XML
39 lines
2.1 KiB
XML
<!--
|
|
We define various map interactions in this xml. If we hover our mouse (after right click) over a tile and it fits a set of data from here,
|
|
we can interact with it, setting of various actions that.
|
|
We can define interactions very broadly (example: we define all water taps found in any location in any map to behave a certain way) or
|
|
very precise (example: set a specific computer in a specific to do something). Note that more precise actions override broad descriptions
|
|
(so we can set a very broad action for all water taps, and then define one specific one to behave differently).
|
|
|
|
SectorGrid sector that this action happens in
|
|
sectorlevel 0: surface 1-3: basement
|
|
|
|
If we do not set SectorGrid and sectorlevel, this action will work in any sector in any location (sStructureGridno and sLevel are no longer used).
|
|
|
|
szTileSetName tileset that the structure we 'interact' with is part of
|
|
usTileIndex index of the structure in the tileset, multiple ones can be set
|
|
|
|
These have to be set, and define what specific structures are valid for the action. We can set multiple indizes via usTileIndex (see examples).
|
|
|
|
sStructureGridno location of the structure (you can get that by pressing [f] in tactical), multiple ones can be set
|
|
sLevel 0: floor level 1: on a roof -1: don't care
|
|
|
|
If a specific map was set above, we can set a specific location here.
|
|
|
|
sActionType what kind of action is possible here?
|
|
0: nothing
|
|
1: hack a computer
|
|
2: read a file from a file cabinet
|
|
3: take water from a water tap
|
|
4: buy soda from a soda machine
|
|
5: play a minigame
|
|
difficulty how hard it is to perform action
|
|
luaactionid if this is set, lua script HandleInteractiveActionResult() in Overhead.lua is called
|
|
with this Id to perform special actions. If no ID is set, the standard action is called.
|
|
|
|
In this file we always define in general with what we can interact, and then set specific interactions.
|
|
-->
|
|
<INTERACTIVEACTIONS>
|
|
|
|
</INTERACTIVEACTIONS>
|