I'm getting these two errors when compiling:
SFmpq_MT.lib(SFmpqapi.obj) : error LNK2001: unresolved external symbol _sscanf
SFmpq_MT.lib(SFmpqapi.obj) : error LNK2001: unresolved external symbol _sprintf

IIRC those two functions are Microsoft's "secure" versions of printf and scanf, i.e. with some memory safety considerations included in them. I think you'll need a Visual Studio C++ compiler to help that.

I am using Visual Studio(2015)

I've began moving the project to vs2015, in the meantime you can use these updated SFmpq compiles (place in Source Files/Mapping Core) http://puu.sh/jBK1q/50b3ce2d06.zip.

Finished moving over to vs2015, pushed to github.

Update 2015-11-07 - Download Latest



Feature changes:
    - Trig conditions (with the exception of memory and custom) completed.
    - More functionality is only shown in advanced mode for triggers.
    - Chkdraft now supports adding a password/login to your map, (note that your password itself is not stored, rather the first 7 bytes of a sha256 hash of your password is stored).
    - LIT can now be run from under the tools menu
    - Chkdraft now expects a subfolder ("chkd") to be found next to itself/in it's working directory; at the moment this just stores LIT but will house configurations/backups/state-saves/additional plugins in the future.

Bug/Error fixes:
    - Fixed a text trig bug where entering less than the actual amount of arguments could cause a crash

Code changes:
    - Banishing manual linked lists: any lists that were wrote in using manual linking/allocation have been replaced with the appropriate stl containers.
    - Undos system rewrite: undos are now stored as "Reversible" objects, these objects must store the data and write the procedures for themselves to be reversed, they should also return a unique nonzero type if they are to be included in the change tracker. the UNDOS class itself is quite generic, storing reversibles and keeping track of how many changes of unique types have been done; change and all-changes-undone events can be observed using the IObserveUndos interface.
    - Map parser rewrite: much more robust, now accounts for various nuances like jump sections and trailing incomplete sections.
    - Scenario reorganization: grouping together functions that affect similar sections/layers.
    - Renamed several scenario structures to ChkNAMEHERE.
    - Removed several defines in favor of enumerations.
    - Project filter reorganization, extra collapse '*' added for files that don't fit neatly into sub-folders, when sub-folders exist; MAPS and GuiMap moved too Main Windows. Mapping Core and WindowsUI each moved up one filter directory.
    - Separated Dialogs and MDIClients into their own classes and have ClassWindows, ClassDialogs, WindowControls, WindowsMenu and MDIClient inherit from WindowsItem.
    - Moved WM_COMMAND and WM_NOTIFY to dedicated functions for all ClassWindows/ClassDialogs.
    - More stuff that I can't recall.

Is storing only 7 bytes of a SHA256 hash a limitation or something? I'm pretty sure doing so is insecure, but if it can't be avoided, oh well.

It's just simpler, not a hard limitation or anything.

It's certainly weaker than comparing against the full hash; however the point of using the hash was to prevent peoples passwords from being stolen from the map, not to provide additional security for the map (which given unprotectors & open source chkdraft is astoundingly vulnerable no matter what you do). 7 bytes has 72,057,594,037,927,936 possible values, so even if SHA256 does a terrible job and barely scrambles it's first couple bytes you'll still have tons of brute force work to do (at least a few million strings, assuming the user didn't make their password too short & simple) if someone was so incline to take that silly route to unprotecting a map.



Post has been edited 1 time(s), last time on Nov 8 2015, 12:46 am by jjf28.

Is the password/login for opening the map in CHKDraft? How easy is it to just edit the map to swap out the stored hash/whatever?

litPath: C:\Users\Randy\Desktop\Starcraft\maps\BroodWar\Cecil's\chkd\Tools\LIT\bin\LIT.exe
luaPath: C:\Users\Randy\Desktop\MyProjects\LIT\ALTTP.lua
workingDir: C:\Users\Randy\Desktop\Starcraft\maps\BroodWar\Cecil's\chkd\Tools\LIT\bin\

The above output is made when I open a map in: C:\Users\Randy\Desktop\Starcraft\maps\BroodWar\Cecil's\.

litPath is incorrect. litPath seems to be set to wherever the path is of the map last opened, and then chkdraft appends "chkd\Tools\LIT\bin\LIT.exe" to the end of this. Seems like a GetCurrentDirectory bug. Before you open a map save chkdraft's directory in a string and store that somewhere, maybe as a global. Then you can restore the working directory whenever you like with: SetCurrentDirectory.

https://msdn.microsoft.com/en-us/library/windows/desktop/aa365530(v=vs.85).aspx

If I place my map in C:\Users\Randy\Desktop\Starcraft\Chkdraft\Chkdraft\, then I get this correct output:

litPath: C:\Users\Randy\Desktop\Starcraft\Chkdraft\Chkdraft\chkd\Tools\LIT\bin\LIT.exe
luaPath: C:\Users\Randy\Desktop\MyProjects\LIT\ALTTP.lua
workingDir: C:\Users\Randy\Desktop\Starcraft\Chkdraft\Chkdraft\chkd\Tools\LIT\bin\

It's trivial for someone who knows what their doing to remove it; I'd rather not discuss the exact details publicly.

I didn't mean how like the core functionality works, I just meant it sounds like it is trivial to remove it or bypass it based on the nature of maps/mpqs/chks.

Why do we need passwords on maps? Are people still trying to put limits on other people's growth by learning how they did something? Not a pretentious point where I've already assumed the conclusion, I'm genuinely curious as to what the reasoning behind this is.

From my understanding map protection had nothing to do with limiting people's growth. It was an attempt to stop map thieves.

To fully secure maps by password, you should at least use it to encrypt full chk.
( Store the encrypted version in scenario.pwd or some other MPQ file? )

Really, Chkdraft is open source.
Simple "Find Usage..." command reveals how password system works.

Maps with a password can be fully viewed by Chkdraft, only copy-paste and save are disabled.


That removes StarCraft's ability to read the map, defeating the purpose of protection (preventing trivial thievery/edits over bnet). There are much better encryption methods out there if you want to fully lock up a map.


Yep, but the purpose isn't to protect a map from those who are willing to do a little research, anyone can go ahead and download an unprotector, I have no desire to fight a war that's already lost.

Please refer to this topic to discuss protection in general.

Post has been edited 2 time(s), last time on Nov 8 2015, 2:13 pm by jjf28.

Thanks for the clarification.

Update 2015-11-08 - Download Latest

Bug/Error fixes:
- Fixed a bug where saving as type "All Maps" without specifying an extension would result in a .scx with hybrid version information, aka a map StarCraft will reject.
- LIT now greyed on the menu when no map is open
- Fixed a bug where deleting a unit causes a crash

https://msdn.microsoft.com/en-us/library/windows/desktop/bb762153(v=vs.85).aspx
https://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/redirection.mspx?mfr=true

I tested LIT with your newest version, seems like the command line is slightly off now. I did change the command line a little bit, but I can't recall the differences from last time we spoke. Link to LIT here. I put everything in one folder (can't believe I had things in different folder before, well, I did stay up really late that day ), instead of in bin and src. That might have caused something in our integration to break.

Here's the current format:



And here's an example in case seeing an example helps:



Post has been edited 4 time(s), last time on Nov 9 2015, 12:36 pm by CecilSunkure.

Update 2015-11-10 - Download Latest

- Updated to work with the latest version of LIT