| 04-06-2010, 12:12 PM | #1 |
This is a native pack for RtC which includes 3 plugins: FileAPI -- a secure FIle I/O system which allows Warcraft 3 to have access to files outside of the map itself. OptimizeAPI -- an attempt to optimise some of the useful BJ functions, which are not often used because they "waste a function call". WindowAPI -- a way of accessing various properties of the Warcraft 3 window. The current natives are: JASS://============================================================================ // OptimiseAPI // // for reals native NpRMax takes real a, real b returns real native NpRMin takes real a, real b returns real native NpRAbs takes real r returns real native NpModuloReal takes real dividend, real divisor returns real // for integers native NpIMax takes integer a, integer b returns integer native NpIMin takes integer a, integer b returns integer native NpIAbs takes integer r returns integer native NpModuloInteger takes integer dividend, integer divisor returns integer //============================================================================ // WindowAPI // native NpGetWindowWidth takes nothing returns integer native NpGetWindowHeight takes nothing returns integer native NpMinimizeWindow takes nothing returns boolean //============================================================================ // FileAPI // // you'll find all your saved files in the "Warcraft/SavedData" directory, where // "Warcraft" indicates the directory where Warcraft 3 is installed // note that you cannot open more than 32 different files in one instance of a map // opens a file and returns a file id used to access the file later -- if append // is true, when writing to the file, data will be added at the end, rather than // overwriting the original contents -- you cannot open files larger than 1 mb // or 1048576 bytes -- this function will build all directories for you and create // the file if you specify a file that doesn't exist // Note: you cannot specify an absolute path ("C:/...") for safety reasons native FileOpen takes string filename, boolean append returns integer // closes the file, returns false if it doesn't exist, true on success native FileClose takes integer fileid returns boolean // returns the size of the specified file in bytes -- can be used to check if you're // near the limit for WriteFile -- a return value of -1 means something went wrong native FileGetSize takes integer fileid returns integer // writes the given string to the file, returns false on failure, true on success // the maximum amount of data a file written like this can contain is 1 mb or 1048576 // bytes, for safety reasons native FileWrite takes integer fileid, string toWrite returns boolean // writes a string followed by an end line to the file -- the file size cap still // applies -- not much different from WriteFile with a "\n" escape character at // the end of the toWrite string native FileWriteLine takes integer fileid, string toWrite returns boolean // reads the specified number of characters from the file, stopping when it encounters // the first character of the string stopAtChar -- returns "ReadFile_ERROR" on failure native FileReadEx takes integer fileid, integer maxChars, string stopAtChar returns boolean // the same as FileReadEx except it does not specify a character to stop at native FileRead takes integer fileid, integer maxChars returns string // the same as FileReadEx except the stopAtChar is '\n' (newline) native FileReadLine takes integer fileid, integer maxChars returns string Remember: I need suggestions / requests! PS: If anyone can think of a better name, it would be welcome. |
| 04-07-2010, 02:40 PM | #2 |
prefixes are evil. RAbs is likely faster as R2I() (Ints can be used in real expressions) |
| 04-07-2010, 03:12 PM | #3 | |
What should I do other than prefixes? Allow it to collide with everything? Quote:
EDIT: Updated, added some file i/o that was requested on the hive. |
| 04-07-2010, 03:22 PM | #4 |
These natives could easily be malicious. You should make a filesize limit on the files that are being written to. |
| 04-07-2010, 04:49 PM | #5 |
You can't run an exe file with this, even if you make a virus, so I don't see what you mean... |
| 04-07-2010, 05:22 PM | #6 |
You could make a HUGE file. And.. remove the prefixes on the I/O functions. |
| 04-07-2010, 05:55 PM | #7 |
Id say anything over 1mb is over-kill for a file. Maybe have a limit to the number of specific files a person can modify? 255 seems extremely large. something like 16 or 32 would be better. Also, I think the natives would work best if they read line-by-line and save line-by-line. Can the files be created anywhere, or only relative to war3.exe? If anywhere, you have a problem with people modifying other files (firewalls, windows, etc) which could cause complications. |
| 04-07-2010, 06:23 PM | #8 | |||
Ok, it seems I have a lot of work to do... Quote:
Quote:
Quote:
I'll get on it later, maybe tomorrow, but right now I'm in the middle of something else. For now I suppose I'll remove those natives... |
| 04-07-2010, 06:40 PM | #9 | ||
Quote:
If I open a file, write the max size, close the file. open a new file, write the max size, close the file. open a new file... etc. You could rape someones HD. Limiting the number of specific files a map can open would be the best bet. Quote:
I'm thinking about saving data over maps (not using gamecache). You would want each bit of data on its own line, instead of jumbled together. C++ has getLine() and endl for reading and writing to multiple lines, so even if you made natives that read line by line and wrote line by line (keeping the bulk ones there) would be handy. |
| 04-07-2010, 07:27 PM | #10 | ||
Quote:
Quote:
|
| 04-07-2010, 07:32 PM | #11 |
I would use a static array of all the files that have been openned, adding new files to the array. When there are no more spots left in the array, return an error. Hmm, right, gamecache... |
| 04-07-2010, 07:38 PM | #12 | ||
Quote:
Quote:
|
| 04-07-2010, 10:45 PM | #13 |
I wouldn't limit the total number of files, but the number of unique files a map can access per game. Sure, a map maker can have there map generate 32 random files of 1 mb per game, but it would take a lot longer to fill someone's HD. So ya, a limit per game. Not at all. Gamecache can't be modified outside of wc3 easily, while a file can. You could use a program to upload the files created by a map to a server and easily keep track of data this way. As well as being able to download new data, and have the map load it. |
| 04-07-2010, 11:43 PM | #14 |
Yeah, that makes it much easier. To be honest I think a limit of 32 is way higher than anyone would need, but then agaib some maps might want to load large amounts of data. I know nothing I'll ever do will amount to even 1 mb of memory... Wow, I made the thing and I couldn't think of any uses for it, but now you've convinced me not to give it up. Thanks. Todo list so far:
|
| 04-08-2010, 06:22 PM | #15 |
Big Update: The file system is back, and fully secure (I think). Here's what I've done:
|
