That's a shame. I wasn't talking about moving data between mods but importing/exporting data outside of SC2. There is no way to interface between a mod and an external 3rd party tool. The only way is via the edit box which is broken, and bank files, but finding and modifying an xml file on their computer is beyond most peoples ability.
If you only want the output, you can use debug feature, would allows you output debug messages as files. (Last time I check you can use relatve path to modify their location, '.' and '..' are supported)
interesting, i havent had any issue when it comes to svn merging gamedata files.
Explain how you can merge the .version and terrain files? It works well for triggers and data but not for terrain and metadata currently as those are binary files.
Quote:
That's a shame. I wasn't talking about moving data between mods but importing/exporting data outside of SC2. There is no way to interface between a mod and an external 3rd party tool. The only way is via the edit box which is broken, and bank files, but finding and modifying an xml file on their computer is beyond most peoples ability.
Doing this safely is a big problem. You cannot except to run anything on a client's system because that is a massive security risk (hackers will waste no time writing malware).
The best they could do is communicating with a remote third party server. The game client is responsible for reading and writing the data but the data is sent to and comes from a remote server. This is secure because all incoming data is treated as data and all out going data can only originate from inside SC2. The server itself runs "unsecure" software but all security risks are then that of the third party who owns it and not Blizzards problem. At most they need to make players aware not to give out personal details through maps as they do not store the data.
the edit box already works, it just breaks after 256 characters. If the limit was extended to 1024 characters then this does not open up any attack vectors which did not already exist. (it already scrubs the input, only alphanumeric characters get parsed, all others get erased)
Or if SC2 was able to read a plain text file character by character instead of through using the key/section xml reader it currently does. If there is the possibility to make it overflow and corrupt further data or inject code into the code section of memory then this capability would already exist in the current form through banks.
There's no way to read in text which the game will excecute as code, but if there were then that means that anything it could exploit could already be exploited by a malicous map maker making a map which has a virus in it.
to be honest i dont really see any real need over merging terrain files. rarely yyou would have two terrain artists working on the same map at the same time. so when a conflict arises over them i simply set them to resolve using the terrainers version. and frankly i havent had any need to worry about the .version files.
I will see about adding the remaining stuff from categories tonight and tomorrow. There is also more stuff I've discovered in other files, but will create another thread for that.
Edit: Added some more stuff in. Behaviors and Effects. Both are very powerful now.
Yes, I'll detail those in a separate thread. I discovered more by examining the galaxy header files. There are about 6 more siteops and 3 or 4 new actors entirely. You will like many of them.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
If you only want the output, you can use debug feature, would allows you output debug messages as files. (Last time I check you can use relatve path to modify their location, '.' and '..' are supported)
The sc2 is unable to 'read' these files though.
Explain how you can merge the .version and terrain files? It works well for triggers and data but not for terrain and metadata currently as those are binary files.
Doing this safely is a big problem. You cannot except to run anything on a client's system because that is a massive security risk (hackers will waste no time writing malware).
The best they could do is communicating with a remote third party server. The game client is responsible for reading and writing the data but the data is sent to and comes from a remote server. This is secure because all incoming data is treated as data and all out going data can only originate from inside SC2. The server itself runs "unsecure" software but all security risks are then that of the third party who owns it and not Blizzards problem. At most they need to make players aware not to give out personal details through maps as they do not store the data.
If that's a security risk then it already exists.
the edit box already works, it just breaks after 256 characters. If the limit was extended to 1024 characters then this does not open up any attack vectors which did not already exist. (it already scrubs the input, only alphanumeric characters get parsed, all others get erased)
Or if SC2 was able to read a plain text file character by character instead of through using the key/section xml reader it currently does. If there is the possibility to make it overflow and corrupt further data or inject code into the code section of memory then this capability would already exist in the current form through banks.
There's no way to read in text which the game will excecute as code, but if there were then that means that anything it could exploit could already be exploited by a malicous map maker making a map which has a virus in it.
@ImperialGood: Go
to be honest i dont really see any real need over merging terrain files. rarely yyou would have two terrain artists working on the same map at the same time. so when a conflict arises over them i simply set them to resolve using the terrainers version. and frankly i havent had any need to worry about the .version files.
Go play Antioch Chronicles Remastered!
Also, coming soon, Antioch Episode 3: Thoughts in Chaos!
Dont like mapster's ugly white? Try Mapster's Classic Skin!
I will see about adding the remaining stuff from categories tonight and tomorrow. There is also more stuff I've discovered in other files, but will create another thread for that.
Edit: Added some more stuff in. Behaviors and Effects. Both are very powerful now.
any aditions to actor system? Maybe some new SOps?
@abvdzh: Go
Yes, I'll detail those in a separate thread. I discovered more by examining the galaxy header files. There are about 6 more siteops and 3 or 4 new actors entirely. You will like many of them.