Is the player facing water? Cuz fishing without water is sil : IV

» Thu May 03, 2012 1:19 pm

Hi folks.

After a little hiatus, I'm back in Oblivion. I spent a week or two of evenings updating my load order, getting all the new utilities (DLL?! Neat!) and finally got to playing. I was running along the other day, further beta-testing my cooking mod on the side, when I realized I needed a fishing mod to help make the ranger character experience complete. I quick search turned up some hits, but nothing to my liking. So I've made my own.

I've got it working well - including a filter patch to understand fish from other mods, and give them appropriate meat if they lack it - and I'm pretty happy with the result. BUT! (and here's the catch) I can't figure out a way to determine where it's appropriate for the player to fish.

I tried GetCrosshairRef but that of course doesn't see the water shader. I tried doing things like comparing the water level in a cell to the player's Z position, but that's fraught with innaccuracies. I even tried (after peeking at http://www.tesnexus.com/downloads/file.php?id=7857 from 2006) to toss a miniturized critter in front of the player and test if it's swimming, but that failed as well.

So I'm appealing to my fellow modders for ideas. I'd hate to have to keep this a personal mod exclusively for my own RP purposes...

» Thu May 03, 2012 1:19 pm

GetParentCellWaterHeight is the way to go for that. You'll have to build in a few checks though (especially for dungeons).

» Thu May 03, 2012 9:09 pm

I am quite certain the falling creature works, if your scenario allows for waiting a couple of seconds.

What was the problem with this approach?

» Thu May 03, 2012 7:17 pm

GetParentCellWaterHeight is the way to go for that. You'll have to build in a few checks though (especially for dungeons).

The problems with GetParentCellWaterHeight are manifold. First off, you have to check if the player is within a hundred or so units of the water level, and it's entirely possible to have cells with the water near the "surface" but never visible. Second, assuming the player is actually near visible water, is he facing it or is his back to it? There's no way (that I know of) to determine where the land/waterlevel boundary exists, assuming it exists at all (see point one).

The dungeon issue is easy: only let the player fish out doors/not in cities.

I am quite certain the falling creature works, if your scenario allows for waiting a couple of seconds.

What was the problem with this approach?

Maybe I wasn't waiting long enough - it was probably only a few frames. The general approach was:

have a ref creature stored in a temp cell: a tiny mudcrab copy, though in retrospect I could use a normal mudcrab copy and set it's alpha to 0
move it to a couple hundred units in front of the player: my knowledge/memory of trig from high school is extremely weak, so to do this I was using code I snipped from Wrye's Summon Bed mod, the same code I used in my Summon Luggage. Maybe that was the problem
wait a few frames and see if ref.IsSwimming: never got a positive result
move the ref back to the temp cell so nothing kills it

I culled the code

but maybe I should put it back and try waiting longer and see what happens.

» Thu May 03, 2012 5:10 pm

You might want to have a look at a mod called Basic Primary Needs (the drinking water part), which should give an idea on how it could be done with GetParentCellWaterHeight.

» Fri May 04, 2012 4:22 am

Played a little bit with an old code of mine and came up with this:

aaqqxxDog.enableaaqqxxDog.call zuRefPositionInFront playerref  150 120

aaqqxxDog is a scaled down dog without packages or factions.

zuRefPositionInFront positions the dog at eye level, 150 units in front of the player.

Spoiler

scn zuRefPositionInFront;---------------------------------------;			   Positions a ref dis units in front of an actor/reference, dposZ is the Z difference;---------------------------------------float angfloat disfloat posXfloat posYfloat posZfloat dposZfloat angZref refMarkbegin Function {refMark dis dposZ}																																																												call zxLog 101 "Function started"				if refMark.isininterior								if GetInSameCell refMark == 0												moveto refMark								endif				else								if GetParentWorldspace != refMark.GetParentWorldspace												moveto refMark								endif				endif				let angZ := refMark.getangle Z				let ang := call zuAngleTrig angZ				set posX to refMark.getpos X + dis * cos ang				set posY to refMark.getpos Y + dis * sin ang				set posZ to refMark.getpos Z + dposZ				setpos X posX				setpos Y posY				setpos Z posZ				setangle Z angZend

The dog script keeps track of the fall and detects when it stops

Spoiler

scn aaqqxxTestDogSCRIPTarray_var cosCheckarray_var oActorref refactionref refSelffloat posXfloat posYfloat posZfloat posXprefloat posYprefloat posZprefloat dposXfloat dposYfloat dposZfloat dis			  float disminfloat dismaxlong i																																																																												  float tTimershort bDone																															  begin gamemode				if getdisabled								set refself to 0								let tTimer := 0								RETURN				endif				let posX := getpos x				let posY := getpos y				let posZ := getpos z				if refSelf == 0								let posXpre := getpos x								let posYpre := getpos y								let posZpre := getpos z								let refSelf := getself																																																												call zxLog 0 sv_construct "Reset"				;;			 RETURN				endif				let dposX := posX - posXpre				let dposY := posY - posYpre				let dposZ := posZ - posZpre				let posXpre := posX				let posYpre := posY				let posZpre := posZ				let dposX := abs dposX				let dposY := abs dposY				if dposZ > -1								let tTimer += getsecondspassed				else								let tTimer := 0				endif				if  dposX > 1								let tTimer := 99				elseif  dposY  > 1								let tTimer := 99				endif				if tTimer > 1								;=== Dog stoped ===								let i := aaqqxxDog. IsSwimming								printc "IsSwimming: %g" i								if IsSwimming												; There is water in front of the player								else												; There is no water								endif								set refself to 0								let tTimer := 0								disable								moveto aaqqteXMArrival				endif				resetfalldamagetimer				ResetHealthend

» Thu May 03, 2012 10:46 pm

You might want to have a look at a mod called Basic Primary Needs (the drinking water part), which should give an idea on how it could be done with GetParentCellWaterHeight.

Sure, I'll have a look, but I suspect from the description that it's all about GetCrosshairRef on fluid-bearing statics (fountains, wells, etc).

edit: Just had a look, and I stand corrected: there is indeed a GetParentCellWaterHeight aspect in addition to checking statics. Quite brilliant, actually: he's checking player positon vs water plane position and factoring in player viewing angle vs terrain height where the player's looking and also aborting if there's an object in the crosshairs. That does a good job of filtering out looking the wrong way or drinking from rocks, but I don't think it'll help me because I need to be able to accomodate things like fishing while sitting on a rock or standing on a dock - so working in the player distance vs the waterplane level would be tricky - and looking straight down at the water isn't realistic for fishing either.

Played a little bit with an old code of mine and came up with this:

Thanks! I'll give this a try.

» Thu May 03, 2012 10:10 pm

Oops, there's a couple of function calls that I don't have code for, QQuix. I assume zxLog is your personal debugging/logging function and can be removed, but what about zuAngleTrig?

» Thu May 03, 2012 7:27 pm

That does a good job of filtering out looking the wrong way or drinking from rocks, but I don't think it'll help me because I need to be able to accomodate things like fishing while sitting on a rock or standing on a dock - so working in the player distance vs the waterplane level would be tricky - and looking straight down at the water isn't realistic for fishing either.

tbh they're pretty minor issues. Sitting on a rock will change the player height a little and can be checked. The looking straight down at the water isn't required. You can easily remove that check. It just isn't realistic to drink water while not looking at it. Anyway, the other option, dropping stuff in the water, would probably work ok too.

» Thu May 03, 2012 1:56 pm

Ooops, missed those.
Yes, zxLog is a debugging function and can be discarded (I usually place debugging lines 15 tabs to the right so they don't clutter the real code, so I missed those)

zuAngleTrig is a function to convert Oblivion angles to trigonometric angles. Here it goes:

Spoiler

scn zuAngleTrig;--------------------------------------------;			   Converts Ob angles to Trig angles;--------------------------------------------float pAnglefloat xAnglebegin Function {pAngle}	if  pAngle <= 90		let xAngle := 90.0 - pAngle	else		set xAngle to 450.0 - pAngle	endif	SetFunctionValue  xAngleEnd

Something I failed to mention: if you use this approach make sure the creature is moved to a different (dummy?) cell at the end and moved back the next time. The game does not like moving actors that are swimming: if you move a swimming creature, it keeps the animations and loses havoc, i.e. it stays swimming in mid air wherever you move it. Moving it to a different cell and back resets and fixes this.

Interesting solution, the one from Basic Primary Needs. It has the advantage of no need to wait for the end of the fall.

» Thu May 03, 2012 11:48 pm

Ooops, missed those.
Yes, zxLog is a debugging function and can be discarded (I usually place debugging lines 15 tabs to the right so they don't clutter the real code, so I missed those)

zuAngleTrig is a function to convert Oblivion angles to trigonometric angles. Here it goes:

Yeah, I poked around on the Wiki and ended up finding the answer on your talk page. Thanks!

Something I failed to mention: if you use this approach make sure the creature is moved to a different (dummy?) cell at the end and moved back the next time. The game does not like moving actors that are swimming: if you move a swimming creature, it keeps the animations and loses havoc, i.e. it stays swimming in mid air wherever you move it. Moving it to a different cell and back resets and fixes this.

Thanks. I didn't know the details, but I have an xmarker in the actor's original cell that I move it back to just as a "best practice" sort of thing.

Interesting solution, the one from Basic Primary Needs. It has the advantage of no need to wait for the end of the fall.

Yes, and it works quite well. Unfortunately, it's very plausible that the player won't be looking at the water when fishing, and I don't know how to do the math for accounting for the player standing relatively far above the water line yet still near the water/ground boundary. I think I'll include a check to keep you from fishing off a 100-foot high cliff though; that should be something easy like

if (GetParentCellWaterLevel - player.GetPos Z) > 1000

» Thu May 03, 2012 9:00 pm

Can't you require that the player must be looking at water only at the moment he tosses the pole?
If you do the water detection at that moment, the player may look somewhere else from then on.

The math would be the same, no matter how far the player is from the water surface, I guess.

But the complex part is that you have to consider that the water and the player may be in different cells (and water heights may be drastically different from cell to cell in mountain areas)

» Thu May 03, 2012 3:49 pm

But the complex part is that you have to consider that the water and the player may be in different cells (and water heights may be drastically different from cell to cell in mountain areas)

Zoinks! I hadn't even considered that. Part of me still wanted to try the mathematical approach, as it seems more elegant, but now I'm 100% convinced that the swimming actor test is the way to go. I should be finished working on it this evening and I'll report back.

» Fri May 04, 2012 2:05 am

I know this is dumbing it way down, and requiring you to manually add a lot of points to the game, but had you thought of manually placing some sort of fishing nodes? I don't have any modding experience (as you can tell) but i'm thinking back to world of warcraft and their "schools of fish" that you could see swimming in a tight circle along riverbanks/coasts. That would also be an easy way to determine the type of catches you could get, though I guess you could simply use cell ids to do that as well.

» Thu May 03, 2012 10:59 pm

I've got the "okay to fish here" aspect working fine now - thanks QQuix!

As for determining what can be caught where, I've got a filter patch that adds fish creatures from various mods (and as a filter patch, it works no matter what is installed and what's missing from its masters) to a levelled list. I then check against that list to see if nearby creatures qualify as fish, and if so, one of those is what you catch if your attempt succeeds. If there are no fish nearby, you can still try but the chance of getting something (again, pulled from the merged list) is lower.

Once I get the meat of it all working, I'll add in some user customization options via ini: base chance, base chance without fish creatures nearby, diminishing returns for overfishing a spot, stuff like that. Also in the back of my mind is stuff like adding a tiny chance of pulling up something other than a tasty fish - a soggy old boot, a treasure chest, a nasty critter...

Oh, and the filter list also is used to add meat ingredients (defined in my mod) to fish that lack it. After all, why else would you fish?

» Thu May 03, 2012 7:51 pm

Hah, you didn't happen to play Ultima Online back in the day, did you?

If not, here's a link that might give you more fishing loot ideas:

http://uo2.stratics.com/skill-guides/skills-and-professions/fishing

» Thu May 03, 2012 1:57 pm

Can't you require that the player must be looking at water only at the moment he tosses the pole?
If you do the water detection at that moment, the player may look somewhere else from then on.

The math would be the same, no matter how far the player is from the water surface, I guess.

But the complex part is that you have to consider that the water and the player may be in different cells (and water heights may be drastically different from cell to cell in mountain areas)

I don't think there are any situations this would ever become an issue. This because of the target, player, land and water height checks.

Just for a bit of fun I'll have a little go at making a fishing mod. Would be interesting to see how hard it would be to add the aspects of UO fishing (and WoW). Might include treasure hunting (with the leveled maps) at the same time, heh.

» Fri May 04, 2012 12:25 am

Hah, you didn't happen to play Ultima Online back in the day, did you?

Oh yeah... waaaay too much.

I don't really want to turn a simple immersion/survival support mod into a treasure/quest mod. But we'll see.

» Thu May 03, 2012 8:45 pm

I've been thinking about this water detection, gave it a try and the code turned out quite small and accurate (accuracy of a few inches)

I don't think there are any situations this would ever become an issue. This because of the target, player, land and water height checks.

There are two situations where this may be a problem: take cell 8,2 (near the Charcoal Cave), for example. It has a water height of 3,500 while all the surrounding cells have water height = 0.

If the player is at the edge of cell 7,2 facing the lake in cell 8,2, you would take the player cell water height (zero) and conclude that the water is way below the ground level.

On the other hand, if the player is in cell 8,2, but at its edge facing away from the lake and enjoying the view of the Imperial City, you would take the player cell water height (3,500) and conclude that there is water in right in front of the player (well, the crosshair is pointing at water, but a mile away down the mountain).

Same thing at the edge of cells 35,-1 and 34,-1

I think I have figured out the math to account for this. I will try it tomorrow.

» Thu May 03, 2012 3:13 pm

I've been thinking about this water detection, gave it a try and the code turned out quite small and accurate (accuracy of a few inches)

I think I have figured out the math to account for this. I will try it tomorrow.

Cool! Though you don't need to trouble with it if you don't want to... I've got the swimming creature method working well. I understand the need to solve a challenge though. :toughninja:

» Thu May 03, 2012 10:07 pm

. . . I understand the need to solve a challenge though. :toughninja:

Pretty much this . . .

» Fri May 04, 2012 2:59 am

I've been thinking about this water detection, gave it a try and the code turned out quite small and accurate (accuracy of a few inches) There are two situations where this may be a problem: take cell 8,2 (near the Charcoal Cave), for example. It has a water height of 3,500 while all the surrounding cells have water height = 0. If the player is at the edge of cell 7,2 facing the lake in cell 8,2, you would take the player cell water height (zero) and conclude that the water is way below the ground level. On the other hand, if the player is in cell 8,2, but at its edge facing away from the lake and enjoying the view of the Imperial City, you would take the player cell water height (3,500) and conclude that there is water in right in front of the player (well, the crosshair is pointing at water, but a mile away down the mountain). Same thing at the edge of cells 35,-1 and 34,-1 I think I have figured out the math to account for this. I will try it tomorrow.

I just checked those 2 places, using BPN to show the water on screen and it's pretty much impossible to notice. However, you could probably just use an activator or whatever on the target location and check for water height with that, rather than the player.

» Thu May 03, 2012 10:45 pm

The problem is that to do the necessary math and determine the target location, you need a horizontal plane. So you start with the player's cell water height.
You take the player line of sight as a straight line and calculate where that line crosses that horizontal plane.
Within the same cell, all is OK and you can determine if, at that crossing point, the ground is above or below the water plane.
But if that point is in a different cell and that cell has a different water height, you have to start over, as you did all the calculation based on the wrong horizontal plane.
And so on, and so on, . . . (worst scenario, imagine the player looking down a staircase and you have to calculate at which step the player is looking)

Anyway, the more I think about it, the more difficult it gets (to devise an all-situations-covered, I mean)

» Thu May 03, 2012 4:17 pm

Yeah, like I said, the math scared me from the start. If it scares you then I know the swimming critter method was the right way. And it works fabulously. I may tweak it a bit to better accomodate fishing from a dock or a rock on shore, but I'm getting good results so far.

http://img543.imageshack.us/img543/3006/stilltimewellspent.jpg
http://img269.imageshack.us/img269/1408/tgetaway.jpg
http://img822.imageshack.us/img822/5834/agoodafternoon.jpg

As a side note, my crosshair was on the rocks in the distance - well above the waterline.

» Thu May 03, 2012 6:09 pm

Well done, Tekuromoto. And welcome back!