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

[WIP] Add a console program #870

Closed
wants to merge 1 commit into from
Closed

[WIP] Add a console program #870

wants to merge 1 commit into from

Conversation

Sejsel
Copy link
Contributor

@Sejsel Sejsel commented Mar 18, 2024

Now that we have some processing logic split into ParserCommons, I looked at making a console program that can actually be ran on Linux with .NET 8. This basic version works for the most basic scenario without any configuration, but is nowhere near complete.

To achieve feature parity:

  • Configuration

Currently, the Windows program relies on WinForms-exclusive property APIs. I feel like within this console version, we might actually be better off by offering all these options as CLI arguments and scrap the file version completely; then we can construct ProgramSettings with that and continue as usual.

We should use a CLI argument library for this, I don't think it's viable to do it this way

  • Store api data somewhere sensible and predictable (another CLI argument, likely)
  • We need to get the EI version somehow

Preferably without duplication (likely needs to be moved into commons, it is possible to set version by inspecting other assemblies within msbuild config)

Improvements I would like:

  • A way to specify output file location (not just next to input file)
  • Refactoring the ConsoleProgram so that it doesn't do all its logic in the constructor, or just don't use it at all (looking back at it, that may have been the intention, I did have to move that to commons)

@EliphasNUIT
Copy link
Collaborator

I believe, at least for starter, it'd be better to keep the current "console" capabilities of GW2EIParser as to not cause a massive breakage with one release to the other and give time to console users to properly migrate.

I'm perfectly fine with not using the .conf file in the CLI, the console stuff in GW2EIParser is more an afterthought than a well thought solution, the conf file makes much sense for the "Save"/"Load" features of the setting panel.

"Store API data somewhere" You mean the GW2 API caches? If yes, then yes, we should avoid duplication in the project, they can't remain in GW2EIParser.

I believe you can already specify an output directory via OutLocation and setting SaveAtOut to false.

As a standalone, ConsoleProgram is not really necessary, its content can be moved out.

@Sejsel
Copy link
Contributor Author

Sejsel commented Mar 18, 2024

I believe, at least for starter, it'd be better to keep the current "console" capabilities of GW2EIParser as to not cause a massive breakage with one release to the other and give time to console users to properly migrate.

Yeah, I definitely do not want to release anything that would remove functionality. On the other hand, changing from mono to dotnet 8 is involved enough that I believe we can afford to change the CLI usage a little bit.

"Store API data somewhere" You mean the GW2 API caches? If yes, then yes, we should avoid duplication in the project, they can't remain in GW2EIParser.

Yeah, I meant those caches. I need to look into how they are stored, actually, all I see is that it clearly isn't cached the way I set it up as it downloads the data again on every run.

I believe you can already specify an output directory via OutLocation and setting SaveAtOut to false.
Yeah, that should work, I missed that when I was looking at the settings earlier, should be easy to add CLI arguments for that.

As a standalone, ConsoleProgram is not really necessary, its content can be moved out.
I agree, I just went for the fast option there without thinking about it too mcuh

@EliphasNUIT
Copy link
Collaborator

Currently the expected location for API caches is hardcoded based on the executable's location:

public static readonly string SkillAPICacheLocation = Path.GetDirectoryName(System.Reflection.Assembly.GetExecutingAssembly().Location) + "/Content/SkillList.json";

@Sejsel
Copy link
Contributor Author

Sejsel commented Oct 15, 2024

Obsolete due to #930.

@Sejsel Sejsel closed this Oct 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants