Blade

Currently Vanilla Conquer would provide portability to other operating systems as well as options that would be very difficult to implement with binary hacks such as mega map support. The fact that its source code rather that assembly hacks makes additional changes easier to implement. Infact I've made a start adding rules.ini support so making some changes won't even involve source code changes in the future. Downsides? The save format isn't stable yet, network multiplayer isn't implemented yet and someone would need to implement any hacks to the original binary into vanilla conquer assuming they are within scope for what the project wants to achieve, otherwise they would need to be implemented in a fork supporting the mod. Given that Vanilla Conquer can also build as a remaster dll, it would also give the possibility to implement the mod in the remaster as well for those that have it giving exposure via the steam workshop.

I did work on this with CCHyper and it feels like it was a lot harder than it should have been. The format it expects is the same as the one Sole Survivor used and the internal map editor will now write that format. The max size is now 128x128 like RA and if you build a TiberianDawn.dll remaster mod from the vanilla conquer source (which supports building both a classic standalone binary and a remaster mod dll), the remaster will also support 128x128 maps. Caveats are that this changes the save format and the save format isn't even stable at the moment as we are making lots of changes to commonise the code with the RA code. Also multiplayer doesn't work in vanilla yet for either game standalone.

I don't see anything here that couldn't be faked using Chronoshift code and some modding, but lets assume you have the genuine article that is a near final beta. What do you want for it? There is going to be very little that the modding community would find useful, so its not that valuable as a resource. As a collectors item? Maybe if its an original disk you might convince someone to pay you something for it if you can prove its genuine but you are barking up the wrong tree here.

Just to clarify what ss*.mix files actually do in the original game, they load as uncached, which means the game can load files from them from disk, but not get pointers directly to file contents. Most files are accessed via the cached pointer method, hence most appear "deleted". WSA files and VQA files are I believe exceptions to this and should still work in an ss*.mix file.

This sounds vaguely like a DLL injection project, similar to what ares (YR) or thyme(Zero Hour, my own project) do to inject their own code. It sounds over the top with its modifications though, allocating heap for custom code? Just reimplement functions you care about in C++ and then set jumps in the original code to go to them. Compile the whole thing with open watcom and you won't even need to write shim inline assembly to account for different calling conventions either. I've recently been experimenting with injecting a dll into RA, so I know this can work and indeed does work very well.

Regarding values of 0x00FF for the tile id, those should be treated the same as 0xFFFF, ie clear randomised tiles. This means that tileset 255, which is a floor arrow in the interior theater is not valid and should never be displayed, it should be the black clear tile instead. This is the way RA itself treats tiles and is probably related to the game originally handling old c&c map data during development.

Depends what you mean by good, Vector math is just trigonometry IIRC which I've not done extensively since high school physics, but I understand the principles fairly well.

Progress is still ticking along, most of the path finding code has provisional implementations, we are just fleshing out the unit logic associated with movement so we can do some testing and debugging of it. The lib we have split off from the project we plan to develop into what will eventually be an open implementation of what the wwvegas lib contained and could form a base for other Westwood related game reimplementation projects.

Development has been slowed down recently due to real life issues as we've not been able to put as much time into the project. We have most of the path finding initial implementation done, but there is a fair amount to do to hook up assigning the movement to a unit and it following it yet. We've also done a bit of work to split the project into game specific stuff and stuff that could be reused in future projects to develop other Westwood game clones as it seems a lot of the low level stuff was reused among them.

I've not really messed about with this myself, but would it not be a better idea to update the registry to enable loading of the safedisc driver again rather than removing the security update? Especially since on Windows 10 the "fix" is part of the OS and can't be removed AFAIK.

We've mainly been posting updates on Facebook, this is a screen shot of our most recent progress update there. Basically, we can get in game, most things draw more or less correctly and you can select things. Still a way to go before we have units moving around doing stuff though, we are currently working on the path finding classes.

To be fair, he doesn't really have to respect the admins, he just needs to keep his mouth shut. He can lack respect all he wants, just not demonstrate it in public.

Are we taking about OpenRA the engine or the games built on top of it (of which there are several)? The focus of these forums is more toward the original games and most people here tend to prefer those over the games built to look like them on the OpenRA game engine. Emotions tend to run high when the OpenRA mods are presented as "replacements" or "improvements" over the Westwood games or exactly how the OpenRA mods relate to those games, but in general I don't think many people here have anything against the OpenRA project or the people who develop it.

I think the idea was to make it harder to enumerate the locations of the files within the mix and make it a bit harder to mod the game, but because it didn't enforce encrypted headers, the normal header format works fine and so new mixes could still be made with the old tool.

To my knowledge they did. EDWIN was created by stripping out unneeded parts of the game, while the game stripped out much of the editor code. The original editor would obviously have had more features such as being able to place units and buildings, set facings and health and so on.

Multi precision integers are basically arbitrarily large integers that can be used for calculations that don't fit into the CPU word size. Internally they are normally represented by an array of ints that match the word size for the CPU and the maths is done something akin to the long addition, subtraction, multiplication and division you may have learned in school. It only gets complicated when it needs to do these operations efficiently and using more complicated maths (such as used by RSA which is modular exponentiation). Decrypt the mix files headers? I doubt it unless you already knew the index that the header decrypts to (in which case what was the point again). Note that the body is not encrypted at all, you can read any file directly from it if you know its start an size. Its only that information that is encrypted. You are wrong though, it does involve keys and is actually quite a sophisticated system. When a mix file was created by the original Westwood makemix tool, a random 448bit Blowfish (56 bytes) key was generated. This was then encrypted using the private Westwood RSA key and saved as an 80byte block in the mix header followed by the mix index encrypted by blowfish using the generated key. The game then reverses this, it decrypts the 80byte block using the Westwood public key that corresponds to the private key to regenerate the Blowfish key and then proceeds to decrypt the index so it can work out where files start and end as well as what their ID is so it can find them by name. How then do we have tools that can create encrypted mix files given that Westwood has a private key? Well XCC cheats, it loads an existing encrypted mix and saves its blowfish key in both forms and simply writes the encrypted block unchanged, it makes no attempt to encrypt the blowfish key and its decryption is just reverse engineered from the game as far as I can tell, using the hard coded public key. Olaf wasn't even aware it was RSA to my knowlege. However Westwood also goofed up and with TS released a mix containing a file called keys.ini which as luck would have it, contains the key pair. We've also since discovered that EDWIN also has the private key embedded in it. This went unused until a few years ago when I put some effort into really understanding the mix encryption and now its possible to create mix files with new keys (though not yet with XCC).

There were a bunch of files missing from Olaf's XCC source, whether the omissions were deliberate or just an oversight I won't speculate on. Tomson tracked most of them down from other projects Olaf worked on such as his bit torrent tracker. Refactoring to remove the requirement for them was more effort than I was willing to put in just to compile the project.

Fearing for neither my life or sanity I have dived into the code of XCC mixer and wrested from it the ability to compress TD shp files properly in the same manner that shapeset does. Replace your normally installed XCC mixer with the http://www.mediafire.com/download/sazobj97sl06wh9/XCC_Mixer.zip. Bonus ability is that it can also now read the ra mouse shp correctly. Source can be found at https://github.com/OmniBlade/xcc in the encoding branch.

TBH, it probably won't be us doing the advertising, that will be up to tournament organisers, but its always a good idea to stay clear of and possible trademarks if only to try and avoid the eye of sauron EA. Regarding the large amount of credits in the image, the variable that holds that isn't initialised properly at the moment so it can end up with whatever random values that bit of memory had previously.

No worries, pinning down the format down needed to be done anyway to ensure we have a full modding tool set for RA++. Its taken some 20 years to get a working WSA encoder figured out properly, but its finally done it seems

The compression is fine in my tool, its the delta in the header which tells the game how much memory to allocate for decompression that is causing these issues. I think I've finally solved it though. The build found here http://www.mediafire.com/download/lhuvu4jsh2006ie/wsaset.zip should be able to create a working choose.wsa file now as well. Give it a whirl and let me know. WSA frames are stored as an XORDelta against the previous frame that is then LCW compressed. The header Delta field is supposed to be the largest frame plus the size of the in memory header that is built for it. My mistake was assuming it was the size of the XORDelta before LCW compression, but its actually which ever is largest, the largest uncompressed XORDelta or the largest LCW compressed delta. For most image data, the assumption that it will be the XOR is fine as LCW compression makes them smaller, but for very random data that changes a lot between frames (like the static in the choose.wsa) then LCW can actually end up larger than the uncompressed XOR, hence the problem.

I much prefer the effect as its done in the PC versions personally, the PSX version is just a big smudge. Regarding the DOS version, as far as I know the effect is the same, certainly the same lut files are used. Could be that an earlier build was bugged and the effect didn't transition to the funnel state, the vortex has a few states it can be in and one of them is dissapearing which based on videos of it I've watched doesn't have the darkened funnel effect (different luts are used for different states).

Okay, more test binaries at http://www.mediafire.com/download/vfy4otw0ok7x665/wsa_test.zip. The reg version should generate wsa files almost the same as the WW encoder, the opt version uses the more aggressive delta encoder that saves extra space. Both should now calculate the delta field in the header the same as the original WW tool, so if neither of these generate working WSA files then I question the integrity of the game edit: These tools should work for any WSA except choose.wsa which for reasons I don't fully understand has a much larger delta relative to its largest frame than any other WSA I've tested so far.

I'm not sure if you included my comment for context or as someone you perceive to be holding a grudge, but in case its the latter, let me state for the record now that I have no ill will toward the OpenRA project or its developers and community. I do have a side hobby of arguing the "C&C RA and OpenRA are different games" angle when I see discussions getting heavily weighted toward the "OpenRA is the second coming of RA, convert and be saved" crowd, but if that ever comes across as me criticizing OpenRA itself or what its dev team have accomplished I apologize as its not my intention. I just get a bit over zealous correcting the over zealous

Ever wondered how they did that Chronal vortex effect in RA? Thanks to research done for RA++, you can wonder no more, I'm here to describe how it is accomplished. The effect is actually created using a series of lookup tables, since doing the math for the distortion on the CPU in the days RA was released would probably have been a bit much. The lookups are actually a series of files located in REDALERT.MIX > LOCAL.MIX. They are unknown file names if you are using the standard XCC database but are actually named hole####.lut. There are also the *_VTX.PAL files which contain "fading tables" lookup tables for drawing shading effects like the .mrf files found in C&C. To draw a "frame" of the vortex, the game decides what state the vortex is in and what frame it is on and then loads the .lut file for that frame. It then draws a 96 x 96 pixel buffer containing the terrain, tile and overlay graphics for the area that is going to be distorted to a special buffer used specifically for this effect and passes it to the distortion function. Game objects are not drawn in this buffer and thus are not present in the distortion if it overlaps them. The distortion function applies the lut transformation which is stored as 3bytes per pixel to be transformed. The first two bytes are the X and Y coord in the source buffer, that the destination buffer pixel will be drawn from. The last byte is which table in the "fading table" will be used to shade that pixel as there are several remap tables, each getting progressively darker which are either loaded from the *_VTX.PAL file on theatre change or generated if the file isn't present. The destination is written left to right, top to bottom. The distorted copy of the buffer is then blitted to the actual rendered display.