Skip to content

Commit

Permalink
doc: Fix typos in converter
Browse files Browse the repository at this point in the history
fixed typos in the architecture and workflow files
  • Loading branch information
fabiobarkoski committed Oct 20, 2023
1 parent e83bb4e commit 80eb80f
Show file tree
Hide file tree
Showing 2 changed files with 5 additions and 5 deletions.
2 changes: 1 addition & 1 deletion doc/code/converter/architecture_overview.md
Original file line number Diff line number Diff line change
Expand Up @@ -30,7 +30,7 @@ Value objects are used to store primitive data or as definition of how to read p
In the converter, the parsers utilize these objects to extract attributes from the original Genie Engine
file formats. Extracted attributes are also saved as value objects.

Value objects are treated as *immutable*. Operations on the objects's values will therefore always return
Value objects are treated as *immutable*. Operations on the objects values will therefore always return
a new object instance with the result and leave the original values as-is.

### Entity Object
Expand Down
8 changes: 4 additions & 4 deletions doc/code/converter/workflow.md
Original file line number Diff line number Diff line change
Expand Up @@ -66,7 +66,7 @@ content can be accessed in the same way as "loose" files from the source folder.

After all relevant source folders are mounted, the converter will begin the main
conversion process by reading the available data. Every source file format has
its own reader that is adpated to the constraints and features of the format.
its own reader that is adapted to the constraints and features of the format.
However, reading always follows this general workflow:

* **Registration**: Enumerates all files with the requested format.
Expand Down Expand Up @@ -100,7 +100,7 @@ attribute values (e.g. `"attack"`).
For example, a `uint32_t` value could be used for a normal integer value or define
an ID to a graphics/sound resource. Every unique value type is associated with
a Python object type used for storing the attribute.
* **Output mode**: Dtetermines whether the attribute is part of the reader output
* **Output mode**: Determines whether the attribute is part of the reader output
or can be skipped (e.g. `SKIP`).

The Reader parses attributes one by one and stores them in a `ValueMember` subclass
Expand Down Expand Up @@ -162,7 +162,7 @@ In general, it involves these 3 steps:

1. Check if a concept group has a certain property
2. If true, create and assign nyan API objects associated with that property
3. Map values from concept group data to the objects' member values
3. Map values from concept group data to the objects member values

This is repeated for every property and for every concept group. Most values
can be mapped 1-to-1, although some require additional property checks.
Expand All @@ -173,7 +173,7 @@ that contains the ID and the desired target filename. In the Export stage, the
source filename for the given ID is then resolved and the file is parsed, converted
and saved at the target location.

At the end of the mappping stage, the resulting nyan objects are put into nyan files
At the end of the mapping stage, the resulting nyan objects are put into nyan files
and -- together will the media export requests -- are organized into modpacks which
are passed to the exporter.

Expand Down

0 comments on commit 80eb80f

Please sign in to comment.