You call that small? My C drive is 40gb :saddowns:
Printable View
Yeah since even the crappiest computers from wal-mart usually have atleast 250gb nowadays.
My 2nd drive only has 30gb oh well!
While I agree that OS would benefit both CMT, and the rest of the community, I feel that Masterz has his reasons for not using it.
Sure, he may be helping the pirates by allowing the 1.00 and 1.04 community (Which currently has the most user base on HCE), however they might "turn over" if CMT were released under 1.08, and Open Sauce.
However, there is a 50 percent chance that people WON'T buy Halo, and will scourge the internet either by posting on forums:
Or by searching with Google (Like that'll ever happen, considering most of the internet newbies never search.)Quote:
hai guyz CMT just releazed tehir new campain, any1 got a cd key??//?
As always, CMT, and the community, would benefit from having this Open Sauce update. However new problems might occur.
1. What happens if a modder makes one set of bitmaps.map and sounds.map, and then he creates another set that uses a couple different bitmaps and sounds. This might result in creating two of the same, which could waste space on a hard drive. A fix would be to create only one of each, then dump everything that is only bitmaps and sounds, into those two files.
2. OS_Tool, as gracious as it may be, since it is made with the "stable but unstable" Open Sauce, it could damage the structure of the map file itself, causing errors all around. Of course I am not doubting Kornman, but it could happen.
Edit: What I said in #2 would probably apply to a "newcommer" in the Halo CE enviroment.
Worrying about pirates is nothing. They know they pirated it, and they won't openly ask for a key. You usually have those who don't know how to pirate asking for keys.
I'm not exactly sure what you mean by your bitmaps/sounds.map scenario. But if I understand it correctly, why would anyone ever do that? If you want to have two sets, compile them into the same, or just don't reference it as a shared resource and compile that in the map. Shared caches are meant for things that are universal across all maps, such as bitmaps, sounds, music, weapons, vehicles, and UI elements. And regardless, you'll always have a scenario that is either the same size as it would normally be or smaller.
OS could be unstable depending on what you do and who does it. I don't want to speak for Kornman here, but I would assume that something like this is pretty damn stable as long as you use it right. Not really sure how it can screw up and go so wrong when it's just compiling like normal, but splitting resources between two files.
I don't understand what you are trying to say. Can you elaborate?
I don't see how Open Sauce could damage the structure of a map file. Nothing is really being changed in the map files. A particular tag will still have a value that specifies if the bitmap or sound is external, OS is just going to change which map the engine will load the tags from.
A "newcomer" to CE should have enough common sense to be able to read a readme and follow instructions on how to install OS and make the maps playable.
I still don't understand what you meant before, but an inexperienced modder should not, and probably would not be using the shared map file feature of OS.
I highly doubt an "inexperienced" coder will be able to figure out what OS is doing, let alone edit something major and still get it to compile. If somebody released an edited OS source code, there is no doubt that it won't be as stable as something Korn would write. It's not like a person who has no knowledge coding is going to be writing this shared map file code for OS, so I don't see what the problem is. If a person edits OS's source code, and fucking something up to where it becomes "unstable", then it's their fault, and it's not like people are going to be forced to use that.
And about me, I don't have any C++ experience, though I do have a little bit of C now, so that restricts me a lot when trying to look at OS and figure out what the hell it's doing. I can understand parts of it, but I really haven't had much time to sit down and thoroughly look at it. I plan on looking at it again sometime soon hopefully.
While OS_Tool (along with OS_Guerilla and OS_Sapien) are part of the "Open Sauce" package, they are not being compiled from the same code base as the Yelo portion of OS. The only open source part of OS currently is Yelo, and it has a license which requires any changes made to the source to be published\made avaiable. The changes I'm making in terms of upgrading the memory are going to be required to be part of the base Yelo framework so its there in all Yelo deviations and thus doesn't introduce versioning conflicts.
The shared data files system in OS_Tool works based on the the "mod" concept. There are currently two new commands added to tool, one of them being a variant 'build-cache-file'. The user specifies the "mod" name, the scenario being built and if the cache requires the memory upgrades. From here, the stock data files are copied and renamed into the "data_files" folder, which is a child folder in "maps".
For example, for h2ce: "maps\data_files\h2ce-bitmaps.map".
Since the mod's data files are based around the stock data files, original maps made prior to OS will still play just fine without any special un\loading during game play. I'm only recommending that custom shared data files be used for campaign mods.
Since OS_Tool is based around tool's code, there shouldn't be any instability except what of which was already there. The option to build a regular cache file a la "tool.exe" is still there along with all original commands.
Another option I'm considering allowing is a globals tag override, so you can easily use different globals for different scenarios. Plus I have a few other ideas up my sleeve, one of which some of you scripters may particuarlly like.
Current memory upgrade testing is based around a 50% increase in maximum tag instances and tag memory, and with a maximum cache size of 512MB (any cache type, even UI). This may change come release.
I tried making Yelo decently stable, but it still has its issues (especially when you don't grasp whats being executed, lack of documentation aside), like the statistics code which causes a crash when killing an AI unit. I should have this fixed in the next Yelo release as I wasn't testing on any AI maps when I originally created the code (after all, CE is suppose to be MP only :downs:). It could be worse; only two people actually test it internally (down to one since bitter isn't active)
I would test it in bitter's place, but I know what your going to say already.
lmao. Are you serious Jcap? Our answer is no.
So you're not using OS? Lmao