-
Notifications
You must be signed in to change notification settings - Fork 6
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
Replaced default CLEO directory in start script opcodes. #187
Conversation
weakly_canonical returns an absolute path, so |
Can we update ResolvePath in such a way that it:
Test casesroot =
0A99: 0same results as above 0A99: 1
0A99: "data"
0A99: "..\root\data"same results as above 0A99: ".."
|
This is writing explicit ModLoader support, but embedded into fabric of whole internal CLEO logic. As proposed before whole path processing inside CLEO should be done without complicating it with ML peculiarities, then just translate resulting path to the ML standard just before using it. CLEO5 was already rewritten to use absolute paths internally to avoid any ambiguities. Once resolved path is absolute and finite. Any further resolving causes no change. |
There is no new logic in the examples, it's just structured + tests cases are given. Which of them you think are wrong? |
Resolving 0A99 argument is not something that is stored anywhere and can be used for test cases in examples. Only persisting result is actual work dir.
and
should produce same result, so there is no point for checking what initial ingredients were. So if preparing path for ML it would make sense to check if the resulting path starts with game directory, then cut game directory prefix from it. Then also it should be checked if global work dir is actually set to game dir as ML depends on it. Then it all gets entangled again when taking into account situation where find_first_file is used along with 0A99 All those problems are already solved with generic approach and ML plugin providing exports: give me file, list me files. |
What test case I provided is incorrect?
it is stored as script's workdir and it is used in the logic I described as
|
They seems to be logically ok, in matter of what you want to send to ML. As mentioned CLEO5 is intentionally not working on relative paths internally, so that logic can not be embedded in generic util function for resolving paths. But... "logically" is not what ML is doing, as absolute/relative paths inconsistency was already observed. |
What functionality you expect to break if ResolvePath implementation changes to the proposed one? |
resolve_filepath opcode returning not resolved paths/mixed styles, cleo.log reporting ambiguous paths |
currently they return/report wrong paths assuming one location (CLEO) where in fact the physical location of the file is different (modloader). I think it is equally bad. |
I think it is already solved in ML branch. |
No description provided.