-
Notifications
You must be signed in to change notification settings - Fork 41
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
replace u_scanner with DECORATE compatible version #2090
Conversation
ef1027b
to
a320f7a
Compare
@@ -64,6 +64,7 @@ set(WOOF_SOURCES | |||
m_input.c m_input.h | |||
m_io.c m_io.h | |||
m_json.c m_json.h | |||
m_scanner.c m_scanner.h |
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.
Please update README.md as well.
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.
Done in fb64425
But this is due to another update to the WAD files, and not related to the parser changes proposed here, right? |
Yes, it's not related to this PR, I'm just starting to refactor UMAPINFO a bit more locally. I think we should remove the whole UMAPDEF system at this point: popular versions of nerve.wad and masterlevels.wad now have proper UMAPINFO, also we have the woof.pk3 system now, so load order is not such a problem. |
Alright, please proceed. |
Preparation for MBF25 DECORATE implementation, which requires more sophisticated scanner. Adapted from https://bitbucket.org/Blzut3/declarate/src/master/src/scanner.cpp
The KEX port's
masterlevels.wad
has a different map order than ourbase/masterlevels.wad/umapdef.lmp
. Should we remove all UMAPDEF at this point?