48 replies to this topic

[cmorgan]

Hey, Wisp - if I am reading this correctly, and I may not be -

I am still missing a step.

It looks like this checks to see if the songlist is patched, based on Taimon's work.

I don't need to check for Ascension64's stuff, as if it is installed the .exe won't match and the patching will fail or report it has already been accomplished.

ACTION_IF count_of_musics < 500 BEGIN sets me up to patch in .acm references if the .2da has less than 500 (0-499) rows. Which woruld return true on the original resource, as 99 < 500.
ADD_MUSIC checks for already existing entries before adding - so it will add those entries no problem - but I am stuck on how to check if there are enough *blank* rows. Unless...


ACTION_IF ( count_of_musics < 500 ) AND ( count_of_musics > 100 ) BEGIN would work?


(Actually, to be really fancy, it would be ranges, wouldn't it. The lower boundary check would be the original songlist.2da, then a check to see if there were between that and 4 below the limit, and the ADD_MUSIC could fit for my mod; if the full 99 were used and there was no patch available, then default to .wav, and if the patch was installed then add between the boundaries... this is getting too complicated. Belh. Overthinking, probably. Might be better to try it out and deal with the occasional assertion error report. It would be tough to fill up all 500 rows.)

Edited by cmorgan, 18 May 2010 - 08:00 AM.

[Wisp]

Hey, Wisp

Que? (How did I get involved in this?) But to maybe answer your question.

but I am stuck on how to check if there are enough *blank* rows.

If you want to add 4 entries, I would think you can merely use count_of_musics < 496. If true, there are at least 4 slots available.

Edited by Wisp, 18 May 2010 - 09:17 AM.

[cmorgan]

Sorry, wut and wisp - i was quick-scanning at work (evil dude that I am), and mixed you two folks up - mea culpa! I apologise!

If you want to add 4 entries, I would think you can merely use count_of_musics < 496. If true, there are at least 4 slots available.

... as long as the patch is installed, that is - but I think I see how this could run... let me play with it for a second...

Edited by cmorgan, 18 May 2010 - 11:09 AM.

[cmorgan]

OK, does this logic check out?

COPY bgmain.exe bgmain.exe
	READ_ASCII 0x000cc6f7 target_bytes_1 ELSE 0 (0x42)
	READ_ASCII 0x000d40ef target_bytes_2 ELSE 0 (0x611)
	READ_ASCII 0x000d4892 target_bytes_3 ELSE 0 (0x10)
	READ_ASCII 0x005e20b4 target_bytes_4 ELSE 0 (0x19c)
	PATCH_IF (~%target_bytes_1%~ STRING_EQUAL ~%orig_bytes_1%~)
 	AND (~%target_bytes_2%~ STRING_EQUAL ~%orig_bytes_2%~)
 	AND (~%target_bytes_3%~ STRING_EQUAL ~%orig_bytes_3%~)
 	AND (~%target_bytes_4%~ STRING_EQUAL ~%orig_bytes_4%~)
	THEN BEGIN
 	WRITE_ASCIIE 0x000cc6f7 ~%patch_bytes_1%~ (0x42)
 	WRITE_ASCIIE 0x000d40ef ~%patch_bytes_2%~ (0x611)
 	WRITE_ASCIIE 0x000d4892 ~%patch_bytes_3%~ (0x10)
 	WRITE_ASCIIE 0x005e20b4 ~%patch_bytes_4%~ (0x19c)
 	OUTER_SET songlist_big = 1 // ADDED <<<<<<<<<<<<<<<<<<<<<<<<<<
	END ELSE
	PATCH_IF (~%target_bytes_1%~ STRING_EQUAL ~%patch_bytes_1%~)
 	AND (~%target_bytes_2%~ STRING_EQUAL ~%patch_bytes_2%~)
 	AND (~%target_bytes_3%~ STRING_EQUAL ~%patch_bytes_3%~)
 	AND (~%target_bytes_4%~ STRING_EQUAL ~%patch_bytes_4%~)
	THEN BEGIN
 	PATCH_PRINT ~Patch already applied. Skipping ...~
 	OUTER_SET songlist_big = 1 // ADDED <<<<<<<<<<<<<<<<<<<<<<<<<<
	END ELSE INNER_ACTION BEGIN FAIL ~Target bytes don't match. Aborting ...~ END
BUT_ONLY





/* read existing songlist.2da to see how many there are */
COPY_EXISTING songlist.2da override
	COUNT_2DA_ROWS 3 count_of_musics
BUT_ONLY 

/* check for space available */
ACTION_IF ((songlist_big = 1) AND (count_of_musics < 495)) OR ((count_of_musics > 82) AND (count_of_musics < 96)) BEGIN

<<add in as acm/songlist, because either there is a patch and space, or there is no patch but still space>>

END ELSE BEGIN

<< go back to good old PlaySong(0) PlaySound("myWAVC") >>

END

?

[Wisp]

I apologise!

Heh, I don't mind.

OK, does this logic check out?

Well, so long as that FAIL is in the exe patch, you won't need your backup scheme. If you remove the FAIL you also need to make sure songlist_big is set to something under all circumstances or you'll get a not found error when the variable is not set to 1 (also, you are using OUTER_SET in a patch environment).

[cmorgan]

I guess I am not understanding something, which is par for the course

The first is if I want to set a variable that is referenced without it being reset to null, referencing it outside of the { PATCH_IF something END }, what should I be using?

The second - let me try to explain why I am hung up on this, so you folks can help me clear my head.

with the FAIL in place, the user is saved from having the wrong .exe version targeted. It skipps extending the songlist.2da. Which leaves the possibility f using songlist.2da anyways, if the install has not filled them up already... and I want the mod processing to go

1. Hey, if it is all possible, open up the songlist.2da to 500 entrys.

2. OK, Let's recheck the songlist.2da.

3.
If it is the original, unpatched one, and has space (there are between 83 and 94 rows inclusive), add the new entries.

OR

If it is the extended one, and has space (there are no rows from what would be 83 and 495 rows inclusive), add the new entries.

4. If 3 didn't work, then set everything up with the workaraound, ignoring songlist.2da and

I am stuck on the backup scheme, and why I would not need it...

[berelinde]

I'm just going to wait for cmorgan to get this working and then pillage code. Because I do that to him all the time.

[cmorgan]

Aha! That explains the gap in my logic - FAIL means "fail and stop everything, roll back, and give an error message." Now I do feel like a dope, because I relied on that when setting up tutu/bgt combined stuff to detect if someone was trying to install it on BG instead of Tutu or BGT.


so, the breakdown, as I am a musician not a real coder, dammit...

set the variable to 0 using OUTER_SET, so it exists and is null. Then the first patch block looks at 4 separate segments, and compares all of them to the values created in the upper blocks of code (not shown) - one set matching expected bytes, another set matching what is expected after the patch has been applied.

If all four blocks match the values "original bytes", then the .exe gets patched with the new values, and regular old SET tells us that the patch was applied by changing the "songlist_big" from 0 to 1.

If all four blocks match the patched .exe values, then someone has already run the patch, and nothing happens; regular old SET tells us that the patch was applied by changing the "songlist_big" from 0 to 1.

If any of the four blocks do not match either original or already-patched, then we just go on. "songlist_big" remains at 0, and nothing happens to bgmain.exe.

Then, we count the rows.

Then,

(checking up WeiDU readme...)
AND = Conjunction. If both values are non-zero, the result is 1. Otherwise, the result is 0. Synonym: &&.

OR = Disjunction. If either value is non-zero, the result is 1. Otherwise, the result is 0. Synonym: ||

ok,
count_of_musics < 96 || (songlist_big && count_of_musics < 495)

says "if there are less than 96 entries, go ahead and add 'em, or if songlist_big = 1 and there are less than 495 entries, go ahead and add 'em - if neither of these are true, then move along to set up the sounds using the PlaySong(0) hack-method."



Thanks for everyone's patience. I will give it a test, shake it about, and see what I can do with it!