[gamemate]

No that is something different, it is lightpost code. The spotlight moves around and displays a circle of light.

[Infraid]

:S

Is this "spotlight" a TS feature ? Coz I can't remember seein a circle moving around... (didn't like TS, didn't play a lot)

[ArgCmdr]

Yeah, its a TS feature.

I remember RV saying he got it to work too, which means the negative alpha trail -brightness+ for affected pixels) is still in the game code.

[Blade]

Me and DJBREIT have been looking at the spotlight functions under assembly and it seems that SpotlightRadius calls a subroutine that is vastly different between TS and YR, anyone who knows assembly better than us want to take a look over it and try and work out whats going on?

[DCoder]

I have some knowledge of asm, I am looking at it... you know that j**/call instructions call other subroutines, right? Well, the TS function is built up from 27 smaller parts, and YR from 16. I dumped the code, but I'm tired and late, I'll try to do something with it tomorrow.
BTW, do you know the Delphi/Pascal/C or some other coding syntax? It might help to translate this into something easier.

[Blade]

Yeah, I know call calls another subroutine, thats what I followed to see that the sections that they call are quite different. The question is what does the differences do that cause errors (if indeed this is the source of the IE when using a spotlight)and also why does the SpotlightRadius bit have an extra register value being set (that and the registers being used are different, but I don't suppose that is of great significance)?

[DCoder]

Here's a thought: the code in windasm looks something like this:

:00671809 6850B88300              push 0083B850
:0067180E 50                      push eax
:0067180F 8BCF                    mov ecx, edi
:00671811 E8BA5EEBFF              call 005276D0 ; <--- this calls a huge subroutine 
:00671816 8986A8070000            mov dword ptr [esi+000007A8], eax
:0067181C 8B8E2C060000            mov ecx, dword ptr [esi+0000062C]
:00671822 8B159C0C7F00            mov edx, dword ptr [007F0C9C]
:00671828 51                      push ecx

I was analysing other tags, and very many of them call that subroutine too. All of those tags require an integer, so I guess that subroutine is only used to evaluate if the value is really an integer, and not some string or boolean value. If so, that subroutine is of no interest, right? But it can help in other ways to know what tag requires what argument type (it appears that PrismType can take a string list as well as a string... maybe).

Edit: I have NOPed that extra line, like DJB suggested. Nothing changed.

Edit #2: We've been discussing this in three different threads ("spotlights", "has anyone hacked this game" and C-GEN "spotlight")! I think we should concentrate in one of them.

[Blade]

Keep it here in this spotlight thread for now then, though it may well overflow into a more general hack the exe thread. Do you have the TS version of the exe, its probably worth comparing the assembly code with the code from that...the sub routine that this points to is quite different between them. Might be an idea to compare the IsSpotlight code to make sure it triggers the same stuff in RA2 as it does in TS.

[DCoder]

Yes, I have the TS (FS 2.03) version. I've just looked at it, and I've noticed something odd:
In YR, look at any tag requiring a number, it always contains

mov ***, dword ptr [007F0C9C]

in the end. I would think it points to some constant offset which is used for something in every single tag. Yet I'm sure this tag requires an integer, as it calls the same routine as other integer tags, and not the one used on real tags.
In TS, look at any other tag requiring a number, it contains the same instruction with different offset. SpotlightRadius is the only one so far which omits it, the one after it (RevealTriggerRadius) carries it twice - in the start and in the end - instead. Any thoughts on why would it be so exclusive?

I will d/l all the patches for ra2 and yr and try to compare each version. Maybe that'll show something else.


Regarding HasSpotlight:
YR:

:0045FEEC 68A0AE8100              push 0081AEA0
:0045FEF1 56                      push esi
:0045FEF2 8BCF                    mov ecx, edi
:0045FEF4 E8F7960C00              call 005295F0
:0045FEF9 8D9D0C0E0000            lea ebx, dword ptr [ebp+00000E0C]
:0045FEFF 8D542414                lea edx, dword ptr [esp+14]
:0045FF03 53                      push ebx

TS:

:00440AFB 68404A6F00              push 006F4A40
:00440B00 53                      push ebx
:00440B01 8BCE                    mov ecx, esi
:00440B03 E838D60900              call 004DE140
:00440B08 8DBD84040000            lea edi, dword ptr [ebp+00000484]
:00440B0E 8D4C2410                lea ecx, dword ptr [esp+10]
:00440B12 57                      push edi

It seems that tag hasn't changed much.

Edit: now that I think more, when I NOPed that extra operation, I most probably ztyped up something with the revealtriggerradius and not noticed it, since it's only used in missions.

Edit #2: people recommended this tutorial to me, according to them, it's the best and easiest to understand.

[Blade]

There must be either something different about the TS code compared to the RA2 code (that is significantly different) or RA2 must be lacking an important asset and/or statement in one of the .ini files to cause the problem with the effect. I can't think of any reason why the SpotlightRadius would be missing that operation and the next having two unless the unassembler is getting confused when it generates the code and it should belong in the higher subroutine. Its the same in IDA pro however and so I assume thats not the case.