EagleEye

From what I remember, WW regretted putting Kane in the Soviet ending (because they didn't really know what to do with him), but it was EA who retconned it to where RA and TD have nothing to do with each other, and used that as justification for making Generals.

It means "a lot" in this context, though it actually means "God's wounds", according to Merriam-Webster.

I got it. I haven't sent you a message yet because I haven't gotten far enough on the disassembler to need to ask you for help yet. I sort of want this to be a $20 alternative to IDA (the $519 dollar difference and the ability to output FASM compatible files making up for the comparatively severely limited functionality), but it's not likely seeing as, well, I'm been really depressed lately and that's the kind of thing that kills all the projects you work on. Edit: I'm sorry, ccso.com, but you don't get to put us-flag.gif next to a QR code. You have to pick a decade. Also, price gouging. I feel sorry for any hobbyist who's ever had to shell out any money for IDA. Especially since two people with different versions of IDA can't collaborate, and updating = $$$.

I was working on a map editor before, but I couldn't parse the .SHPs correctly because I'm an idiot. If someone could write some (MIT-licensed) code to convert a SHP into a List<int[,]> or List<int[][]>, then I could probably write the rest of the map editor. Everything else should be easy enough, but you need to be able to see the map in order to make sure you're loading it correctly. I'm thinking of making the map editor feel like the game, with a sidebar on the right side, clicking on the logo changes what side is selected (a side without a logo will display GDI's frame for showing the radar, with the side's name), and clicking the "Sidebar" button switches from units/buildings to ground to terrain, the middle of which will be used for the icon (with Solid/Water/Shore/Clear being the "names") and a mouseover will show the full ground in the radar. It's hard to explain, but if I get some time, I'll make a mockup of the UI.

Then you better go catch them!

Could you post how the .bin file works in this thread (for reference purposes)?

There's no public place that I'm aware of, but Hyper will surely send you his database and any documentation he has, though I'm not sure he has any proper documentation. I know for a fact Nyer doesn't, but I've never really talked with Hyper that much.

By "disassembly", I meant "reassemblable disassembly". Something that you can turn into an .exe with an assembler. I'm saying that with people like you and Hyper around, Command and Conquer is much more likely to get a reassemblable disassembly than, say, Lego Island or Ultima 9. Though that's still not likely, since you guys have been working around not having a way to reassemble for years now.

5 hours? Wow, the longest I've ever had to wait for something to compile was a little under an hour, and I've got a dual core 1.6GHz AMD processor that can't even play Unreal 3 games.

The square root problem could be worked around by making a function like this: int SquareRoot(int input) { switch(input) { // case 4096: // return 64; case 16384: return 128; case 65535: return 256; default: return 64; } } (Or you could look up an x86 assembler with a Math library. I've used one when I was trying to make a CnC disassembly.) About the "initialized at start" thing: if you change MapBuffer[4096] to MapBuffer[65535], does the game change at all? Though changing every mention of 64 in the context of MapLength to a reference to a variable, both in finding and repointing, sounds like it'd be a huge PITA. A disassembly would make it a lot easier, but someone would need to make a disassembly first (Though if there was ever a PC game with a community that could make a disassembly of it, I'd say it's Command and Conquer. 1.06, Ares, Arda, OpenDune. Not to mention the various Assembly-hackers here and at PPM/RenX.). Edit: And it works. I have no clue how easy it'd be to implement in ASM, but all a square root needs is addition, subtraction, and a while loop (I have no clue how a while loop works in ASM). Also, I learned 65535 isn't a square root (I'm a moron sometimes). using System; namespace SquareRoot { class Program { static void Main(string[] args) { Console.WriteLine("4096: " + SquareRoot(4096)); //64 Console.WriteLine("16384: " + SquareRoot(16384)); //128 Console.WriteLine("65536: " + SquareRoot(65536)); //256 Console.WriteLine("262144: " + SquareRoot(262144)); //512 Console.WriteLine("1048576: " + SquareRoot(1048576)); //1024 Console.WriteLine("65535: " + SquareRoot(65535)); //0 Console.WriteLine("65535: " + Math.Sqrt(65535)); //255.998046867549 Console.ReadLine(); } static int SquareRoot(int input) { int tosubtract = 1; int subtracted = 0; while (input > 0) { input -= tosubtract; subtracted++; tosubtract += 2; } if (input < 0) { //throw (new Exception("Internal Error: Not a Square Root")); return 0; } return subtracted; } } }

Argh, I want to say "just make a variable that defaults to 64 that controls the width and height of the internal map, and set it to the square root of half the size of the .bin file", but I know you'd already be doing that if it were as easy in ASM as: int internalsize = Math.Sqrt(mapfile.Length/2); byte[] map = new byte[internalsize*internalsize]; //etc... Use internalsize in place of hardcoded 64 It's times like this I wish I could understand x86 ASM better.

I PMed EA_CIRE and asked him how I would ask EA for official permission to distribute Dune 2000. If he sends me a reply either way, I'll post it here. EDIT: He's looking into it.

Okay.

I was wondering what the community's position on distributing Dune 2000 was. Abandonia says it's Abandonware (and that Emperor is protected by EA until 2017), but Abandonia isn't a CnC site, so I have no clue if that's how the CnC community feels about it.

I'd already ported it to C# again my the time I read your post. I also did a speed check on both versions and both take 0 ticks to complete. I'm going with your port, though, because I trust XCC Utilities more than a defunct CnC remake.

Sorry to triple post, but does anyone know where I can find some documentation on the .AUD file format? All I could find is how to extract audio from non-death-scream .AUD files. Edit: I'm just going to leave this here so I never have to write this again: static public uint GetID(string filename) { if(filename.Length > 12) { throw new Exception("\"filename\" " + filename + " must not exceed 12 characters in length."); } //Prepare filename filename = filename.PadRight(12, '\0').ToUpperInvariant(); //Compute ID uint id = 0; foreach(int i in new List<int>() {0, 4, 8}) { if(filename[i] != '\0') { //Rotate 1 bit to the left id = ((id<<1) | ((id>>31) & 1)); //Add the new value id += BitConverter.ToUInt32(new byte[] { (byte)filename[i], (byte)filename[i + 1], (byte)filename[i + 2], (byte)filename[i + 3] }, 0); } else { break; } } //Truncate to 32 bits id &= 0xFFFFFFFF; return id; } Here's a random thing of notes I have, if anyone's interested. It's mainly just other documents people wrote compiled into a file. You probably don't need Office OneNote: https://skydrive.live.com/edit.aspx/.Documents/Tiberian%20Dawn%20Notes?cid=c5d06616ef6a6457&sc=documents?& E: I looked into the SHP file format. °?°

Um. I changed my computer's font size, and when I let it log me off automatically, it crashed, and I couldn't get it to boot up Windows proper again without crashing before the login screen. Long story short, I didn't have a backup disk for Windows 7, but eMachines has a recovery partition, so I came out unscathed. Unfortunately, I forgot to backup my code. I am a dumbass. Luck thing I hadn't done anything other than implement .MIX and .PAK files, right? Edit: Damn it. I'm going to have to port the .MIX ComputeID method to C# again. E: Unless I can make a simple Visual Basic application with the function, then use dotPeek to see how it looks in C#. Another thing for me to redownload.

I never expected that getting the offsets would be so hard. I wrote a utility that prints out where the first .INI file's stated offset (SCB22EB.INI at 0x2F65), then I searched for "; Scenario", which is first found at 0xA9CE12. Thing is, SCB22EB is Deceit, which starts with "; Scenario 31 control for house BadGuy.", while this file, unnamed, starts with "; Scenario 1 control for house BadGuy.". Anyway, I subtract 0x2F65 from 0xA9CE12 and get 0xA99EAD, which doesn't appear to have a single null (0x00) anywhere in the vicinity (the closest one downwards is 0x608 bytes away; don't know why I checked that). So I'm utterly confused by however Looking Glass did this. Hell, considering the 0xE178DD (14,776,541) empty bytes (~14 megabytes) at the end of the ROM, and that uncompressed, all the files are 12,144,460 bytes (~11.5 megabytes), I'm starting to think Looking Glass Studios got broken into one night by a Westwood Studios programmer. Also, I can't find a potential variable that's always smaller than the uncompressed file size, meaning it's quite possible that some (read: a lot of) files take up more space compressed than uncompressed. TL;DR: Fired. Out a cannon. Into the sun.

Wow, that algorithm sounds horrible. Then again, it was programmed by Westwood, and it's been established that their programming is half as bad as their games are good.

Does anyone know how to get the offset of the compressed files inside the C&C64 ROM? I know how to get the uncompressed file size, and how to get the filename, but not much else so far. If I could figure out how to get the compressed version, I may be able to figure out what the compression method Looking Glass used, and consequentially how to reinsert files. You can find an extracted version of the file listing here in both it's unaltered binary format and a text format here.

TibDawn doesn't use .PAK files. I just felt like messing with Dune 2 for a little bit. Essentially, .MIX files list how many records there are, and all records are the same size, making getting a listing of the files in a .MIX easy. .PAK files don't say how many records are in them, and are terminated by 4 0x00s following the last record (which is terminated with an 0x00, meaning there are 5 consecutive 0x00s). In practice, that means I need to loop through the file until I come across a file at offset 0, then break and load the files. Note, though, that while a .MIX says how long a files is, a .PAK doesn't, requiring subtracting the offset from the next entry's offset (or the file length). Long story short, .MIX files are a lot more intuitive than .PAK files, though truth be told neither are a hard format to support. P.S. Thanks for reminding me about that. I need to remember to check the folder, then the .MIXs in the folder, then the CD, and to stop whenever I find one of those.

Wait, is it "sc*.mix" or "sc-*.mix"? If it's "sc*.mix", that means it also loads "scores.mix". E: Also, wouldn't Language be loaded before BaseLanguage? E: While I'm messing with initialization code, I might as well mess with loading form disk (at some point I'm going to need to do a non-NoCD minimal install of Gold, so I can compare what files are used). As far as TD goes, what are the CD labels? Worldwide Warfare uses "GDI95", "NOD95", and "COVERT". Do different releases or languages have different labels. P.S. Does anyone have a scan of the N64 manual? If not, I might scan mine in. E: Messing with loading .PAK files. While I had a lot of trouble converting Mix computation to C#, loading the .MIX files themselves was easy as pie. .PAK files suck, and I can see why they switched to the ID computation system.

Thanks. By the way, does CCConfig use an .INI reading library, or did you write your own functions to modify the .INIs? E: Also, if ModName is left blank, would it load a file named ".mix", or would it skip loading a [modname].mix?

Thanks, Nyerguds. That was exactly what I needed. P.S. I am an idiot. ((63+1)*4)-1 = 255 Q.E.D. No clue if that's what XCC uses, but a difference of 4 shouldn't be too bad if I'm wrong.

I'm probably never going to need to touch the .mix loading code again, actually. My problem now is converting the .PAL palettes from 0-63 to 0-255. Though I have the source code to XCC Utilities on my hard drive, so I can just look at those.