-
-
Notifications
You must be signed in to change notification settings - Fork 438
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
Add getResourceFiles
#3603
base: master
Are you sure you want to change the base?
Add getResourceFiles
#3603
Conversation
Very nice. Can you add an argument "resource element" so you can get file list of another resource, which would work if it is running? |
Already did ;) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
switch (resourceType) | ||
{ | ||
case eResourceType::RESOURCE_FILE_TYPE_SCRIPT: | ||
case eResourceType::RESOURCE_FILE_TYPE_CLIENT_SCRIPT: | ||
m_resourceCategoryType = eResourceCategory::SCRIPTS; | ||
case eResourceType::RESOURCE_FILE_TYPE_MAP: | ||
m_resourceCategoryType = eResourceCategory::MAPS; | ||
case eResourceType::RESOURCE_FILE_TYPE_CONFIG: | ||
case eResourceType::RESOURCE_FILE_TYPE_CLIENT_CONFIG: | ||
m_resourceCategoryType = eResourceCategory::CONFIGS; | ||
case eResourceType::RESOURCE_FILE_TYPE_CLIENT_FILE: | ||
case eResourceType::RESOURCE_FILE_TYPE_HTML: | ||
m_resourceCategoryType = eResourceCategory::FILES; | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can filter it in CLuaResourceDefs::GetResourceFiles
. You don't need GetResourceCategoryType
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Its better this way
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm. You can use original types. I think client-scripts
and server-scripts
have some sense for developers. So you shouldn't map eResourceType
into custom enum for one Lua function
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd have to do string manipulation in both functions just to get values.
Its better that way
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you mean?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is wrong with eResourceType
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
too much noise
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like using existing enum is much better than creating a new one with mapping from eResourceType
and adding boilerplate code in client and server.
too much noise
What do you mean?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you mean?
Exactly what I said. Its easier to have 3 categories: scripts, maps, files instead of: client/server scripts, client/server files, (client/server?) maps, etc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see no problem here. It's much useful.
Does it return shared scripts twice here? Is it expected behavior? local list = getResourceFiles("all") |
File paths returned shouldn't be repeated imo |
To make this more advanced, the list returned could be a table of {filePath, fileType} where fileType is like "client-script" or "shared-script" or "map-file" idk |
if (file->GetResourceCategoryType() != type.value() && type.value() != eResourceCategory::ALL) | ||
continue; | ||
files.insert(file->GetName()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Previous varian was more readable. Why did you change it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
previous variant was basically the same.
This leaves room for more conditions to come.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is no 'early continue' rule. You obfuscate the code with overusing 'continue' in loops. And you don't really need to use early return for small code blocks.
You did the code less readable and maintainable.
if (file->GetResourceCategoryType() == type.value() || type.value() == eResourceCategory::ALL)
files.insert(file->GetName());
Is fine condition, that describes the function logic.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is early-return which is basically the same but whatever.
I'd rather go with continue rather than indentation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Your continue
creates indentation too. Please, keep it simple
There is early-return which is basically the same but whatever.
Not really. Multiple 'continue' conditions can make a loop harder for reading.
There is no goal to use minimal indentation. The code should primarily describe the logic.
You're overusing 'early return'
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Again?
No one was interested in this convo for 2 weeks, give it a break.
No contributors were opposed against this so Im leaving it as it is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I also see the early return overuse here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No contributors were opposed against this so Im leaving it as it is.
And nobody confirm your position. Don't hide requested changes. Stale conversations should be dismissed by another members.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And nobody confirm your position
Im following the guidelines is'all.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you interpreter these guidelines very differently
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ready to merge imo
@TracerDS it would be nice to have a way to know if a file has download="false" attribute, so it can be downloaded using downloadFile later |
Any ideas? |
maybe a parameter that checks download="false"? |
Resource files, when they are parsed in the meta.xml, are already identified if they need to be downloaded later by the client. |
It's a matter of returning that download attribute value for each file. The array of file names returned by this new function should contain arrays where you have like |
I think it would be better to return just an array of files and handle the download attribute via a parameter. It would be better for the end user |
True, but what parameter exactly? |
Something like isDownloaded or something like that. Or maybe it will receive a table of flags if more param were to come |
getResourceFiles
will return names of all files loaded by a resource