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.