Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

doc: Fix typos in converter #1588

Merged
merged 1 commit into from
Oct 21, 2023
Merged

doc: Fix typos in converter #1588

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion doc/code/converter/architecture_overview.md
View file
Open in desktop
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
View file
Open in desktop
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