(Cross-posted, hope nobody minds )

Hey all. I've been tinkering with writing a portal renderer over the last couple months, and it's now starting to evolve into an actual JK clone. I've got world rendering and thing rendering working pretty well (I get about 60-100 fps on my GeForce2 Go), so now I'm trying to make a foray into some of the physics. I know that this is the place where Sith2 got bogged down, and if Jon`C and company can't figure it out, I don't know what hope I have, but I figure I might as well give it a shot.

I've run into a couple questions that I can't seem to find clear answers to in the JK Specs, so I thought I'd post them here to see if any of the old wizards have run across answers during their time editing JK. Any help would be greatly appreciated.


1. Are things like walk/run speed and crouch height specified in data files somewhere, or are they simply hardcoded?

2. If a surface is flagged as floor, is there some angle above which you will still slide down it? Or can you just walk up a floor that's sitting at 89.9 degrees?

3. Do thing collisions use sphere radii as specified in the 3DO file, or do they somehow make use of bounding boxes as well? I can see that JED shows bounding boxes for templates in the template creator--where does it come up with this information? I can't see anything in the template section of the JK Specs that would indicate that bounding box information is specified.

4. With regard to sphere-based collision detection, how does the Radius field in the 3DO file relate to the size/movesize members of the template? They appear to be different numbers (at least for ky.3do vs. walkplayer).

5. When I'm doing POV rendering, how do I determine the height below the camera point at which the player's feet are? Is it just hardcoded, or is it derived from the bounding box of the thing + the eyeoffset in the template or something like that?

6. Is collision detection in POV mode done the same as in 3rd-person mode (i.e. collisions are performed against ky.3do), or somehow different?


I know some of those are pretty obscure, but I figured I'd throw them out there just in case somebody has any idea about them. Also, I'm not sure how far physics development in Sith2 has gotten, but if anybody working on that has any answers, I'd love you forever.

I'm afrade i'm not a programer so i can't help. But still is there some way we can see some of your work?

Why do you wanna know how it was done in JK? I mean, maybe you can do it better?
Anyway:

1) Force speed modifies an actor's speed...should be easy to find out.
2) You can't run up a 89.9° angled surface that is flagged as floor. The angle can be determined by testing.
3) I think JED calculates the bounding boxes using the vertices of the 3do (min/max values of x,y,z). I'm not sure what JK uses...you do know that you can't hit the legs of actors, right? So, the collide sphere/box must be on a strange offset there. I also remember a flag called "face collision"...so it might use the sphere system for quick pre-collide determination, then using surface collision when the flag is set.
4) I'd say the radius file doesn't matter at all. It's probably a leftover. Size and movesize are probably the collision sphere in JKUs. You can test it easily.
5) I think the centre of the thing + eyeoffset determine the camera position.
6) Why should it be done differently? This makes no sense.

Well, I may end up doing things differently, but I figure if I can start by doing things the way that JK does, it'll be a good base to improve upon--I've never done physics before, so I'm sort of learning as I go.

I checked force_speed.cog, it uses a verb called SetActorExtraSpeed(), so it still doesn't say anything about the base speed. There's a template parameter called maxvel, which for walkplayer seems to give a speed about equal to running speed. I'm tentatively hardcoding forward walking as 75% of this speed, and backward walking at 50%, because those seem to be about right. This one's not really a big deal, I was just wondering if anybody knew some definitive numbers.

My main concern is with the collision detection. For walkplayer, the center of the model should be .12 away from the floor, but the size/movesize is only .065. This seems appropriate for what you mentioned about not being able to hit the actor's legs--a .065 radius would go up to the top of the head and down to the waist somewhere. So it would appear that these are used for thing/thing collisions. However, using this radius for thing/world collisions would make the player sink down into the ground (which is probably what happens when you forget to flag a surface as floor--Kyle falls down until his waist is level with the ground). So floor collisions have to be done some other way--perhaps face collision with the 3do? That sounds kind of expensive though. Otherwise, you could just hardcode an offset in, but that gets tricky when you start talking about other actors that are of different sizes. Anybody know anything else?

The other wrinkle is that when crouching, the size of the player needs to decrease, so he can fit through smaller openings. Perhaps this simply decreases this offset to 0, and uses size/movesize straight away.

The base player speed is not hardcoded. The base player thrust is. When you press movement keys, thrust is placed on the player. It is this thrust that results in movement. JK does not use bounding boxes. These are JED creations only. It's really just there for Show Things As... Boxes. There is an angle, but again, this is physics calculated. There's a static drag variable on the player, this is the equivalent to coefficient of static friction as far as I know. So if force of gravity greater than this times mass or some such, and you slide down. (Or your char runs really quickly; depends on speed I think...)

Camera height is like collide radius + eye offset. But it's not actually linear from what I remember. I believe Zeq has tested this, and the camera rotates a bit around the thing center based at eye offset distance. I think...

Collision in first person is the same, however, the weapons are rendered differently so that they always show (they won't collide with the walls) (paint rendering or some such. Full polygons always drawn)

As for kyle vs floor/world, do a search for halucid and player. Should be in JK editing or cog forum... He messed with a lot of those things.

Yeah, the thrust may well be hardcoded, but thrust is equivalent to acceleration, so if you continue to apply thrust, the velocity will just increase without bound. Therefore, there has to be some limitation on velocity.

I found that thread that halucid started, it had some interesting information. It confirms my suspicion that when walking, the collide sphere is raised off the ground by a specific amount, and when crouching this amount is reduced to 0 and the collide sphere alone is used. Thanks for the tip.

The problem I'm facing now is just the insane number of cases to consider in writing the physics engine--things like the player walking up to a stair, for instance. If the change in height is small enough, the physics engine should raise the player up to be level with the new step. But if the ceiling is too low in the new sector, the player should be forced out instead.

Then, adding in thing/thing collisions, how to deal with a player being crushed by an elevator coming down? It will exert a force on the player downward, which the ground will counter, but this should cause damage to the player. Meanwhile, gravity also exerts a downward force on the player, which the floor counters, but this should obviously not cause damage. It's going to be a fun adventure to find a way to reconcile all of these things--writing the rendering engine is starting to pale in comparison. I have newfound respect for the occasional physics glitches in games like JK--even getting something that's close is hard enough.

Anyway, I think I've got some leads to start on now--thanks for the tidbits. If anybody else has any insights (especially anyone from Sith2, who I'm sure have been dealing with these same kinds of questions), please let me know--I'd really appreciate any advice.

I remember something in the 3do called insert offset. Couldn't this be the distance from the ground to the collide sphere of the player?
And the damage is probably chained to speed and mass...gravity CAN cause damage...if the player is falling, e.g.

I hate it when my posts get ignored

There's a ground drag. A friction factor between the player and the ground, and of course, the important maxvel=1.00000 which directly limits maximum velocity to 1 JKU/s. And perhaps something else which I can't precisely recall at the moment.

Zwier Zak--I'll be happy to post this online at some point, if it gets to the point where I feel that it's worth showing to the public. At the moment, that is far from the case--it's still kind of a glitchy, buggy mess. And I'm sorry to say that this does not and probably never will have the visual goodness of Sith2...I just don't have Jon`C and Sige's knowledge of shader programming. This is just a project I'm working on for my own enjoyment, and I make no guarantees that it will ever even turn into anything worthwhile.

In the meantime, the advice from this thread is helping significantly as I start to formulate a coherent plan for the physics. Thanks to everyone for your assistance. Currently, I'm planning to do a system with sphere collision based on the movesize parameter, after shifting the thing upward to ensure that the "foot" point is on or above a floor surface. If shifting needs to take place, the thing is considered attached to the floor surface, meaning that surfdrag becomes valid, and if the force on the player is less than staticdrag, velocity becomes 0.

I still need to do some testing to figure out the offset to the foot point. The thread that halucid started seemed to indicate that this is specified with the height parameter, however neither walkplayer or even _actor has a height parameter specified. Insert offset could be the missing link, so I'll do some checking into models like the AT-ST and the Rancor which walk on the ground but are of different sizes than the walkplayer, and see if I can figure out how to do it consistently. Once that's established, it *should* just be a matter of some really messy vector math to do the actual collision processing. After that, it'll be on to thing/thing collisions, which scares me muy mucho.

Yeah, thing-thing (with face collision) probably involves EVEN MORE messy vector math. Heh. Have fun ;).

Ok, I'm making some pretty good progress here. I've actually managed to get a system implemented that works most of the time, at least as far as thing/world collisions go. A large amount of testing has shown that the surfdrag parameter gets multiplied by the current player velocity, and the result is added to the acceleration in the opposite direction of the velocity, thus acting to slow the thing down. Therefore, the speed which causes this force to balance the applied thrust determines the maximum velocity. It also appears that, if no thrusts are applied (not counting gravity), then the velocity is checked to see if it is less than staticdrag, and if so is clamped to 0.

Collision detection appears to be done as I stated before. I've also confirmed that the insert offset from the 3do file determines the distance between the thing center and the foot point. So I have it offsetting the collide sphere according to the insert offset, and shifting the thing if necessary to ensure that this point is not beneath a floor surface. Then, normal sphere collision detection is done on the thing's collide sphere. This is where most of the bugs still lurk for me--the way that I'm doing sphere/polygon collisions is not exactly right. Still, it's good enough to work for most of the levels in JK. I'll be doing some more revision later.

The one problem I'm still having is reconciling gravity. If I use the gravity field from the level header, then the player falls at the correct speed. However, using this value causes problems when walking up diagonal surfaces--the gravity slows the player down, as it should, however it is much too strong. To get results that are consistent with JK.exe, I have to reduce gravity to about 1/4 of its normal value when attached to a surface. I'm not sure if this is due to a misunderstanding of mine about how world gravity works, or whether this is actually a hack that they put into the game engine.

In any case, it's getting there. I'll continue posting any progress that gets made.

maybe if you become an expert in physics programming, you can sign on to Sith2 XD

^ yeah there is no need to have more than 1 JK 'cloned' engine

hell, you can go to Sourceforge and take everything that Jon`C developed and complete it if your physics coding works. He's given up on the project, but wants somebody to complete it if they can.

He is not working on a project funded by the community. Maybe you don't need another JK clone, but why should he care?

Quite frankly, I'd welcome an alternative to Sith 2. There's been compatability problems, and the thing was fairly slow from all accounts. It doesn't matter if there was a fully functioning clone. If he can do it better then let him. In this case, if he can finish it, he should go ahead.

This project began its life as an attempt by me to write a portal rendering engine. I started using JK level data so I'd have a test environment, but at first I had no plans to actually implement a JK engine. As things went along, I ended up writing a parser for JKL files, and eventually got it reading all of its data out of JK's GOB's. At that point, I started considering seeing if I actually could write an all-out JK engine. I'm still not sure if that goal will come about--several major areas could still pose insurmountable challenges, or I might simply not have time (I'll be moving in a couple weeks and starting a full-time job, so my free time will be severely reduced.) So at this point I refuse to make any committments to finish this thing or release it to the community. It started as and remains a personal interest project.

That said, if I ever do manage to get it completely implemented, to a level of quality that I feel comfortable with, I would certainly release it, if it can be of any use to the community. Just don't hold your breath...things are going strong now, but you saw what happened to Sith2.

Anyway, if anyone's interested, here's an update. It's amazing how much progress you can make if you have a few weeks completely off with no obligations whatsoever. I have implemented the basics of a physics system, and it appears to be relatively stable and consistent. This includes surface collisions, floor attachment and gravity, as well as face collision for things, and sphere collision. There will be some additional work to be done (i.e. water, crushing, and flying things), but there's a good base right now, and the player can walk through the levels pretty much correctly.

COG's are now partway implemented as well. One of my other projects recently was playing with writing a compiler, so I was able to lift a lot of code from that project into this one, meaning that COG parsing and the VM was actually written in only a couple of days. That part's now pretty stable, however I'm now setting to the monstrous task of implementing all the verbs. This one will probably proceed in parallel with the rest of the development of the engine, as COG verbs touch nearly every subsystem. However, I've put in some of the basic ones (e.g. MoveToFrame, GetSenderRef, SetWallCel), to the point where I've been able to get a couple basic COG's like 00_door.cog and 00_std_elev.cog working.

World rendering is practically done, minus a few special effects. I've been tweaking it constantly, and am reasonably certain that I've eked about as much performance out of it as I can. On my laptop (P1.3, GeForce2 Go) I get around 80-100 fps for most places, dropping down to around 50 at places like the tower in level 6. This is consistently better than Sith2 (at least the binary on sourceforge, which I am pretty sure is an old build), and almost on par with JK.exe itself in most places. As I continue to implement the COG's that disable sector adjoins, the framerate might still climb a little here and there, but even on my computer it's satisfyingly playable right now.

As I said, I'm going to keep going on this for as long as I can, but we'll see what happens after the end of next week when I start work. If anyone's interested, I could probably clean some stuff up and post a binary of the engine's current state, if for no other reason than to see how it performs on other people's computers.

Sounds like you're having a good time. If you can take some screenshots, I'd like to see them.

I'd be interested, and I'm sure some others would as well. Sounds like you've made a good bit of progress. Hmm, I'm not sure about that gravity thing. There might be a combination of static and air drag helping keep the player still. JK works by applying the gforce constantly (mass * 4). I imagine surface attachments have some effect similar to a friction effect. Whether that is merely the drag values or not, I don't know. I don't think we really know just exactly the units/proportionality of the drag units.

All right, I have a version of the engine set up for outside use. You can download it here. Controls are as follows:

Arrows - Forward/backward and strafe
Mouse - Look
Right Mouse button - Jump (hacked to allow you to jump even if not grounded, allowing you to fly...necessary since not all cogs are implemented yet.)
C - Crouch
L - Full light
T - Disable thing-thing collisions and impassable adjoins (allows you to walk through doors, etc...also necessary since not all cogs work.)
Space - Activate (most doors and switched elevators, i.e. the ones that use 00_door.cog, 00_doorkey.cog, 00_std_elev.cog, etc. should work)

The program can load any level out of jk1.gob. Specify level name as the first argument on the command line. JK CD must be in the drive...if your drive letter is not D, specify it as the second argument on the command line. Sorry for the lack of a friendly interface...this was just hacked together for a quick exhibition.

If anybody takes the time to play around with this, I'd be very interested to hear some feedback on performance...framerate in various areas, plus system specs. Thanks, and enjoy.

Wow, what a find! (This thread)

I'm glad to see someone has taken it upon themselves to try and unravel the mysteries that are JK Physics. It sounds like you're having a good time.

Jon'C at one point had said that overlapping sectors would totally screw with 'conventional physics systems', but JK.exe has no problem. (A lot of the single player levels have overlapping sectors) Is this the case with your home-brewed code?

I as well would be interested in seeing how your clone matches up with JK.exe. What a shame I didn't stumble upon this thread sooner, as I'm pretty proficient with the inner workings of JK and it's physics properties. I could have probably gotten you on the right track sooner.

Also, Jon'C pretty much has his own Cog VM (I think it is also on SourceForge), and I think (take this with a grain of salt) he's gotten all the cog verbs implemented, somehow.

Good to hear from someone who has some experience with JK's physics. Perusing this thread, do you have any comments on the way I'm implementing it?

I don't think Jon`C's comment about overlapping sectors was meant to apply to all physics processing, but to available third-party physics libraries (ODE, specifically.) There isn't any problem with them in systems like mine, because the engine doesn't check the player against all surfaces in the level, instead it works in a method similar to the portal rendering algorithm--beginning with the current sector, it checks all surfaces against the player, and if any adjoins intersect, it recurses into the new sector and repeats. Therefore, overlapping sectors don't cause a problem because it can't recurse into both sectors.

Regarding COG verbs...I've browsed the source for Sith2, and there are only a handful of verbs implemented--mostly the same ones I've implemented. I know he has an additional project online that's only a COG VM, and that may well have them all implemented in the sense that there is code to respond to them all, but that wouldn't help in implementing them as part of an actual engine. The tough part of getting verbs in isn't actually implementing the verb (all you do for that is add another entry into the parser), the real problem is adding the associated functionality into the engine itself. I.e., adding code that responds to MoveToFrame() is easy, but adding the code that causes a thing to follow a path, update attached objects, etc. is the hard part. So, it wouldn't help to add in an existing VM, because currently my engine doesn't know how to respond to them all. So, as development progresses, and I add things like a sound engine, animation, or (ughhh) AI, I'll be able to add the associated verbs.

Anyway, feel free to download the binary I posted and play with it. I know there are still some inconsistencies in the physics system, but comparing to JK.exe, it seems pretty close. It even malfunctions in some of the same ways, which suggests that they use a similar algorithm. Let me know if you have any thoughts.

lol, I can't believe I missed that post. I spent so much time reading the thread, I didn't bother to refresh it after reading SniperWolfs post.

Downloaded and tried to run, and it performs an illegal operation.

Here's my shortcut:

"E:\Program Files\LucasArts\Jedi Knight\Engine.exe" -09fuelstation.jkl -X

I've tried different variations, like using /'s and taking off .jkl, but no cookie.

Oh, sorry. Lose the -'s completely. I.e. "E:\Program Files\LucasArts\Jedi Knight\Engine.exe" 09fuelstation.jkl X

Like I said, not the greatest UI in the world.

Wow, I'm impressed! I didn't expect to get as far into the fuelstation level as I did. You didn't mention you had the inventory system working. I grabbed the yellow key and voila, first door opened for me.

It seems to be pretty spot on with JK.exe as far as the physics are concerned. I'm not too familiar with the walking speed of kyle, as pretty much everyone has "Always Run" checked. I was also able to move around the actors that were placed in the level, and they seemed to respond accordingly.

As for quirks, well, for one, why require the CD? :p I placed engine.exe in my Jedi Knight folder thinking it'd be fine. Just a little something, no big deal.

Also, I have a two monitor setup, and I noticed the mouse cursor going over to the 2nd one and interacting with my windows over there, heh. There's been a time or two I've seen the mouse cursor in JK, and it is centered at all times, as if JK reads in how far away it moves from the center each frame, does the appropriate action, then moves it back to the center.

I was also surprised to see materials change when I activated switches, and was able to pickup items. So far, it's the most functional JK clone I've seen to date. Good job, keep it up.

Oh, and some bindable keys and mouse sensitivity would be nice.

Awesome...glad you got it working.

The inventory system is just in its infancy...the bins store values, and verbs like GetInv() and ChangeInv() and all that work, but there aren't COG bindings in place yet, so you can't do things like activate items and all that goodness. I was just getting it to a point where the powerup COGs would work. The rest will come in time. But for the moment, things like door keys do function. Also, see my post above about controls...holding down T disables thing-thing collisions, which will allow you to get past the slopy floor elevator in 09fuelstation that's probably currently blocking you.

As far as requiring the CD, I just have it set up that way because I didn't do a full install of JK, so res2.gob isn't on my hard drive. This is pretty trivial to change, and in the future will be made more flexible. I suppose I should do that anyway, since it'd help my load times during testing. :p

Mouse input is currently done using DirectInput, so I don't ever look at the actual mouse position. Until recently, it was done precisely the way you mentioned, by centering the cursor each frame and reading deltas, however I was trying to see if DirectInput would offer any advantages as far as sensitivity and smoothness. It doesn't really seem to, but when this gets to the point where I start worrying about actual responsiveness, the flexibility might be useful, so I'm going to leave it as is. I'll uncomment my cursor-centering code from before, though, so that that doesn't happen anymore.

Bindable keys and mouse sensitivity? Ha. Come back in about six months. This code is hot off of the workbench, there's no chrome to be found here.

What kind of framerates are you getting?

I just tested it and was very impressed.
Your gravity is even better than JK's in
my opinion. This is excellent. Good job.
Sorry I'm not too much help though just
because I have little programming
experience and know very little compared
to some people on this site. This is
very neat though. It's just what it says
it is, a JK clone.

Very nice demo. I get a constant 60fps, with no fluctuations at all. I got an Athlon64 3200+, 1GB RAM, GF6800GT.

One detail I noticed: the powerups can block your way, when you cannot pick them up. Like when you got 200 shields and an armor vest is in the middle of a low shaft. You can still move it, but I think it should be set to "no collide".

Zagibu--you probably have your computer set to Vsync, which is why you're only getting 60fps. I haven't looked into how to tell OpenGL to change that setting yet, so it uses the default for the computer. If you shut it off in your system video settings, it'll let it run as fast as it's capable, which on a 6800 should be ridiculous.

I'm aware of the powerup collision thing--I'm not quite sure how that's handled in JK--does anybody know if there's some kind of template option that is used to disable collisions for powerups and other things that shouldn't interact with the player? The problem is that it should still detect that they're in contact, and send a touched: message to the powerup's COG, but it shouldn't actually apply counterforces to the objects like it does when two actors collide.

Another question for the editing gurus--I'm working on sound now, and am a little unclear how the minRadius and maxRadius parameters are used. I'm assuming if the sound is closer than minRadius, it's at full volume, and then the volume tapers off until maxRadius, at which point it's 0. My problem comes when parsing function calls or soundclass entries in which these members are missing, or are -1. Anybody know what kind of defaults JK uses for this case?

Your assumptions about the sound radii are correct. I'm unsure what the defaults are, however. This could probably be found by examining the memory linked to a sounds track in JK.

I imagine the collision behavior is caused by type=item in a template. Someone else can test this, but nothing else in the template seems to be responsible, so I'd guess this is the cause for the behavior.

I thought there was a collide flag, which could be set to no, sphere or face collision. Also note that the values for sound radii are not in JKUs. They are almost in meters, just off some little fraction, IIRC. I think default values are around 5m for min and 25m for maxradius. I usually kept the sound radii at default, and this is how I remember them being. Maybe a more modern approach of 2m/50m would be better suited?
I'm not sure about V-Sync. I have set my monitor to 75hz refresh rate, but it could be the stupid windows cap. Gotta install rivatuner again.

There is a collide flag, and it must be set as sphere so that collision between the player and powerups work correctly when the player picks one up. It most likely is the type=item entry in the template that disables counterforces--thanks. Incidentally, I'm not sure if this is old news or not, but I managed to figure out the difference between size and movesize. Movesize is used for counterforce collisions, i.e. it's the size of the "solid" sphere that is used for collision purposes. Size is used for determining when to send touched: messages to COG's, so it's the virtual "bubble" around the thing.

It would make sense for the sound units to be in meters. I've found a couple other measurements so far that are clearly not in JKU (mostly speeds on scrolling floors and moving things), however dividing them by 10 seems to give the right value. Since Kyle is .185 JKU tall, this would make .1 JKU about 1 meter. I'll update the sound processing accordingly, and use the defaults you mentioned.

1 JKU IS 10m. But sound radii are not exactly 1/10 JKU. They seem to be a bit off (more like 1/10.5 or something). And I guess you are right about the sizes...the seqcharge should have a small movesize and a large size (to trigger the charge from a distance).

Along with a few other JK editors, I have also done some tests with JK templates, physics, and other miscellany.

I have been deciphering the DirectPlay network messages that JK passes between players. In the message that corresponds to PlaySoundThing(dismountSound, player, 1.0, -1, -1, 0x80), the numbers 0.5 and 2.5 are used. In the message that corresponds to PlaySoundPos(on_snd, SurfaceCenter(switch), 1.0, 5.0, 10.0, 0), the numbers 0.5 and 1.0 are used. Both sets of numbers seem to match up with what the DataMaster labels minrad and maxrad. So, my guess is that 0.5 and 2.5 are the defaults, and that the arguments given are divided by ten before being used by the engine.

There is such a collide flag. However, for items, it's set to sphere collision. So something has to be preventing the physical collision while allowing the touched message to be sent. Which is where I believe type=item is playing a role.

ZeqMacaw--ooh, this is good stuff. That is very very helpful. Having played around with some stuff now, it looks like the numbers given in the .SND files are in JKU--I tried dividing them by 10 and things got quiet way too quickly. However, COG verbs could certainly be dividing the numbers down. I'll put them in and see if it makes any noticeable difference one way or the other. Zagibu--does this jive with your experience? I.e., were you referring to the radii given in the .SND files, or just the parameters of COG verbs?

Also, Zagibu--have you by chance looked at the DirectPlay commands for MoveToFrame or SlideWall? If so, is the speed parameter also divided by 10? I've determined that it must be at some point along the chain, I'm curious as to whether it happens internally in the engine, or in the COG parser.

I was just talking about verb parameters. I can't remember the .snd values, sorry.

And it was Zeq who looked at the DirectPlay messages.

Oh, my bad. Wrong Z.

Ok, so sound has proven suprisingly easy. It's still not complete, but I've got a pretty good chunk of the sound engine working. This includes the COG Play*() commands, sector sounds, as well as some of the Foley in the SND files (walking, jumping, landing, as well as startmove, moving, and stopmove for elevators and doors.) The above link (here) has been updated.

Yes, I have looked at MoveToFrame. The speed argument divided by ten is sent in the related DirectPlay message.

I have not looked at SlideWall, yet.