The DLL Project

[Blade]

I should probably get back onto leaning C again. I can just about make out what is happening in the sample source file...

[MCV]

Hmm. Could the Westwood Stupidity fixes be included in a DLL, or would you have to code them in since they are allready part of the code. I'm not too sure wherether DLL's can affect the EXE they are used by, so if not, could the WWStupidity fixes be included for the sake of cleanup?

[pd]

I'm not too sure wherether DLL's can affect the EXE they are used by

Of course it can, that's the purpose of all this.

[gordon-creAtive]

Hey do you remember this thread?

I think it could be usefull to add a plugin system like AdminMod/AMXMod/AMXModX to YR. With these plugins multiplayer games will be much more amazing like it is in Counter-Strike

[pd]

Small progress report:
No, no fancy new stuff to look at this time...

I'm working on the core things to work, at the moment I'm replicating the interfaces and virtual tables. This means - among other things - that later you can come up with custom classes deriving from the originals.

For now, it all works as planned! Little problems that naturally occur here and there are fixed easily. Well, that's the good news, the bad news is it might take ages to complete... >.<

Also, I moved to the MS Visual Studio 2008 now, which luckily reads the getter and setter functions out of the macros and has many other fancy features that will make documentation easier.

Speaking of documentation, I will probably not go into every little detail, but rather give people a general overview of what the single classes are for and how you can approach things.
Additionally to that I'm planning a small tutorial from literally "Hello World" to "Adding a new SuperWeaponType". As said, I won't (and can't... it's too much) explain every little detail, but I'll try my best to comment on the class properties etc so you will be able to browse the classes in some way and learn about things.
As said, this might get comparable to getting into UnrealScript, which is kinda easy at the beginning, but will take some effort to in order to work on advanced stuff.

What I can tell for sure is that the first C++ wrapper versions won't be complete. They will feature most things you might be wanting to use (all kinds of unit classes, SuperWeapon classes, drawing, file loading, ini reading), but just not everything (while "everything" is practically impossible anyway... I believe).

I know people always want to know "when", but frankly I can't tell.
Might still be this month, but of course, I cannot promise it at all!

[Blade]

I assume you'll make it easy to ensure save games will work too

[gordon-creAtive]

pd, what about Multiplayer? Will there be again issues with reconnection errors?

[pd]

While the reasons for broken savegames are completely clear now and can be easily avoided, I'm not sure what caused the reconnection errors.
It might be the checksum calculations, but why should it get checksum problems when it doesn't even calculate checksums of the newly added stuff? I'm not sure, I'll have to experiment with that.

[gordon-creAtive]

But this also can cause easy cheating right? :S

[pd]

Heh, yes... creating trainers of sorts is indeed possible, but might cause reconnection errors (not sure how the online stuff works, meh).
We would have to think about some sort of protection, maybe when the game checks for game versions it must check the DLL versions as well.

But it's not like this would be the first possibility to cheat is it?

[Marshall]

As well as checking DLL versions, would it be possible for the RP to force all players in multiplay to use RP? I.e. if Player 1 uses RP and player 2 doesn't, then RP will refuse to start a network/internet game? That way, Player 2 can be sure that their opponent has no possibility of using RP to enable cheating in a vanilla online game.

[Bachsau]

Well, cool!

At this point I can't stop myself from saying that i've thought about doing all changes in a DLL a half year ago, but I thought you would also have thought about this already, and had your reasons not to do it.

Cool!

[~Guest~]

I was just wondering if you have talked to VK yet. I am curios what he say of co-op.

[DCoder]

Can you stop doing that?

[pd]

As well as checking DLL versions, would it be possible for the RP to force all players in multiplay to use RP? I.e. if Player 1 uses RP and player 2 doesn't, then RP will refuse to start a network/internet game? That way, Player 2 can be sure that their opponent has no possibility of using RP to enable cheating in a vanilla online game.

Of course I might do this in RP, but other DLLs do not *have* to do it.
IE, only RP users would be protected, if somebody runs his own project the check is not necessarily done.
I don't think we should put too much attention to cheating.
It has always been possible to use trainers online (Droke confirmed this to me a few days ago), so what would the difference be?
Those who blatantly cheat can usually get identified quickly.

---

I will use this small section to ask DCoder or Ren to add support for the <hr> tag here, cause horizontal rules look alot better than "---" ...

EDIT: Maybe I should just find a BBCode reference >.<

---

Progress Report:
I "took a few days off", another few days I worked almost half-time.

Funny things have been implemented and can be done in the game:
The CaptureManagerClass is responsible for units capturing other units (mind control). This feature is (apparently) fully implemented.
My test was selecting an enemy unit and make one of mine mind control it. It worked!
Mind overload and freeing a unit from mind control seems to work fine just as well.

The DiskLaserClass draws a radial laser around a unit which eventually fires at an enemy unit. This is used by the floating disk in YR, now it's available using C++.
A minor addition, but a good step in the "done"-direction.

Untested, but already implemented is the AirstrikeClass, which is used for Boris' airstrikes. Bad news is, it really wants to be fired by an InfantryType.
I might have to code a new class that works independently from infantry.

Yeah, there's more stuff, but the list would blow this forum.
It will be a damn pain to write a documentation over this, it might turn out to be just a little description on each class, ie what it can be used for.
The rest can be explored in the declarations, which I'm trying to comment understandably.