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.

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

parseGender improvements #121

Open
Tracked by #122
Toma400 opened this issue Sep 13, 2024 · 1 comment
Open
Tracked by #122

parseGender improvements #121

Toma400 opened this issue Sep 13, 2024 · 1 comment
Labels
code improvement Call for some improvement of code
Milestone

Comments

@Toma400
Copy link
Owner

Toma400 commented Sep 13, 2024

I'm really rusty on my old code (and IoA seems to be permanently in such state) but I'm wondering if the code made to parse text and replace its default M format couldn't be coded better? My concern is mostly accuracy and performance:

  • does current system runs everytime gender is even hypothetically the case? If so, this is heavy on performance and it should be decided on string level (so, not in code, but .toml/.json files). This could even hypothetically work better since not all languages need the conversion in the same contexts, so every string could have this decided for itself (more work for writers/reviewers, but yields significant resource savings)
    • the check could be for example ! symbol (or any other) preceding whole string
    • default should be no parseGender, because it saves us cost of removing the symbol
    • the other issue I could see is that there are texts that would benefit from both converting gender and not - I'd assume this kind of texts could have separate mark and then additional syntax later to signify which word should be translated and which not
  • current system is looping over dictionary, which makes it incredibly demanding as the dictionary grows
  • dictionary itself is difficult concept, because it does only simple replacements and requires a lot of work to maintain the list, as well for people writing narrative to use it as a tool
    • would it be possible to have some more performant solution that already has big data storage reflecting languages?
    • what if simple replacement does work incorrectly? wouldn't RegEx or something along those lines work better?
    • how easy it is to check for specific occurence for writers? would simple ctrl + f yield enough of possibilities, so you could safely check if the translation is there?

Just some concerns I had over few days and which should be adressed for this feature to be actually good and not something really hitting game's performance (as if it wasn't terrible already)


I went over the code and I'd say current code check may still have performance advantages over solely parsing first letter from text, or at least the cost difference is minimal (worth checking whether text[0] == "" is performant because it checks precise element, or not, because it parses whole string? just me spitballing).

@Toma400 Toma400 added the code improvement Call for some improvement of code label Sep 13, 2024
Toma400 added a commit that referenced this issue Sep 13, 2024
@Toma400
Copy link
Owner Author

Toma400 commented Sep 15, 2024

Idea partially taken from Reddit post I made on the topic - what if gender wasn't based on dictionary, but instead work similarly to how _descr works? I imagine this working like that:

regular_key^gender

Game would first look for gendered version, and if not found, it would search for just regular key. For example:

"test" = "Look at the player! He is such a lovely person"
"test^female" = "Look at the player! She is such a lovely person"
"test^non_binary" = "Look at the player! They are such a lovely person"
"test2" = "This is good day to kill some orcs"

In this example, test would adjust itself to all standard genders, while test2 would just aim to regular key. Minimum amount of parsing or checks, performance is happy.
I'd also brainstorm if parseGender check is still needed - I guess it's a bit less perf heavy than iterating over keys, so I guess keeping it would be useful.

Issues I could see:

  • any modded genders would have trouble being compatible, as they would overwrite each other (unless there was a patch later in load order)
  • finding non-TOML breaking symbol would be needed, so there's no need to wrap keys with ".." everytime - mind you though it shouldn't be _descr-like, because genders can be added, so the symbol must be unique to the extent

Neither really serious though.

@Toma400 Toma400 mentioned this issue Oct 5, 2024
36 tasks
@Toma400 Toma400 added this to the Pre-Alpha 7 milestone Oct 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
code improvement Call for some improvement of code
Projects
None yet
Development

No branches or pull requests

1 participant