Patching extra functionality into <gamemd.exe>

[Marshall]

Actually, 'divide by zero' is nonsensical. Just as inifinity isn't a number.
zero/zero is also nonsensical.

But this is getting off topic.

Guest had a good idea, however if that were the case it would surely cause a problem on any OS.

[pd]

Guest's idea is wrong.
The game gets the CellSpread value, e.g. 6.

So it loads the 6th entry out of the valuetable by multiplying the value 6 with 4 (each value is a dword = 4 bytes) and adding the base address of the table.

So 0 wouldn't cause any problems.
What's funny is, that CellSpread is a float value.
I dunno what happens if CellSpread=2.5 or 0.5.

[CannisRabidus]

Cellspread is used like that throughout the game. It certainly does work to define radius as you would expect. This is needed for infantry in particular, because infantry is never in the middle of a cell like a voxel is.

[Bobingabout]

in engineering, we assume devide by zero is infinity, because the smaller the number you devide by, the bigger your answer is. we use mathamatical "tricks" using infinity and zero to cancel parts of fomulas out to make the reverse process easier, and in some cases just possible.

now here is a strange 1, anything devided by zero is infinity, but whats something over infinity? lets assume zero, so whats infinity devided by infinity? assuming both infinity is equal to infinity, then the answer is 1, but how can you be sure both infinitys are of equal size?
that is 1 mathamatical jam we try not to get ourselves into...

what was we talking about again?

oh yes, cellspread is kinda strange, cellspread=0.1 works, but, as PD pointed out, its a table, so does it mean that the cellspread covers the entirety of that 1 tile?
range seems to work fine though, although hight issues screw with it sometimes.

[Marshall]

I really don't want to get off-topic here, but:

[@=infinity]

X=1/Y
As Y tends towards infinity, X tends toward zero.
As Y tends towards zero, X tends toward infinity.

0/0 and @/@ are nonsensical.
@ isn't a number, but logically:

1/1 = 1
X/X = 1
@/@ = 1

0/1 = 0
0/X = 0
0/0 = 0


Anyway, regarding cellspread, obviously there must be other code that uses the values in the cellspread table.

[pd]

I'm back at work, and created a small list of everything that uses the CellSpread-valuetable:

Usage of the "CellSpread Table":
--------------------------------


--------------------------------
=== 1: Warheads (CellSpread) ===
--------------------------------

At: 4895A3, 4899C7
Limited: no
Possible errors/bugs: CellSpread > 11 => IE


--------------------------------
=== 2: DominatorCaptureRange ===
--------------------------------

At: 53B186
Limited: to 10 (hardcoded)
Possible errors/bugs: none


-----------------------
=== 3: RevealOnFire ===
-----------------------

At: 567528
Limited: to 10 (hardcoded)
Possible errors/bugs: none


----------------------------------------------------
=== 4: RevealShroud (e.g. Psychic Reveal, Sight) ===
----------------------------------------------------

At: 567A63
Limited: to 10 (hardcoded)
Possible errors/bugs: none


----------------------------------------------------------------------------------
=== 5: Unknown (among others: building placement, infantry entering buildings) ===
----------------------------------------------------------------------------------

At: 567DC7
Limited: min 3, max 11 (hardcoded)
Possible errors/bugs: none

At: 567DED, 567F03
Limited: ???
Possible errors/bugs: ???

Part #5 is weird, it's where the error occurs.
I'll do a deep check now.

[Marshall]

I know that the Sight= of a building detremines how much shroud is revealed when the building also has RevealToAll=yes.

[Bobingabout]

hmmm...
can someone send me a working version without sight and cellspread?

[pd]

Okay then, say "welcome back" to the limit of 11.

I made up 4 test versions which Fenring tested (he had the same problem Marshall had).

The only working version was the one with none of my new limited stuff at all.
Not even CellSpread alone works, so I gotta remove it as well.

[CannisRabidus]

Here's a goofy idea. Feel free to ignore.

UseQuadSpread=X
When used as a [*Type] property, it modifies Sight= origin

Default = 0, means don't use it.

Values >0 means create an array of 4 origins, offset from the 'natural' origin by the number of cells specified by X.

So if a unit has UseQuadSpread=3 and Sight=10, create an array of 4 sight origins offset from the natural origin by 2 cells in all 4 directions. This unit will be like having 4 units all unshrouding at the same time, and its effective Sight= would be 16.

This really wouldn't work for Warhead CellSpread= since the overlapping spreads wouldn't seem circular without a much larger array.

[jonwil]

I was playing YR with the latest (1.04b) patch installed and got the attached except.txt crash early in the loading of the Massivesoft mission.

In addition to your patch, I also have the latest version of the Terrain Expansion addon installed.
No other mods or patches are installed as far as I know.

BTW, great patch (I found out about it because I saw the Terrain Expansion news on planetcnc and installed RA2 and YR again to play with it. Then I saw about the game expansion packs because I was reading the Terrain Expansion and DeeZire message boards which lead me here). And I know all about except.txt files (they are great debugging tools , I deal with them all the time for another westwood game, Command & Conquer Renegade (I am the primary coder of a similar project to yours that ads extra functionality and unlocks stuff that didnt work right in the renegade engine). In fact, it appears to be identical code between RA2 and Renegade for spitting out except.txt files

Also, I was very active back in the day in the TS/RA2 modding sceneand was (and still am in fact) friends with Olaf Van Der Spek of XCC mixer and Matze of FinalAlert. In fact, it was me that did a large part of work to figure out the TS/RA2 .SHP format way back when (and other stuff like the filenames of files in the various mix files)

I do things differently to you though, what happens is that I load an extra dll into the renegade memory space which then patches the dezired offsets. This lets me work in a mixture of inline assembler and C (and the odd bit of machine code here and there where I need to write actual machine instructions directly to renegade memory space)

Hopefully you can tell me if this crash is caused by your patch or something else.

[pd]

@Cannis:
Right, would be a workaround for Sight only which isn't that elegant to be honest...

@jonwil:
DLL's a nice idea.
When I began this project, I've been a complete beginner in EXE editing and machine code, even in ASM.

People advised me to make the game use a dll rather than expanding the exe, but I wouldn't have known how to do that.

Well, I gained a lot of knowledge working on this.
The only knowledge that's missing now is how to declare API functions in ASM... the input tables don't tell me much :huh:

Hm, but the possibility to code in C wouldn't help me much actually.
Maybe it will though, when I do larger stuff...

Anyway, you're IP points to B9800C... if any value begins with B9 or BA, it's very likely to be caused by my patch
Hm... what's actually wrong - the address returned by YAPAXI (not a Yuri unit but a memory allocating function).
I THINK (not know) the problem that I didn't leave the first 4 bytes of my data stock. The first 4 are mostly used for initialisation crap like data length etc.
So maybe I should avoid writing to them.
The question's that left is why does it occur in THAT mission... I should try that out myself.

BTW, 1.04c should be released in a few minutes

[Renegade]

Building up on Cannis' idea...can't you perhaps just work around the bug by adding a multiplier?
Like, Sight=10, SightMultiplier=1.5 or something?
As in, perhaps you can cheat the game by technically leaving the Sight alone, but making the unit have more sight anyway.

Just pondering...

[jonwil]

I wonder if there is anything I can do to help with this project...
I do have skills in assembler myself and (depending on free time) might be able to throw some of those skills towards helping make RA2 a better game...

Perhaps I can bring a different perspective and skillset towards this work...

EDIT: I did a look at the YR exe file and I can see a few things already that are of note.
Firstly YR uses Runtime-Type-Information which basicly means that essentially we have the complete class hierarchy (i.e. the name of the class plus which classes it is derived from/which classes derive from it)
Secondly, YR has that ra2.tlb file. Looking at it with an OLE object viewer reveals that a bunch of the game classes appear to be (or have associated with them in any case) COM interfaces. This makes figuring out stuff about those classes a little bit easier (especially if combined with the Runtime Type Information from before)
And thirdly, YR seems to use a number of "basic" classes (specifically VectorClass and DynamicVectorClass) that are also found in Renegade.
In fact, I have lots of knowledge about these classes.

[pd]

:o :o :o
That means those strings like ".?AVPlayerProfile@@" actually are useful?

Yes you are... I always ignored them because I thought they're overlefts by anything, researches I've done about them didn't bring any results...

But you're right... before each of those "class names", there are offsets, pointers to the classes...

Damnit, you're God!

EDIT: Ech, those pointers all point to the same offset.
Anyway, we need to talk a little about that stuff in MSN