sigmmma / c20 Goto Github PK

If content is added for H2 or other early Blam! games, there may be "collisions" between page titles especially for those related to common tag types. For example, a "shader" tag class page will probably exist for both Halo 1 and Halo 2. This could cause user confusion and make cross-page linking more verbose with the need to provide absolute paths for everything.

Some ways to deal with this are:

• Make editors use absolute paths in links to disambiguate (with either undefined behaviour or error at build time otherwise)
• Include h1 or h2 in the title of pages to disambiguate. Should it be done consistently for ALL Halo 1/2-related pages?
• Prefer link references within local page hierarchy, e.g. [bitmap][] links to H1 bitmap from the H1 shader page, and to H2 bitmap from the H2 shader page
• Link references are done via a fuzzy match so users can disambiguate without having to provide a full absolute path, e.g. [biped][h1/biped] matches /h1/tags/object/unit/biped/
• Game-specific page styling to help avoid user confusion (e.g. xbox h1, pc h1, cea, h2)
• Some combination of the above?

CoS;

• Decide on an approach with feedback from editors
• The approach is implemented unless too technically complex, in which case a spin-off ticket should be created

We need a way to track contributions and display credit within the wiki. Git history is not ideal, since it will mostly be project editors making commits and we may write content based on the research of others.

CoS:

• We have a page listing all people who contributed directly or indirectly via research
• Each page lists authors/major contributions
• Page-level footnotes supported so we can reference research/tutorials

The "tags" page will be one of the heaviest used indexes on the site. This page should list every tag type and explain briefly their purpose. A table would be suitable.

CoS:

• The table has columns: Tag name, Tag class/ID, Inherits, Purpose
• The tag name is a link to the tag's page
• All tag types are present

When stuff is deployed to S3, the content in CloudFront should be invalidated. Otherwise, we can get assets cached at different versions and styles can be broken. This is pretty low priority because it's likely to affect us most at the start of the project when assets and markup are still under heavy development, rather than content which is OK to wait for the TTL.

Apparently there are some useful shortcut keys to activate commands/features in sapien

http://forum.halomaps.org/index.cfm?page=topic&topicID=45792

http://forum.halomaps.org/index.cfm?page=topic&topicID=49013

juicy frank mentions somebody may have poked around in sapiens executable to find some of them

make sure the game window in sapien is highlighted then press v+m

Tested in Custom Edition 1.0.10.621

When the profile is renamed in-game, the profile's folder and the "waypoint" file containing its relative path are updated with the new string which is limited to 11 characters.

However, the name in blam.sav is unchanged.

The buildspec.yml step to upload files to S3 was recently updated to:

aws s3 sync --delete --cache-control max-age=3600 --metadata-directive REPLACE ./dist s3://reclaimers-wiki-files

The --cache-control max-age=3600 header is now being set at sync time on an object-by-object basis rather than at the CloudFront level because CloudFormation/CDK doesn't support defining it there. However, as a side-effect the sync now updates every file for every build and is eating up our monthly S3 free tier budget.

Research different flags for s3 sync or different ways to do the sync, or a different way to set cache TTL.

Cloudfront can be configured to serve a 404 document. We should have one that uses the client-side search index to search for pages related to the URL the user was trying to visit.

The page structure is highly hierarchical. Breadcrumbs exist to show the user's current location, but they lack a view of what child pages are available within the current topic.

CoS:

• Decide if this should be in a sidebar or part of page content
• A tree view is added to all applicable pages

Constraints:

• Design doesn't have to be perfect, we can iterate on that later

Some practices will need to be established around writing style, document structure, and page hierarchies.

CoS:

• Decide on an approach to page hierarchies
• Document our desired writing conventions and style
  • Use of header levels
  • Consistency between pages
  • Spelling conventions (US vs Canada)
  • Amount of cross-linking
• Decisions documented in the repo as a root-level markdown file

With Spanish translation on the table, some restructuring of the project is necessary:

• Allow multiple source files for pages
• Split page metadata from readmes
• Multiple search indexes
• Localized URLs
• Localized tag structure comments

Mobile has been sorta considered during development. It's pretty half-baked, so we should do a pass on it to really make it mobile-friendly.

CoS:

• Tags table, and any other wide table, scrolls horizontally
• Sidebar items are laid out above or below the main article content
• Metaboxes are not too narrow -- maybe take up full width
• The title bar is appropriately laid out to not overflow horizontally. May need to hide "c20" and put the discord link under a hamburger menu, or add horizontal scroll.
• Search is still usable

We need a guide for beginners to get started with Halo modding, including:

• An overview of major tools
• Installing the game and the HEK properly
• Links to the HEK tutorial and Shelly's tutorial index

-vidmode x,y seems to inherit the refresh rate from the most recent player profile. Enforces V-Sync.
-vidmode x,y,0 seems to set refresh rate to 60 (not 0).
I didn't have the luxury of time to test these thoroughly.

This information isn't noted in the wiki

EXCEPTION halt in \halopc\haloce\source\tag_files\tag_groups.c,#3142: offset>=0 && offset+size<=data->size

Some kind of tag corruption from HEK+ extraction.

http://forum.halomaps.org/index.cfm?page=topic&topicID=38586
Monitor animations or a vehicle.

According to the 80/20 rule, 80% of visits will be to seek out 20% of the content. If we can identify that "hot" content, quick links or tips can be placed on the homepage to shorten the user's navigation path and time spent searching.

CoS:

• Page hits tracked
• Incoming links tracked
• Tracked in aggregate with no identifiable user attributes
• Let it bake for a while after launch to get enough data

I think animation period, phase, and scale should be thought of like a graph. Period should be the base length of the graph, phase would shift the values in the graph left or right and scale would repeat the length of the period or cut it short. Animation function would simply change the shape of the graph.

Perpendicular and parallel angles used for reflections create a fresnel effect.

The orange in this example being the perpendicular and the green being parallel

I couldnt fit it in the first image but detail map scale applies after the shader UV map scale.

Rotation animation centers are based off of the UV scale in the gbxmodel/model tag

In this example for a animation function of zero you would have to use 1.00023 for x and 1 for y. For the cyborg gbxmodel you would use 0.5 for both as the base map UV scale is 1.

Alpha test vs alpha blended decal

By default shader model uses alpha test which treats alpha transparency as 1 bit alpha, this creates aliasing and hard edges but sorts much better with other transparent surfaces. The alpha blended decal flag forces shader model to use alpha blend which is the default transparent shaders like chicago uses, alphas are in 8 bit and this provides very smooth transparency but at the cost of sorting terribly against other transparent surfaces, for this reason its relegated to decal like shaders where they are against solid objects.

Radiosity note: If detail level is set too high, the mesh the shader is on could attempt to subdivide too much and fail to render lightmaps. Some maps will fail to render lightmaps even with original shaders because these had to be changed on a per scenario basis. (irrelvant to shader model but its part of the tag so i thought i'd add it)

Self illumination color lower and upper bounds are interpolated between linearly with the animation function. Setting a color source can allow you to set the lower and upper bounds in the object itself and choose to use the flags to change the interpolation.

Change color channel source C will have it's color values overwritten if the scenario is multiplayer, with the hardcoded colors. If the channel source is A, it will be overwritten by actor variant color values if spawned as an ai (this one i haven't proven yet, it just seems to follow some kind of convention bungie used).

For detail map functions
double biased multiply: double multiply the detail map with the diffuse map, brightens the detail map before multiplying (standard setting, detail maps with grey backgrounds and black details)
multiply: multiply the detail map with the diffuse map (white backgrounds and grey-black details)
add: add the detail map to the diffuse map (useful for detail maps with light colors. black backgrounds and light details)

Base map attributes for shader model
The RGB is treated as diffuse color, alpha is treated as transparency. Halo predates physically based rendering, so lighting and shadows are typically baked or authored into the base map.

Ending thoughts
Maybe get actual image examples from halo itself if they can be used.

Flags

On/off toggles for various things

Can shoot while flying
Interpolate color in HSV interpolates between the change color bounds along hue saturation value
Has unlimited grenades when enabled gives the actor unlimited grenades
Moveswitch stay w/friends
Active camouflage when enabled gives the actor permanent camo comparable to player camo
Super active camouflage when enabled makes the active camo the "hyper stealth" variant in globals
Cannot use ranged weapons when enabled disables ranged combat settings
Prefer passenger seat when enabled will make the actor choose a passenger seat if one is available over a gunner seat

References

Misc tag references

Actor definition specifies which actor tag to use
Unit is what biped this variant will spawn as
Major variant determines the major variant this one can upgrade into

Movement switching

clueless about this at the moment

Ranged combat

Defines how actors use their weapon

Weapon is the referenced weapon the actor spawns with
Maximum firing distance is how far the actor can fire from in world units
Rate of fire lets you select a rof value within the weapons maximum rate of fire, 0 uses the weapons maximum
Projectile error adds error ontop of the weapons defined error
First burst delay time is the delay in seconds before the actor starts its first burst on a new target
New-target firing pattern time
Surprise delay time
Surprise fire-wildly time
Death fire-wildly chance
Death fire-wildly time
Desired combat range is the distance in world units the actor will try to be in to attack, lower bounds is the minimum range and upper is the maximum
Custom stand gun offset
Custom crouch gun offset
Target tracking is how closely the actor will follow moving targets. 0=not following at all and shooting at the targets last location before it moved, 1=following the target perfectly. interpolates everything in between
Target leading is how accurately to predict lead on moving targets. 0=not leading at all and shooting directly at the target, 1=perfectly predicting how far in front of the target to lead based on projectile speed and distance. interpolates everything in between
Weapon damage modifier is a multiplier on the weapons damage
Damage per second overrides weapon damage if set and weapon damage modifier is 0

Burst geometry

Controls burst properties

Burst origin radius is the starting point of the burst randomly from the left or right of the target in world units
Burst origin angle is the angle from the horizontal the burst starts
Burst return length is how far the burst moves back toward the target in world units. chosen randomly between the two bounds.
Burst return angle is the angle from the horizontal the return burst ends at
Burst duration is the length of the burst in seconds. chosen randomly between the two bounds.
Burst separation is the time to wait between starting a new burst
Burst angular velocity caps the speed on the return burst in degrees/s? effectively shortens the burst origin distance.

The burst origin and duration control how fast the return burst is. If the origin radius is large and the duration is short, the return burst will cover a large area in a short amount of time.

If the burst origin radius is non 0 and the return length is larger than the burst origin radius it will move past the target, and if shorter it will undershoot the target. Negative values can be used to move the return burst in the opposite direction.

Firing patterns

Multipliers to burst geometry and ranged combat settings depending on actors current state

New-target is when the actor finds a new target to shoot at
Moving is when the actor is moving between firing points while shooting
Berserk is when the actor is in a berserk state

Special-case firing properties

Actor charge fire or secondary trigger settings

Special damage modifier is a multiplier on special fire damage*
Special projectile error is error added ontop of the weapons error for special fire*
moved here from burst geometry because it didnt make sense for it to be there*

Berserking and melee

Ranges for berserk and melee in world units

Melee range is the minimum distance an actor will attempt to melee an enemy
Melee abort range is the distance an actor will give up on trying to melee an enemy once attempting to melee
Berserk firing ranges is the desired combat range for shooting while berserked
Berserk melee range is the minimum distance a berserked actor will attempt to melee an enemy
Berserk melee abort range is the distance a berserked actor will give up on trying to melee an enemy once attempting to melee

Grenades

Grenade settings

Grenade type
Trajectory type

Items

Controls what the actor drops on death

Equipment references the equipment tag the actor drops on death
Grenade count is how many grenades the actor drops on death, random range between the two bounds
Dont drop grenades chance is the percent chance the actor doesn't drop any grenades on death. 0=0% 1=100%
Drop weapon loaded is the percentage of the magazine/battery left in the weapon the actor drops on death, in a random range between the two bounds
Drop weapon ammo is the total reserve ammo the weapon can have when dropped, random range between the two bounds

Unit

Misc biped settings

Body vitality sets the actors body health
Shield vitality sets the actors shield strength
Shield sapping radius
Forced shader permutation forces the bitmap index for any shader the biped uses. ex: the grouped elite cubemaps
Change colors overrides the bipeds color change permutations

Hello, I wanted to give a tip about the debug menu in h3 Sapien. I don’t remember this being a feature in Halo CE, but I might be wrong since my knowledge is pretty limited. From what I can tell it is basically a more accessible and user-friendly way of executing commands.

Anyway, while looking at key binds for H3 Sapien, I noticed that there was no mention about a debug menu on the H3 Sapien page. The menu itself is pretty self-explanatory but it would be nice to see the key binds added to the page. The menu can be toggled by pressing Home and navigated using: Up, Down, Enter and End

I hope this information was helpful in some way.

blam.sav Gamepad documentation is rather sparse right now.

The resolution of this Issue will answer the following questions:

• Q: How many non-KB/M input devices can be assigned to a profile?
  A: Four. The game does not allow any more to be assigned. Forcing it to do so may lead to an overflow of blam.sav 0x32A-0x339.

• Q: How are the Menu Accept and Menu Back bindings able to share bindings with other controls, but not each other?
  A: Two reasons. Unlike other bindings, Menu Accept and Menu Back are offsets with values (button enums) written to them. Secondly, these offsets are located in a range separate from the other bindings' offsets, as noted in the previous question's answer.

• Q: How do I manipulate the file itself to assign bindings to Menu Accept and Menu Back for a specific gamepad in the profile?
  A: GamePad 0's Menu Accept is written to 0x32A. Its Menu Back is 0x32C. GamePad 1's bindings start at 0x32E and so on.
  Like many values in blam.sav, these are stored as Big-Endian Little Endian—the last byte in a value is the first byte at the offset in the file and the first byte is at the end of the offset.

• Q: How does the game know the difference between two identical input devices in the file? (how it does it in memory is another question altogether)
  A: Two reasons. The first is the device name. When Halo detects two devices with the same name, the second one will have " (2)" appended to its name. Secondly, a boolean-type Byte is written after the string "PIDVID" in what I will call the "footer" of a gamepad entry. After the footer, there are three bytes of empty space before the header (and device name) of the next gamepad.

• Q: Where are the gamepad bindings in the file?
  A: The bindings for Gamepad 0 are scattered throughout blam.sav with the bindings for each gamepad following one another.
  < a graph will be here later >

• Q: Is any other gamepad data written to blam.sav?
  A: As noted in previous question's answers, a gamepad's name/description, input bindings, Menu bindings, Product ID, Vendor ID, and duplicate-device bit are all written to blam.sav.

Additional data is being collected and organized.

Edit 1: I inferred the meaning of Big Endian as the opposite of what it really is. I had the meanings of Big Endian and Little Endian mixed up these past few days and I only now realized it.

The metabox currently shows tag dependencies, and with issue 12 will also show parental inheritance. However, child tags will still need their own section (e.g. shader showing all the various shader_* types). This can either be done as a metabox item or templated body section.

CoS:

• Determine which approach (metabox item, or body section) is best
• Like dependencies, children rendered to one level only -- the entire tag tree could become too large and irrelevant

Given the large number of editions of Halo titles, we need an unambiguous way to refer to them without being overly verbose each time. The standard should be added to the editor's guide (EDITORS.md) and applied across the wiki for any case we refer to a game by abbreviation.

MCC now fully supports and correctly renders a lot of shaders and effects correctly, and the wiki currently still has them listed as broken.

shader transparent generic

shader environment (bumpmaps shadows render, specular tinting works and specular masking works on objects like scenery)
EDIT: some BSP triangles are dark for some reason.

shader model (detail after reflection works as it should)

atmospheric fog (sky fog)

planar fog with fog layers (fog tag)
EDIT: fog isn't rendering correctly over models as of season 7, appears to be some kind of depth issue.

shader plasma

The Rust map-making wiki has coincidentally taken a very similar approach to us. They have visible contribution buttons on every page which link to github and prompt you to fork the repo, for example:

https://rustmapmaking.github.io/Wiki/Monuments

We can take a similar approach to help encourage contributions by readers

While contributing to Refined and working on Enhanced mod projects I started to keep a log of different issues with the Gearbox port of the game, ranging from engine specific to renderer and api issues. Noted behaviors and solutions/workarounds.

I've attempted to organize them into categories. Some of these might already be in the wiki, i havent had the chance to browse through the whole thing yet.

Renderer
Issues related to how the game renders shaders and effects.
-Fog screen layers effect does not render at all. All fog contains information in this section for a simulated volumetric fog (only working in the Xbox version, also might be broken in backward compat modes. need more confirmation). not the same thing as sky fog (atmospheric fog)
-Shield meters missing flash effect when drained, the end of the meter is brightened by a white gradient (only working in the Xbox version).
-Texture assets dont load immediately. Pillar of Autumn thruster lens flares for example, or plasma decals. Easiest way to see this is to load the pillar of autumn opening cutscene for the first time on game load, the thrusters almost dont show up at all in the time they are in view of the camera (only Custom Edition?).
-Detail after reflection flag is working in reverse of what it should. the flag changes the order the detail is applied as a toggle, detail after reflection marked should apply detail over specular/cubemap. (only working correctly in the Xbox version, Chimera has a built-in fix which is disabled for CE in the main builds)
-Environment shaders on objects do not function properly. Specularity isn't masked (only working on xbox), atmospheric fog also does not render correctly on objects that use environment shaders (only broken in CE).
-Bitmap types not normally supported without mods: all monochrome formats and p8 bumpmaps. these formats are high quality and save on space being channel limited (Xbox version supports these, Chimera supports them or used to).
-Various blend modes for shaders are broken. Multiply in transparent shaders, double multiply in decals and render invisibly (Decals work properly in MCC, decals also work with chimera now).
-Shader environment "normal" type wrongly masks primary and secondary detail maps when an alpha is present in the base map. See b40 exterior tech wall <<< my hypothesis for now (working on Xbox only).
-Shader environment does not tint cubemaps with the bumped cubemap reflection type, perp/para brightness does not work correctly either under bumped reflection with both just being a general scale instead of on angle. I believe some specular light is missing as well which makes dynamic lights appear a smaller radius (flashlight). Bumpmap shadows do not render on environment shaders from using lightmap/bsp info. (only working on the original xbox version)
-Weather particles dont draw near opaque fog, seems to be more transparency sorting problems, need a proper source but i believe it should either fade when the fog plane does or show up through the entire volume.
-Atmospheric fog appears to have sorting issues with fog volumes(planes), and is even further compounded by water shader sorting... see c10(guilty spark) swamp water/fog rendering its an absolute mess. the water sorting issues seem to have been fixed with MCC along with the mipmapping.

API
Issues related to how shader code is handled by the API on different hardware.
-Mirror surfaces don't reflect properly. light volumes/projectiles are offset. (only working in the MCC and Xbox version of the game).
-Water shader renders improperly in the Gearbox versions of the game. Mipmapping appears to be working in reverse. volume fog and atmospheric fog both seem to sort badly through both sides (working in MCC and Xbox versions).
-Glass shaders require mods to work in the Gearbox version of the game (Retail/Trial only). The same mods do not work for Custom edition (working in MCC and Xbox versions, CE needs a shader workaround)
-Environment shader self illumination animation has inconsistent behavior. Plasma animation does not scale or loop properly on some hardware (working in MCC/Xbox).
-Plasma shader has inconsistent behavior between different hardware. The wrong behavior is the default in MCC (only working in the Xbox version. Apparently MCC doesnt use 3d textures for this, i dont have an accurate source just hearsay).
-Some processors/gpus cause problems with the renderer, specifically transparent shaders stretching/exploding, and mirror reflections exploding (must force 1 core affinity in the game process)

Engine
Issues related to the way the engine handles certain features.
-Camera point animation stops being smooth at framerates over 60.
-Widescreen aspect ratios and FOV's over the default show normally offscreen garbage such as objects popping in and out of creation (Chimera has a cinematic FOV option to fix this, and will eventually get a pillarbox feature).
-First person models clip through geometry while active camo is in effect, something something clipping planes? (may or may not be fixable with mods).
-Transparent shaders occasionally Zfight with bsp geometry due to floating point precision (may or may not be fixable with mods).
-Contrail point generation tied to fps. Higher than 30 fps causes contrails to bunch up and twist, and animate faster (fixed with mods like chimera).
-No control over the quality of fonts, resolution and size are linked and tool rasterizes fonts automatically (chimera now has a high quality font feature to replace ingame fonts).
-UI bitmaps/widgets have some hard limits on resolution and resolution and size on screen are directly linked, you can work around it somewhat by using negative bounds values in the widget to scale a bitmap down. this doesnt really seem to work for widgets that are heavily cropped by bounds already.
-Transparent shaders do not sort properly behind Glass shaders, they will shift in front and behind each other. part indexes allow draw order to be set manually for objects through gbxmodel, there is no such method for bsps, the best you can do is flag the transparent shader to "draw before water". glass shaders seem to render in the same position as water.
-Dynamic shadows are at a fixed resolution/quality (may or may not be a way to change this with mods in the future)
-Weapon fire rates are rounded for values not divisors of 30, has to do with time and tick rates and 30 is the maximum fire rate.
-Camera shake in damage_effects tied to framerate, short duration shakes (0.05) get skipped occasionally at high fps (fixed and interpolated by chimera).
-Rounds between tracers should apply per projectile and not per shot, weapons like the banshee/ghost and shade turret do not work the same as their xbox counterparts.
-Radar blip ghosting effect/fading scaled by FPS. (Fixed with Chimera)
-Several debug and console commands are present ingame for PC but do not work or are disabled, and many of them work in sapien. it appears they do work in xbox builds of the game, mostly commands that draw to the screen such as debug_objects.

Editing Kit
Issues related to how the editing kit works with the HEK release
-Transparent shaders with extra layers will crash sapien when using the "transparent self occlusion" flag in object properties. Same shader will work completely fine ingame. Seems to be more of a warning, possibly for performance that is just enforced this way.
-Sapien debug wireframe colors change at angles. Hard to identify types of info when everything just turns black.
-Sapien game window is at a fixed resolution and aspect ratio.

MISC
Quirks or random tidbits/notes
-Transparent chicago shaders inherit parent properties if referenced as an extra shader layer, ie: first map type cubemap reflection flag will make the first map type for the child shader also a cubemap regardless of its own flags
-Transparent chicago extended shaders have an additional block used for fixed function rendering that uses less map stages.
-PC version of the game seems to be an earlier version of the engine pre-retail xbox release as evident by missing features, an incomplete renderer and beta assets.
-Some tags are changed by tool depending on scenario type for balancing in campaign (plasma rifle and pistol)
-cannot unmerge scenarios/extract child scenarios from maps, source tags needed and we dont have access to them. this causes things like duplicate camera points and infamously the garbage collection spam for c10 in sapien.

Cloudfront shows this to be a hotly requested file -- we should help bots crawl the site.

Header anchors were not a feature of the wiki until recently. None of the current content references other pages to a specific header.

CoS:

• Implement a way to use anchor tags on named destinations like [lightmaps][scenario_structure_bsp#lightmaps]. This currently doesnt work and would require you to provide the whole tag path in [lightmaps](/tags/.../scenario_structure_bsp#lightmaps) format
• Browse through all existing pages and use anchor links where appropriate

Having a sound_looping with multiple simultaneous layers for a portalled background sound it seems to be that the engine will only visibly play back the first two ambient_nature sounds in a list. Any further sounds will not be heard.

The Sapien limits section could use a bit more explanation, possible in guide form, on how to patch the application to support 4GB of virtual memory.

Moses' discord posts got archived, lots of useful information on transparent shader types
https://drive.google.com/file/d/1Rm9LoAKPgepOH1wLQfRHNiaVa1iwVEaO/view

Most noteable thing in there being transparent generic, which he explored while working on refined, unknown territory for most people, could be useful in the future or for creating shaders for xbox maps.

Searching for "tags", I get both the H1 and H2 tags pages but it's not clear which is which.

With access to tag structures when rendering pages, we should be able to render out a table of tag fields and blocks.

CoS:

• All tag pages gain this content
• The section at the end of the page, since most users won't need it
• The section appears in the automatic table of contents if the page uses that feature
• Sub-structures and blocks are annotated as such
• Data types represented, e.g. tag references, ints, floats
• Both tag and map/in memory representations available

Currently, tables of contents are generated using a markdown-it plugin which converts [[toc]] within the page markdown into a table of contents of the headers in that markdown document. However, this can't include headers it doesn't know about. Rendered markdown is just one part of the content for tag pages, for example.

CoS:

• Programmatically generated headers like "Tag structure" should be able to be included in the ToC.
• Only headers from the page content are included; e.g. nothing from the page wrapper or metabox.

For a heading "It's broken", its ID and URL slug becomes it-39-s-broken. Something is encoding the apostrophe before slugify gets a chance to remove the character. Also any markup in headings, like links, causes similar issues.

The tag shader_transparent_water doesn't list any tag dependencies even though it should have at least bitmap. Something's up here!

Opengraph metadata, which is placed in the document's <head>, helps social media platforms show previews for C20's pages. For example, discord:

We especially want to make sure this works well for Discord since many of our users will be sharing links there. The groundwork has been laid, but the preview is a bit lackluster.

CoS:

• Page introduction is included as a short summary in the og:description property
• The description text should not contain any markdown markup or HTML -- pure text only

The homepage currently serves as a big page index out of necessity, but isn't the role it should be serving long term. The wiki will have major topic areas like:

• Tags and engine info
• Communities
• Data formats
• Game info
• Tools
• Guides

To reduce information overload, each of these should have a respective main index page which the homepage can serve as a portal into. Note that it will be necessary to implement child pages (#8) before this so navigation is still functional.

We currently support viewing the dependencies for a tag within the metabox, grouped by inheritance level. However, there's no easy way to see a list of dependents.

CoS:

• The list of tags which depend on a tag are included in the metabox
• Decide if only direct dependents are included
• Tag pages are linked

globals.globals tag, rasterizer block, active camo sub

tint edge density flag
adds the tint color to the background

refraction amount
how much to distort the background, lower values distort more, higher distorts less. measured in pixels?

distance falloff
the distance in world units the active camo effect fades completely and the object is entirely invisible

tint color
color multiplied over the background

hyper stealth values
same as above but used when "super active camo" flag is enabled in an actor variant

extra: the alpha channel in the active camo texture masks the tint colors on PC

Transparent shader's UV scales are relative to model/gbxmodel UV scale.

Map UV scale 0 does no additional scaling, but 0 gets defaulted to 1 on cache build through tool. If model scale is not 0 or 1 then shader scale will cause unwanted scaling.

The solution is to have the model UV scale as offsets in the shader (shown in first picture).

This behavior only happens with transparent_chicago.
Note: the model UV scales can change when re-compiling the model.

i might need some help with this one, i cant fully explain it.

filthy part indexes can be used to change render order of transparent shaders. as far as i know only the needler fp.gbxmodel has them explicitly set in original tags.

through previous filthy part index you can set the part that will render before the current part. next filthy part sets the part that will render after the current part. -1 is a null value to not use an index, im not really sure what this does but it seems to be required. i wasnt able to figure out how to apply this to a model with only two parts, i had to create a new part for index 0 in needler ammo gbxmodel.

the fp needler model uses this to render the "core" over the glass, it also prevents a sorting issue that happens when transparent shaders are behind glass shaders that causes flickering when viewing at different angles.

In the tag template, dependencies are listed in full for each tag as a section of the "metabox". For some tags like weapon this list becomes full of dependencies from tag superclasses like item and object, making it less clear what the immediate dependencies are. The dependencies list is meant to help show what tags are related to the one the user's currently viewing. Organizing the list by inheritance would clarify what dependencies are highly specific to the current tag.

CoS:

• The dependency list is broken into sections by which level of inheritance the dependency came from
• Tags remain sorted by ascending name within each inheritance level
• Direct dependencies order first, followed by ascending inheritance level (e.g. Vehicle, Unit, Object)

Constraints:

• Additional metabox features (e.g. expand/collapse) are a non-goal of this ticket

Example page:
https://c20.reclaimers.net/h1/tags/actor_variant/

This is preventing the page from having a text preview when pasted in Discord.

When viewing resource pages under data or tags, it would be helpful to see what tools can edit, view, or convert that resource. Similarly, tool pages can have the same references in reverse. This is ideal content for the metabox.

CoS:

• The metabox contains tools which can operate on that resource
• Show conversions to other resource types (e.g. tif --(tool)--> bitmap)
• Tool pages show links to the resource types they can operate on
• The tools main page shows a diagram of all conversions and workflows

Tag definitions from the invader submodule are outdated. For example:
SnowyMouse/invader@ab0731b

Last time I checked, c20 doesn't build when using a newer invader version, so expect some minor breaking changes to how we consume the tag structure definitions.

### ERROR vertex #0 has a bad point.
### ERROR failed to import collision bsp.

Tool error for bsp models exceeding a certain size (?) physically during compile.

http://forum.halomaps.org/index.cfm?page=topic&topicID=38314
https://discord.com/channels/228263208299790338/523620962390769695/859783266834579516 (reclaimers discord)

The page table of contents can become pretty unruly when the tag structure is large (e.g. scenario) or there are a lot of article headings (e.g. bitmap). The commonly used detailsList UI component would be a good substitution for nesting ToC. We'll need a way to force it to show single children as a list still instead of a single line, but this can just be another optional argument to it. The detailsList already knows when to collapse a list when it's too long.

We're missing a lot of details on how to use Sapien's UI. Rather than shotgunning little bits of info as we come across it, I suggest we assemble tidbits on this issue then write it all into the wiki in one go. This should let us organize stuff better too.