2013-04-10, 12:00 PM
Platform: Sword of Moonlight, what else?
Just kidding. Seriously, I want a door from scratch. You'll need x2mdl, cpgen, and probably that Somimp thing to see where the CPs are in the door models. If you don't know what these tools are, read no further.
I know people are making games with custom pieces, and you can't very well make games without doors. So sooner or later one of you guys will need to figure this out either way.
But here is why I need it. Actually I don't need the door. I need to know how the doors work...
Long story short, we (inc. Verdite) were working on adding ladders to SOM. The ladder model had a problem, in that you could activate its event from no less than 5 meters away. Verdite figure out that was because the distance was based on the height of the object. I worked out it was 1.75 plus half the height. So tall skinny things were totally out.
I'd been meaning to work on localizing the activation of things so that climbing would not feel so different from activation (SOM lets you activate things from ~2 meters away, which is like if you had tentacles instead of arms)
I sunk a lot of work into this. Its one of the biggest projects I've ever done for SOM. Clearly it may as well had been a bug. But it turned out that it actually was a bug. What happens is the height is used where the depth should be used instead.
It's a bug you could fix by hexediting one byte of the game program files, but I don't want to encourage that. PM me if you want it.
For events, SOM actually bases activation on the box dimensions; edited: rotation along height only I think. But for doors and things, everything is treated as a cylinder. And not in a clever way. Because I did run into trouble with the tombstones, because they are rectangular, where the radius was not reaching the front and back when activating with a more modest distance than 2 meters.
So I got the clever idea of routing everything through the event subroutine. This worked well for now, since I am sick of working on this (its been like a week) and really don't feel like programming everything from scratch as good as it could be. Even though that will probably be done eventually.
So now tombstones work well. But there is a remaining problem in that many doors will only easily open from one side. So I am not routing the doors. I will probably just replicate what SOM does for the time being.
The reason this seems to happen is many doors are not centered in the PRF shape. I would not be surprised if none of them are. If only so when you add them to SOM_MAP they will fit snugly into the doorways without adjustments.
At first I thought doors used the cylinder shape. But only the double doors seem to do that. The others seem to use boxes. I don't know why, but boxes would be ideal. If that was they were centered; edited: and actually used. I thought because they were using cylinders for activation that the many control points in the door MDO files were being used for clipping. But I think I've noticed when pushing into the doors that some seem to have a cylindrical shape, so that you can get closer on the edges than you can in the middle.
Anyway, finally. There seems to be at least 3 kinds of doors. B, D, and E. I can't think why any of them would be necessary, other than maybe 2 kinds to mark a door as see through. I would not be surprised if the opening and closing clipping is built into SOM based on the door types and dimensions and maybe the shape too. Only because I can't think of reasons to have more than one kind. The 82nd byte of the PRF file has B, D, or E. Never seen a C. A is lamps. The next highest thing is 14.
Regardless, its not possible to activate doors in the best way possible without knowing their true shape.
PS: I noticed today a stone door that seems to slide sideways. It was in the database at \<span> site blocked, contact your administrator. It's probably a set that is not where its supposed to be. Probably because it was decided not to include it in the final product. May have been a test door. Anyway, that could be C. Or at least, its a new kind of door. Here (\<span> site blocked, contact your administrator/wp-admin/admin.php?page=database&home=pc&view=/obstacles/doors/%E6%A8%AA%E9%96%8B%E3%81%8D%E6%89%89%E2%91%A0%EF%BC%88%E7%9F%B3%E8%A3%BD%EF%BC%89&file=/data/obj/prof/0346.prf) it is. It seems to be in the right place, but I've never noticed it before when making maps.
EDITED: There are actually two sets of 3d coordinates for everything in the MPX data. Probably there is only one in the MPX files. I wondered why this was. Now I suspect that there is probably a CP based center point stored in the odd set. Probably for doors alone. Its just a guess, because I can't see things working as well as they do any other way. I think that may be what makes the event activation subroutine different, if so. If I determine this to be the case, I'll probably just change the event activation subroutine to use the CP as center. If there was a bug in the box dimensions I'd not be surprised if there is another bug of this kind in play.
I won't hazard to guess that the MPX data is the same for objects, NPCs, and enemies, but for NPCs (and enemies) it would make sense if the extra set was a spawn point.
Just kidding. Seriously, I want a door from scratch. You'll need x2mdl, cpgen, and probably that Somimp thing to see where the CPs are in the door models. If you don't know what these tools are, read no further.
I know people are making games with custom pieces, and you can't very well make games without doors. So sooner or later one of you guys will need to figure this out either way.
But here is why I need it. Actually I don't need the door. I need to know how the doors work...
Long story short, we (inc. Verdite) were working on adding ladders to SOM. The ladder model had a problem, in that you could activate its event from no less than 5 meters away. Verdite figure out that was because the distance was based on the height of the object. I worked out it was 1.75 plus half the height. So tall skinny things were totally out.
I'd been meaning to work on localizing the activation of things so that climbing would not feel so different from activation (SOM lets you activate things from ~2 meters away, which is like if you had tentacles instead of arms)
I sunk a lot of work into this. Its one of the biggest projects I've ever done for SOM. Clearly it may as well had been a bug. But it turned out that it actually was a bug. What happens is the height is used where the depth should be used instead.
It's a bug you could fix by hexediting one byte of the game program files, but I don't want to encourage that. PM me if you want it.
For events, SOM actually bases activation on the box dimensions; edited: rotation along height only I think. But for doors and things, everything is treated as a cylinder. And not in a clever way. Because I did run into trouble with the tombstones, because they are rectangular, where the radius was not reaching the front and back when activating with a more modest distance than 2 meters.
So I got the clever idea of routing everything through the event subroutine. This worked well for now, since I am sick of working on this (its been like a week) and really don't feel like programming everything from scratch as good as it could be. Even though that will probably be done eventually.
So now tombstones work well. But there is a remaining problem in that many doors will only easily open from one side. So I am not routing the doors. I will probably just replicate what SOM does for the time being.
The reason this seems to happen is many doors are not centered in the PRF shape. I would not be surprised if none of them are. If only so when you add them to SOM_MAP they will fit snugly into the doorways without adjustments.
At first I thought doors used the cylinder shape. But only the double doors seem to do that. The others seem to use boxes. I don't know why, but boxes would be ideal. If that was they were centered; edited: and actually used. I thought because they were using cylinders for activation that the many control points in the door MDO files were being used for clipping. But I think I've noticed when pushing into the doors that some seem to have a cylindrical shape, so that you can get closer on the edges than you can in the middle.
Anyway, finally. There seems to be at least 3 kinds of doors. B, D, and E. I can't think why any of them would be necessary, other than maybe 2 kinds to mark a door as see through. I would not be surprised if the opening and closing clipping is built into SOM based on the door types and dimensions and maybe the shape too. Only because I can't think of reasons to have more than one kind. The 82nd byte of the PRF file has B, D, or E. Never seen a C. A is lamps. The next highest thing is 14.
Regardless, its not possible to activate doors in the best way possible without knowing their true shape.
PS: I noticed today a stone door that seems to slide sideways. It was in the database at \<span> site blocked, contact your administrator. It's probably a set that is not where its supposed to be. Probably because it was decided not to include it in the final product. May have been a test door. Anyway, that could be C. Or at least, its a new kind of door. Here (\<span> site blocked, contact your administrator/wp-admin/admin.php?page=database&home=pc&view=/obstacles/doors/%E6%A8%AA%E9%96%8B%E3%81%8D%E6%89%89%E2%91%A0%EF%BC%88%E7%9F%B3%E8%A3%BD%EF%BC%89&file=/data/obj/prof/0346.prf) it is. It seems to be in the right place, but I've never noticed it before when making maps.
EDITED: There are actually two sets of 3d coordinates for everything in the MPX data. Probably there is only one in the MPX files. I wondered why this was. Now I suspect that there is probably a CP based center point stored in the odd set. Probably for doors alone. Its just a guess, because I can't see things working as well as they do any other way. I think that may be what makes the event activation subroutine different, if so. If I determine this to be the case, I'll probably just change the event activation subroutine to use the CP as center. If there was a bug in the box dimensions I'd not be surprised if there is another bug of this kind in play.
I won't hazard to guess that the MPX data is the same for objects, NPCs, and enemies, but for NPCs (and enemies) it would make sense if the extra set was a spawn point.