nipkownix / re4_tweaks

Fixes and tweaks for the "UHD" port of Resident Evil 4
zlib License
342 stars 33 forks source link

Ability for ETS models scaling #303

Open Corazon-SA opened 2 years ago

Corazon-SA commented 2 years ago

Describe the feature you'd like to see added

Hi, First thank you very much for the amazing work you are doing hare I am happy that now we have enemy scaling (thanks to you), and I am start to think about the ability of ETS models scaling We already have the option to change the scale of ETS model, but it doesn't work .. Thank you

emoose commented 2 years ago

I'm not really familiar with the different model types and stuff used by the game (and the code usually refers to stuff differently than what the filenames show...), could you give an example what ETS models get used for?

E: ah looks like EtcModelSet might be what handles it, that makes use of an ETS_DATA struct to setup/init some cEm instances - looks like that struct does have a scale field, but haven't seen anything actually try reading from it, hm...

Corazon-SA commented 2 years ago

I'm not really familiar with the different model types and stuff used by the game (and the code usually refers to stuff differently than what the filenames show...), could you give an example what ETS models get used for?

E: ah looks like EtcModelSet might be what handles it, that makes use of an ETS_DATA struct to setup/init some cEm instances - looks like that struct does have a scale field, but haven't seen anything actually try reading from it, hm...

.ETS files contains the information about interactable objects, such as (breakable barrels, doors, breakable glasses, ladders .etc) we can set the (position, rotation, scale) of an ETS objects, but unfortunately the scaling doesn't change anything. I believe scaling ETS objects can scale its hitbox too, which is awesome for new ideas Thank you very much

emoose commented 2 years ago

Hmm, any chance you can point me to where the ETS files are stored for me to look at? Guessing they're in some kind of container like BIN/EVD/etc but don't know which ones.

Seems like I can probably add code to update the actual cModel scale based on the data in the ETS (surprising they didn't add code for that already), but not sure if there's any ETS which already has some value set there which might mess stuff up, if so I guess would have to add some kind of flag like the ESL scale stuff.

Corazon-SA commented 2 years ago

Hmm, any chance you can point me to where the ETS files are stored for me to look at? Guessing they're in some kind of container like BIN/EVD/etc but don't know which ones.

Seems like I can probably add code to update the actual cModel scale based on the data in the ETS (surprising they didn't add code for that already), but not sure if there's any ETS which already has some value set there which might mess stuff up, if so I guess would have to add some kind of flag like the ESL scale stuff.

.ETS files are inside .UDAS files. .UDAS files holds multiple containers inside it. .UDAS files are located in st1,st2,stX... folders,, .UDAS files contain rooms data. Let me know if you need any extra information. Thank you very much

emoose commented 2 years ago

Ah thanks for the info, had a look at one ETS and seems there are some scale values set there already, ones I saw were all just set to 1 though, no idea if there's any that might be different... I guess we can just update it from the values there and see what happens, can always add a flag etc later on if it turns out that some do have invalid data there.

Corazon-SA commented 2 years ago

YES, we already have scale values, they are always set to 1 but changing them doesn't have any effect. I think since we already have values for scaling, then it will be possible to make it work with some coding. Thank you very much

emoose commented 2 years ago

Might have something working at https://github.com/nipkownix/re4_tweaks/pull/305, don't really have a way to test that myself though, any chance you could try modding scale value of some ETS and check with that build?

You'll need to use the dinput8.ini provided & set EnableModExpansion to true inside it first though. Release build should be up at https://github.com/nipkownix/re4_tweaks/suites/7653358431/artifacts/318663700

Mister-Curious commented 2 years ago

Good work on this. I was speaking to @Corazon-SA about something that would be beneficial for this edit.. THere are times people don't want the laser to touch their ETM models, so I was thinking something like this:

F0 = activate scale collision (already established and used).. But what if we could also: F1 = activate scale collision and disable laser interaction) F2 = disable laser interaction

This would give a bit of flexibility to certain scenarios.

Cheers

Mister-Curious commented 2 years ago

@emoose Did you get a chance to look at my suggestions for this edit?

Also it seems the functions described here are only working the first time we enter the room. After hitting retry, (or going to new room and coming back, or even going to the main menu and loading save), the scaling no longer works.

Cheers

emoose commented 2 years ago

Oh darn, hadn't even thought of those being saved between sessions, figured game might have handled that for us but guess not...

Do you know if the savegame format is described anywhere? Made a small start on that in my IDA database but it's still missing a lot, hopefully can just hook into the savegame code to make it read/write the scale values too, but I'll need to figure out the rest of the save format for that first.

(although, I wonder if maybe scale isn't being saved because of the Em10 code that I mentioned at https://github.com/nipkownix/re4_tweaks/pull/266#issuecomment-1183993641:

ahh okay, Em10/Ganado stores a backup of scale value at 0x498 which it slowly grows/shrinks the actual scale to, added code to also update that and now scale seems to stick

Guess it's possible the Em scale does get saved, but the 0x498 value doesn't, resulting in Ems reverting when you load in - no idea if that's actually the case though)

About the flags you mentioned, I'm not really sure how we'd stop laser interacting with them, does any other mod have that capability? F1/F2 is a bit of a problem though since that field might be getting used by something else, so I made the scale flag only edit the first digit/nibble of the field in case something else needs to use the other one, we could always change that to use 0x80 as scale flag though, leaving 0x10/0x20/0x40 available as other flags that could be added to it.

E: hm, it looks like ESL data might be wrote into the save, if game is calling the EmSetXXX funcs with pointer to the savegame ESL it might be ignored since our code only accepts data that came from the memory for Globals atm...

emoose commented 2 years ago

Ah okay found the issue, our hook is unsetting the scale/speed flag after it processes it (in case game tries to use that field for something like mentioned above, field is at least defined for use by the game, but haven't seen any code actually read from it) - the ESL with flag removed then gets written to save, so next time our hook is ran it won't see it, and speed/scale won't get applied.

I guess we can just remove the code that unsets the flag, and hope nothing else reads from it... though I did notice the be_flag part of the ESL only seems to have 3 values defined (out of a possible 8): https://github.com/nipkownix/re4_tweaks/blob/e2afcdde08c4e11564dbea63e0b0ef87a236c4d0/dllmain/SDK/em_set.h#L6-L8 From looking at the ESL files they seem to use more than just those 3 values though, maybe values used depend on the kind of EM being spawned. Maybe worth writing a quick tool to check all the ESLs and see what values are never used, and use one of the unused flags as our speed/scale flag instead...

E2: ah I was wrong, be_flag is only 8 bits, not 16... luckily from checking all the ESLs it looks like only 4 values get used (the 3 mentioned above, and also 0x4 - not sure what that does), leaving 0x8, 0x10, 0x20, 0x40 unused, it's possible the unused ones are only used when the ESL is loaded in memory though and just aren't set in the file itself, will look into it some more... (E: looks like 0x8 gets used in memory at least...)

emoose commented 2 years ago

@Mister-Curious https://github.com/nipkownix/re4_tweaks/pull/330 should have a fix for the savegame issue now, it also changes the flag position so that we can add more flags in future - any chance you could test it to make sure it's working for you? (you'll have to update your mod to use the new flag described on that page though - @Corazon-SA might want to update your mods too)

Mister-Curious commented 2 years ago

@emoose Thanks for this. Will test this when I can link up with @Corazon-SA. So far just setting scale in the ETS file doesn't seem to work anymore, but perhaps I am missing something.

It does seem though that the trainer is missing from this build.

Mister-Curious commented 2 years ago

For the 'No Laser Collision' you can try checking this edit out:

Laser Goes Through ETM Objects

Must set last 4 bytes of original ETM collision to (1.001 Thickness -- C5 20 80 3F)

----------------------------
66 83 BE 24 03 00 00 00 0F 8E FB 00 00 00 6A 00
Change To:
E9 5F 01 00 00 90 90 90 0F 8E FB 00 00 00 6A 00
---------------------------
Find: 001BB5F0
Paste:
81 BE 64 03 00 00 06 01 CC 41 74 99 66 83 BE 24 03 00 00 00 E9 8B FE FF FF

If you need an example I think I can dig one up that I edited. Cheers

emoose commented 2 years ago

Ah I just realized, you were talking about ETS in the https://github.com/nipkownix/re4_tweaks/issues/303#issuecomment-1236627769 comment right? Not ESL? D'oh

Well at least we found ESL also had the same issue and got that fixed, I'll have to look into ETS again though - might be the same problem with us unsetting a flag when it gets read in, so next time game loads from save the flag won't be available for us to read any more.

If you use the normal ETS scale fields (and not the two 6-byte ones that 0xF0 flag enables) then it might work fine though, maybe worth a test? (game might be loading it from save a different way than what our ETS hooks use though...)

Looked into the laser stuff too, seems cObjWep::drawLaserSight handles drawing it, looks like that func makes use of GetWepTargetPos to find the Em that laser is pointing at & tells it how far laser pointer should draw / whether it should draw the laser-hit effect.

Made a quick test of hooking that function and unsetting it if a flag was set on the Em, seems to work fine, laser can go through the Em and won't leave any hit effect neither - will try seeing if I can let that flag be set by ESL (would ETS also need to be able to set that though? not sure)

Mister-Curious commented 2 years ago

Thanks for this reply @emoose . The whole time I was mentioning the F0 stuff I was talking about ETM models (handled by ETS). I haven't been following much of the ESL stuff, so any talk there was about the ETM models (and the code I sent is to disable the laser collision for ETM models. This is activated by setting that special scale to the original in the bio4.exe. I hope this clears things up.

I hope to test this ETM scaling, saving, laser stuff soon, but could use a refresher on how to do it all. I will be asking @Corazon-SA to run some tests with me.

Cheers

Mister-Curious commented 1 year ago

Hey just wanted to follow up with this edit because I actually put it to use! Thanks to @Corazon-SA for explaining how to scale models to fit collision. One question about that; I remember reading a comment somewhere on here that mentioned something about the issue of vanilla ETS entries that already have some kind of scaling going on. Was that ever addressed or talked about more? I can't remember where I read it.

Thanks!

emoose commented 1 year ago

Yeah there's some ETS entries that already have some invalid data set for the scale for some reason, vanilla game just ignores that data, but now ModExpansion tries to apply it that ends up scaling them using those invalid values, resulting in crazy big objects (I did post a screenshot of that somewhere on here but can't find it now...) IIRC one of the rooms that has invalid data like that is the first castle sewer level, can't remember the stage ID now though.

You only need to worry about those if you're using the ForceETSApplyScale setting that was recently added, if you aren't using that and you're setting the 0x40/0x80/0xC0 flags instead then it should be fine.

Mister-Curious commented 1 year ago

You only need to worry about those if you're using the ForceETSApplyScale setting that was recently added, if you aren't using that and you're setting the 0x40/0x80/0xC0 flags instead then it should be fine

Ok, thanks for the input here. I am using 1.7.7.6. Is the ForceETSApplyScale present in that build? I don't recall using any 0xXX flags at all. We just scaled the model in 3ds Max, and then scaled the model in the extracted ETS txt file (using SoP tools), so I am not sure what to worry about ! Any insight is appreciated!

Mister-Curious commented 1 year ago

Just found a bug with this. ETM id 54 will not scale at all. These are black screens that appear when you shoot a computer screen (can be seen in r309). Its an invisible ETM model that sits right in front of the computer screen, and when you shoot it, it turns black (overlaying the stage model of the screen) to give the effect that the screen has been destroyed.

I suspect this isn't working because the model is a 2d plane. I tried altering the values for all axes but the model will not change size. Try scaling any of the et54 models in r309 and you will see.

Scaling is working fine for other ETM models fine. I'd really love to see a fix for this because I have almost a dozen rooms with computer screens that vary in size. It would be a shame to just have to leave them without the breaking option.

Thanks!