I need a custom door proof of concept

[Holy_Diver]

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.

[Holy_Diver]

BTW: One thing that is very strange about doors in the database there is their center is nowhere near where the door is. If you spin them they don't spin so much as move sideways around an empty space like it was fighting a monster in a KF game.

This is really unusual because the models are recentered based on the furthest out vertices, and control points should get filtered out so not to count against the limits. I am pretty sure base CPs are not considered center points. So I can't think of any reason for the doors to act this way.

I would guess that their animation moves them away from their original center. But I don't think that is possible because SOM_MAP doesn't take the animation into account, so if that were the case the door wouldn't be where you placed it in game.

So in conclusion it seems like something weird is going on. The only thing I can think of is a new kind of control point or a bug in the control point filtering when calculating the boundaries. If there was just blacked out triangles you can make those visible in the database preview. I don't see anything.


EDITED: If I had to guess I suspect that SOM_MAP does some special adjustments to the doors based either on their CPs. Or the extra data in the PRF file after the 82nd byte (the last byte turns the XZ rotation lock off; that still leave 23 bytes unaccounted for with no obvious purpose. Edited: the 82nd byte is actually 2 bytes just for the record. Its 16bit that is)

[Holy_Diver]

I did some more tests with the wooden swinging door.

It doesn't have different values in the two sets of 3d location coordinates. But I can see what animation it is doing and a timer while it is waiting to begin closing. But the time of the animation is nowhere nearby.

It has a box shape, or it should if doors are like other objects PRF wise. It has all 3 dimensions filled out. Still with a 0 sized player radius, its pretty obvious that the clipping follows a cylindrical shape. A very pronounced one at that, which is not centered. In other words one side of the door will not let you get as close.

But what is weird is I can walk inside the door from the sides. I don't think any other kind of object would allow you to do that. And also I can slip behind the cylinder by coming at the sides from an angle, but still not go through the door.

To me all of this suggests that there is probably something to the control points in the doors. Or at the very least a complex shape is being used where it depends on which side of the door you are on.

Finally while the door is moving the cylinder seems to move with it. I don't think that can be done without a base CP or making some broad assumptions about the door animations.

[dmpdesign]

Another optional and fairly easy bandaid for your climbing problem is just to put a textureless model at the base and top of the ladder to interact with, as just an invisible event holder.

I sure hope you can fix the issues SOM has with going up and down though, any movement in the vertical direction above a crawl I found causes you to fall through objects or be pushed to the side of the object.

[Holy_Diver]

Another optional and fairly easy bandaid for your climbing problem is just to put a textureless model at the base and top of the ladder to interact with, as just an invisible event holder.

Well the ladder system is already cumbersome in that you must setup at least one event. We really don't want to be using dummy objects for anything after all. Activation is very tight now except for doors.

One thing I wonder is if the reason so many objects that come with SOM do not have correct heights is because the artists were working around this bug. I wouldn't be surprised if its a bug in King's Field games. So much of SOM's bugs are present in the PlayStation KF games. Its really like the source code was just ported over to SOM in a rote fashion. I know that if it wasn't SOM would've been a really big project. I bet the SOM tools are even very much like the tools From' already had for developing KF games.

We probably wouldn't have SOM if someone hadn't decided to take all of their in house tools and repackage them for consumers. It would have just cost way to much to develop SOM from scratch. There's really a lot to it.

I sure hope you can fix the issues SOM has with going up and down though, any movement in the vertical direction above a crawl I found causes you to fall through objects or be pushed to the side of the object.

What do you mean by this? There are problems where you pop away at times. I see them more in custom MHM files. I think we don't really understand MHM files. They'll need to be exported to figure out what they are supposed to look like. SOM has very steep slopes you can walk up without problems.

There is gravity now. So you fall much slower for the first few milliseconds. That might help. But after a while you are falling much faster than SOM's constant terminal velocity of 6m/s. I haven't fallen through the floor yet.

There does seem to be a bug around walking into ceilings. There is definitely code that keeps you under a ceiling. But the heights are calculated wrongly so that you either go through the ceiling or can't get close to the ceiling. It will need some work.

[Holy_Diver]

There definitely seems to be something different about doors.

One thing I just noticed. With the short double stone doors, you can get a lot closer to them than other doors. And on one side when up against the door you are actually standing behind its center point. So the usual logic of not being able to activate things that are behind you fails.

I can't think of any way to handle this case. And I can't think how SOM does it. But it seems to be doing something to let the door open. I didn't think doors were treated any differently from the other props with benefits, but I will have to trace through the code and see if it does indeed treat doors specially.

Anyway, what I think this does indicate is that the clipping for doors must be entirely custom. Probably based on all of those extra control points in the door MDL files (which makes me wonder if any MDL object can benefit from custom clipping shapes. Any object that mimics a door should certainly be able to anyway)

But its still possible that the clipping is built in based on the type of door (there are a few different types as explained) but if so it doesn't really explain why the clipping is so different for this particular door. Whereas a funky MDL file easily would. That said this door uses the E type, which is pretty rare among doors from what I've seen.

[HwitVlf]

Have you tried swapping the CP file between two different types of doors to see if the collision movement changes with the ‎  new CP file? I seem to remember doing this and ‎  finding that it did.

[Holy_Diver]

No, but that's what I would expect. I tend to delegate anything that involves messing with files (short of hexediting them)

I do think the time has come to figure out doors. Not sure why its taken this long. You might find out that there is a way to make objects with irregular clipping models. Which could be really useful in the short term.

I do intend to load that door up in a test map I have with just a door in it today or tomorrow. I would like to figure things out so I can deal with that scenario where the door wont open from right in front of it from one side. I don't think many doors work that way, but an outstanding bug is a bug. Plus it would be nice if you had to get closer to the doors to open them up.

[Holy_Diver]

I was thinking, I wonder if the door system is robust enough to do a drawbridge. That is a door that opened vertically and swept things out of the way.

In which case if so, it stands to reason that you could make an object that could represent steps. Or rather a ramp. Which would be pretty handy, because the current solution I've seen games using is making each individual step an object. And A) that's really not fun to do. And B) the steps are going to be really bumpy, instead of proper steps you can walk up as an incline.

Not to mention that you're tempted to skimp by making the steps cyclopean since that is less work and keeps the object count lower. Never mind that each step must be processed individually.

[HwitVlf]

Does mdl2x have an option that exports CP triangles? Last time I used x2mdl, it had issues with the ordering of the triangles which made things not very user friendly. Since doors are all going to be rectangles, it might be easiest to export an existing Door's CP triangles and resize them to match the custom door model.

That's assuming the CP triangles are what set a door's collision shape, and I'm pretty confident that is the case.