Hmm, doesn't seem to work :/
Okay, I think I figured it out:
- The handler needs to be persistent
- The corresponding bonus pool must have CKGroup::unk2 set to 4 (third bit)
- The beacon must have it's bit set to 0
I guess the beacon bit indicates if it is collected or not, and by default the editor sets it to 1, which makes the bonus not appear when playing the level for the first time
probably why the laurels I tried to add in the past never showed up: The game thought they were already collected.
Ah yeah, didn't know that. I just put the same default bits for every type of beacon, and I also wondered why new laurels wouldn't appear, but metal crates did
Good to know 👍
@adrientd I have a suggestion to find out which sector the water grounds are in: The member "ckhwUnk29" is a bitmask which indicates in what sector the water is active. Starting from the second bit, which is sector 0 (start), each bit corresponds to a sector in which the ground is active. So a value of 2 would be sector 0, or a value of 6 would be sector 0 and 1
And of course make sure that you only check the number of bits equal to the number of sectors 👍
Hmmm interesting..., but as it is a bitmask, what if there were two or more sectors enabled, and the ground is in the STR?
I guess in that case the ground would be in the LVL, or water with STR grounds are only active in at most one sector, but I will probably have to verify.
Yes, either it's in the level or there are no postrefs to bind
So far I only know of the water in gaul which is active in two sectors, but it has no ground refs so I think it's fine
I'm not even sure what the point of these ground references are, since you can you make water using parameter in the ground, unless somehow it is required for swimming?
I thought that maybe these Grounds were only referenced to determine how to create the Water plane's mesh, to determine the borders etc.
There is probably a good reason for it tho
Maybe if there are two overlapping water planes? 🤷♂️
I verified, and yes ckhwUnk29 does contain the sectors active, however there are some water hooks, especially in Egypt, where ckhwUnk29 == 0xFFFFFFFF, yet they still reference to grounds in the STR.
``` WaterBox AABB: -349.477509 9.501619 3.331326, -359.477509 9.501619 -6.668674
- Sector 0
Ground AABB: 320.410919 13.497355 233.091125, 314.854248 11.379189 221.961365
Distance: 884.839355
- Sector 2
Ground AABB: -299.523895 11.585178 242.727951, -343.632263 8.997638 235.210800
Distance: 237.724716
- Sector 3
Ground AABB: 677.712402 11.930403 -214.256180, 652.891846 9.930401 -260.014343
Distance: 1210.385620
- Sector 7
Ground AABB: -349.410095 9.747905 3.062702, -359.226196 8.969905 -6.937300
Distance: 0.000000
- Sector 8
Ground AABB: 301.859406 -379.885254 -410.009827, 267.918243 -406.759949 -474.010193
Distance: 1410.123779
ckhwUnk29 = 0xFFFFFFFF:
strHitFrequency:
7: 1
bind struct CKHkWater :: node postref to sector 7
bind struct CKHkWater :: ckhwGrounds[0] postref to sector 7```
For example this one above.
So what I might do, is to check ckhwUnk29 first, and if only one bit is active in the valid range of sectors, I could just take the active bit as sector, else I will still have to compute for distances and take the nearest.
Cool, by using the distance method would also mean that new water hooks could reference grounds in multiple sectors as well
GeneralXXLXXL 2XXL 3XXXLOlympic GamesXXL EditorToolsOff-TopicXXL RomasteredXXL 2 RemasteredOther GamesModsCaesar's ChallengeUnfair XXLPatchesFan ArtPersonal ArtSpeedrunningMediaRandomizerBETA RomeHSKALPresence AdrienPresence SPQRPresence Mr. Rubinshtein
Helpdesk ☰