Patrick Rannou

How IMHO it should be fixed:

At moment of teleportation:

• Memorize player coordinates and full orientation.

• For BOTH entrance and exit portals:

– Determine portal shape, making a list of all Portal blocks for both portals, aka 'the lists'.

One list for the entrance portal, one list for the destination portal.

– Determine portal's orientation (EW or NS?)

– Determine the portal's "primary direction" as follow:
— Determine what are the portal sides A and B that will be checked:
If orientation is EW: then A is East and B is West; while if orientation is NS = then A is North and B is South.
— For each of the portal's portal blocks in 'the list', check the blocks on side A and on side B, sum up how many are "air" blocks in A_count and B_count.
— Determine which if the portal's sides is the "main" side:
> If A_count > B_count, then main side is side A
> If A_count <= B_count, then main side is side B
(thus, in case of a tie, the south-West rule applies: West wins over East, and South wins over North).

• From this primary side, you can then determine which half is the "leftward" side and which half is the "rightward" side.

• We now know what are the "primary" sides for both the entrance and the destination portals:
  DELTAANGLE = entrance portal's main side's angle + 180 degrees + destination portal's main side's angle

• On teleportation, Player's XZ body orientation, horizontal viewing angle, and horizontal movement direction, are all be adjusted by DELTAANGLE,
  then modulo 360 degrees on each of the 3 values.

IN OTHER WORDS:

If player enter some portal by the side with the least obstacles (no matter portal shape and size), he will also exit by the destination portal's by the side that also has the least obstacles. If player enters portal by side with more obstacles, then same thing he exits on side with more obstacles.

Also, if you enter by strafing or walking backwards, then you also exit by strafing or walking backwards. Relative angle is preserved.

THEN:

• Now, while we parsed 'the lists', we also took note of which coordinates indicate the topmost, bottommost, leftwardmost and rightwardmost blocks.
  Basically, getting the "width" and height" of both portals and they start/stop coordinates along width and height.

• We reduce width and height values by player model's width and height (respectively).

• Using start/stop coordinates we find the "center" of entrance and destination portals.

• With the above data, we can now determine, in terms of percentage, where the player was (right before teleportation) relative to entrance portal.

• We can then compute where he should reappear in the destination portal, using start/stop, percentage, and center and width (adjusted for player model size).

For example, if you enter a 2 high by 10 wide portal while floating with your head and left side both touching the top left corner of the portal, then you would exit a 10 high by 2 wide destination portal also with your head and body touching to the top left corner. If you enter on the ground with your body at the midpoint between rightmost location and center, you are also exiting at the midpoint between where your body would be at center and rightmost possible positions.

• If the output destination makes player hitbox hit some blocks other than portal blocks, his reappearance location is simply pushed so that he is inside the portal and if that still doesn't work, simply shunted straight to a valid spot (to take into account really weird portal shapes)

IN OTHER WORDS:

Players always exits in a location that makes the most sense as if the portal was really like some kind of doorway.

That algorithm should cover all situational cases pretty neatly and would be very intuitive to use too.

I can confirm that this bug existed ever since release 1.2.5 ! Not just on killing blows, but in fact on ALL strikes to a mob wether the mob gets killed or not has no importance. It just shows up more clearly when you kill a zombie and the moaning sound is STILL going on not only while the zombie is also saying its "ouch" sound, but for half a second more even after it has already despawned and disappeared from the screen !

All other games I know of can stop a sound after it started. For example you leave an area and the music fades out immediately, not 1 minute later when the entire soundtrack is finished, and then a new different music starts. Every game does that ! So why is it so hard to fix in Minecraft? Controlling sounds properly is part of basic game user interface ergonomics, right ?

The code wouldn't be so hard to do: Whenever ANY mob plays it's "hurt" sound, just stop that mob's other "vocal" sounds ! i.e. if the mob falls in water, and the mob gets hurt to, then the "water splashing" sound would not count as a "vocal" sound and thus would not get interrupted. Think of it as "mob mouth" and "'mob body" being two different sound sources, that both follow the mob around, and the "mob mouth" source should be able to play only one sound at a time: normal moaning/grunts/howls sounds, that can be interrupted, and their hurt sounds, which can't be interrupted.

Currently sounds have some link to their source at least in the form of orientation/distance or even full coordinates, because when you turn your head or move around, the left-right sound balance and the sound volume already get changed dynamically. So yeah I don't think it would be hard to make better use of that link between "soundsource" and "soundbeingplayedbysource" to make sure a "hurt" sound doesn't make you think there are suddenly two monsters nearby, when there is in fact only one.

And it's much more satisfying for the player to interrupt in full a monster. "shut up you meanie" you strike and it says "ouch" instead, is much more interactive than no matter what you do even manage to successfully kill the enemy, it's still going on moaning anyway. Gah.

A huge data integrity flaw, not treated as a bug but a "feature"? Funny. All respectable IT departments I know about, treat such a weakness as one of the things in the "needs to be fixed ASAP" category, not in the "wishlist of new features some clients would like". Expecting users to go into system files (%appdata% sure fits the bill) to use the program normally is always a defective approach. I worked in IT for 15 years, and that kind "blame user for basic safeguards or normal program operation wich leads to corrupted data", this is something that I've unfortunately seen too often but somewhow that never fails to simply amaze me.

Not storing the version in the world save files is not a "missing feature" but is a bug as much as say not saving the position of dirt blocks.

"The user should just be more careful". Never heard that excuse before lol !

Thanks anyway.

Seems fixed as of 1.7.9.

Confirmed for MC 1.7.9.

Well, sorry for the delay I said I'd test in 1.6, but I managed to do so only today.

I tested on Minecraft 1.7.9, and this bug doesn't happen anymore, not even once in 2 hours of play.

I did not change my hardware or the way I handle the mouse either. The only thing I have which may grab the mouse in a non-typical way is TeamViewer 8, to occasionally do some tech support stuff. And I update my drivers only through the mostly automatic Windows update. And I probably must have hit the F8 key at least once since last year, that is for sure. Redoing the F8 thing didn't make the bug reappear either.

So I won't be able to help more than that anymore.

Can anybody that was previously affected by this, try to confirm if the spinning still happens in 1.7.9 ?

Thanks and good day.

Suggested fix:

When the algorithm searches for a valid exit point, instead of:

SET valid spot to right over the bed
LOOP through all potential exit spots
IF ( exit spot is Air AND exit spot is under Air AND exit spot is over Solid ) THEN: SET valid spot to exit spot, and exit loop immediately
CONTINUE LOOP
Return valid spot.

Note: "exit spot' corresponds to the player FEET coordinates not his head.

Replace with:

SET primary valid spot to right over the bed
SET secondary valid spot to right over the bed
LOOP thought all potential exit spots:
IF (exit spot is Air AND exit spot is under Air AND exit spot is over non-Air ) THEN:
IF (exit spot is over Solid) THEN : SET primary valid spot to exit spot and exit loop immediately
ELSEIF //comment: we have the exit spot inf free air space but over a non-Air non-solid block
IF ( 2 blocks under exit spot is a solid block ) THEN: SET secondary valid spot to exit spot, however continue the loop
CONTINUE LOOP
IF primary valid spot is right over the bed: SET primary valid spot = to secondary valid spot.
Return primary valid spot.

Still happens in 1.7.9.

@David Harmon: If you want to be nice to the players, you could tweak the overnight check to make a player count as 3 or so villagers for crowding purposes. (That is, if the player moves into a building, villagers give them room.)

That would not always be nice. When trying to trade with villagers, seeing most of them suddenly escape the house you just entered would be bad.

The entire way villages are defined is kind of sucky. 1 door = 1 housing space is very limiting.

Houses with lots of doors yet an obviously lower "habitability" can't work weel. For example, if a player makes each room inside a big mansion house not only have it's own set of doubledoors plus doors for each closets too, obviously this would at last triple the housing" value of the house for no good reason. Sure it should have more villagers after all it's a mansion, but it should not have THAT many villagers in it. Even if the masion'.s rooms where without closests and single doors, the "rooms per occupant" of luxury houses is instinctively not the same as for slum housing. In the same way, a storage shed with lots of cubicles, made for decoration, should not suddenly automtically become a house for lots of villagers in it. Or a house that the player uses as his "own"' yet doesn't want to be constantly annoyed by "impromptu visitors". And not all wooden doors player places in his own base should not also automaticaly count as potential village doors.

In short, wooden doors, while an imporant aspect of villager navigation, should not be what defines the housing unit criterion itself. Something else that is not a door is needed, and a way to differentiate "housing" doors from "normal" doors too. But it is just the simplest way right now.

Also, in the case of super long villages or villages with weird shapes say, an L shaped village, using the center mass makes villagers wander, on those sides without houses, quite farther away than normal (when counting the nearest housesdistance, not the village center) to unsafe spots. Also, several nearby villages tend to create funky village dynamics where villagers can just suddenlty abandon one village forever, cramming into the next village.

Instead of a single village of varying boundary, maybe have a "village rating" in the section? (not a chunk because chunks are 256 blocks high = 16 sections that are 16x16x16) is determined. Then villagers just occupy those sections, so that a village of any weird shape or size will, because of villager semi-random travels, eventually be filled more or less evenly. You could build a huge city that way.

Any way, each villager should definitely have "his" house and stick to it as much as possible during the night. Currently finding a specific villager for trading is a real nightmare except in the tiniest of villages. It would look cooler to see villagers sleep in the house they spawned in (librarian in the library, etc.)

But just making the villagers stop crowding all in the same spot would already be a boon.

This occurs quite regularly on all my maps and versions.

Maybe it solved itself through an update. But maybe not. (I don't do snapshots, only main releases.)

I'll recheck again in the next official 1.5.6 release. If the problem is still there, I'll ask for a reopening the issue, and to ask for the test to be made in these conditions:

• By a tester that is able to click fast.

• On a setup that is not too powerful.

Please remember that this is an issue related to timing.

#1 - It may be related either to the double-click speed interval itself. In which case, the "power" of the testing setup is quite irrelevant. All it would need is setting the double-click interval to the maximum and using a fast clicking tester.

#2 - Or it may be related to actual timing delays for the game to be able to recognize 2 clicks that are standing very closely spaced apart from ach other. In which case, the "power" of the testing setup is critically important. Powerful setups will not show this second category of timing problems unless the player is inhumanly impossibly fast - faster than the mouse hardware would be able to follow anyway - and yet, still well within the insanely big FPS performance of the game. And thus, that testing setup would never be able to "see" such bugs.

Ergo, to cover all your bases, timing bugs should always be tested using crappy hardware lol! Simply because that is the easiest way to make them stand out all that much more.

My computer setup is actually rated around 500 on Passmark, and that is definitely on the low side of things. My graphic card's performances aren't too shiny either.

Anyway, I'll definitely post an update here on this issue after the official 1.5.6 comes out.

Ah, I finally see now how your code "works as intended"...

... and it is because our "requirements" actually differ a little bit!

=== Your requirements are ===

Requirement Markku #1: The player never exits face up against an obsidian pillar (even when one portal is oriented North-South and the other portal is oriented East-West).

Requirement Markku #2: Whatever opening the player enters (either North-or-south, or East-or-West, according to the portal's general orientation), and whatever "half" of the portal the player actually entered into (left or right), the player should always comes out of the same (the 'best') opening.

--> Markku requirements example: 2 portals: Portal #1 with openings on sides A and B, and Portal #2 with openings on sides C and D:

Then when player enters from "Portal #1 Opening Side A" (through either left or right half)
he would exit out of "Portal #2 Opening Side C" (i.e. the "preferred exit" side)

and when player enters from "Portal #1 Opening Side B" (through either left or right half)
he would ALSO exit out of "Portal #2 Opening Side C" (also the "preferred exit" side)

And in all cases, he never exits facing straight into a portal's obsidian pillar or through "Portal #2 Opening Side D".

=== Meanwhile my own requirements are ===

Requirement Patrick #1: Same as yours: The player never exits face up against an obsidian pillar (even when one portal is oriented North-South and the other portal is oriented East-West).

Requirement Patrick #2: Whatever whatever half of the portal player actually enters into (left or right), the player always comes out of the "best exit" side of the exit portal when he entered from the "best exit" side of the entrance portal, and always comes out of the other opening of the exit portal when he entered from the other oening of the entranve portal.

--> Patrick requirements example: the same 2 portals: Portal #1 with openings on sides A and B, and Portal #2 with openings on sides C and D:

Then when player enters from "Portal #1 Opening Side A" (through either left or right half), which happens to be the portal #1's "best exit" opening side,
he would exit out of "Portal #2 Opening Side C" (i.e. the "preferred exit" side)

and when player enters from "Portal #1 Opening Side B" (through either left or right half), which happens to be the other side of entrance portal,
he would instread come out of "Portal #2 Opening Side D" (which is also the "non best" side")

And in all cases, he never exits facing straight into a portal's obsidian pillar.

Your algorithm merely needs to check out only the neighbouring blocks around the exit portal to determine which is it's "best exit" side, and always use that side.

My version would simply require to *also check out the neighbouring blocks around the entrance portal to determine (in the same manner) which is it's "best exit" side.

Then simply apply directly to the player's facing whatever angle difference obtained between both portals "best" orientation, dephased 180 degrees to account for the fact that the player "entering" one portal is 180 rotated relative to the "best exit direction" of that portal.

In case of a "tie" between both exit directions, a portal's "best" exit direction would always be say always North over South and West over East. Thus, in the case of matched pairs of similarly oriented portals, you'd obtain the extremely natural "enter going north, out going north, but and enter going south, and going south you also go out it".

I think it would be quite simple to do and would allow being able to use all available openings in portals with a much more natural "feel".

SwiftyKitty2k,

Thanks for the very valuable input.

My "walls of text" isn't about giving a hard time to anybody, more about giving full detail for help.

Personally I'd really hate switching between official and snapshot and then back, what with the big launcher upgrade we have right now. I prefer avoiding any risk of "stoopid noob error".

Given what you just told me, and that Majong is working so hard on these very thing, I prefer to wait until the 5.1.6 release and then I'll then test again with that "official" version, and then either post "problem slved itself!" here, or I will then provide the crash report.

Really thanks Workday Lobster for pointing how much I was in error there! And thank you Brad Corbin for giving us that video link (cut & pasted below), and very sorry for my blunder! It's my previous post which is totally invalid lol!

The video does indeed show the upper left white sheep moving out at exactly 1:03, and show the white sheep in the lower right corner escaping at exactly 2:22 (at night time but it's still easy to spot).

http://www.youtube.com/watch?v=ATMmO-1OW2I

I just can't believe how I totally missed BOTH of these 2 "escapes", despite having watched the video TWICE. "DUH-Facepalm-And-All-That". My eyes must have been playing really bad tricks on me that night lol! Again, sorry and thanks a lot.

Still, now that I have my full wits about me (should never post stuff when tired!), I must say that it is extremely interesting to watch the sheep's behavior here in the video when they escape, particularly the differences and similarities:

-> In the 1st escape, the sheep is more or less immobile, and there is a grey sheep that is being "pushed" into the white sheep, twice, and then the white sheep comes out, it's a very calm movement, but as soon as it is out of the fence it turns left (not abruptly , with the grey sheep (still inside the pen) bouncing back aside (toward the right).

-> In the second escape, the sheep seems to want to go left, but a sheep is already there. Again, it is the SAME grey sheep! Is that a mere coincidence? And then the white sheep seemingly has to very quickly turn back counter-clockwise ending up facing the right fence, again it occurs twice, and then the sheep simply walks out, and again turns as soon as it comes out, this time making a right turn (and again not abruptly).

Maybe we need another video? This time with 16 sheep instead of 10, and put inside a 6x6 pen instead of 5x5 (with the width including the fences blocks). Each sheep should be of one of the 16 possible colors, allowing easy "sheep tracking". In fact, each seep should be renamed using name tags to a number from 1 to 4 indicating the pen it originally comes from. This way sheep escaping from one pen to another could also be detected easily.

Also, to avoid night scenes in the video, a daylight detector would be set up to detect the slightlest lowering of the light, to power a Control Block that resets the time to the moment of the beginning of the day when maximum illumination is already reached.

Finally, instead of using only 1 pen, we should use 4 pens, placed in a 2x2 configuration, with shared fences in the middle parts. Thus, with 64 sheep instead of 10, we should be able to capture about 6 times as many escapes for the same length of video taken. A couple hours of video capture should be enough to capture lots of escapes, and ultimately trying to find some kind of pattern.

Linda, in case you ever read this thread again:

All chunks farther away than 160 blocks (the normal 1-chunks sight range unless modding or editing the game files) get unloaded. You actually have 5 minutes to go get your stuff back counting only the seconds while a chunk is actually loaded.

So the truth is, if you die far from your respawning point (from a bed or the original spawn point), and the chunk is usually "out of the way" of other players (on a server), and no special mob forces that chunk to stay active, then it will probably get unloaded immediately after your death because no players are near it. In that case, the truth of the thing is that you actually have all the time in the world to prepare yourself and THEN go get your stuff back.

If you think that the stuff is very valuable, is plainly visible instead of hidden at the bottom of a big ocean or deeply nested in a dark forgotten corner of a giant undeground maze, and you know it's general position, but you're just not sure exactly where, and you don't mind "cheating a little bit" in order to get it back, then you can determine in which "region" you were when you died by guessing the "multiple of 512" of the coordinates (useful website for this: http://dinnerbone.com/minecraft/tools/coordinates/) and then keeping a backup copy of the appropriate region files (normally located in the C:\Users\<PutYourUsernameHere>\AppData\Roaming\.minecraft\saves\<PutYourWorldNameHere>\region\ folder) so that you actually can get several "tries" at this.

Note that the 5-minutes counter pauses if the game is paused, but does NOT pause while the game displays the "you died" red screen.

Ok, understood!

Man oh man, it would be just so wonderful if the new input device librairies solved this! I hope it's not a problem with Vista!

I'll definitely do the crash report thing test on the latest update and then post the full results here.

Thanks!

Ok, sorry for that hothead flaming rant, that bug constantly making me go bat crazy isn't a real excuse to me having used such harsh accusating language. Anyway it seems like the Mojang team is becoming more and more professional-like each passing year. So thank you very much for keeping your cool.

Ok, the game never actually crashes because of this bug. However, I'll try to reproduce the "forever spinning" thing. It occurs way more often when I have to make frequent turns, especially turns going up and downward (like in the typical Minecraft maze of underground caves and tunnels).

Well, the spinning itself occurs often enough - and probably from a combination of the way I usually tend to handle my mouses + the way the optical mouse send their output signals when their lasers gets "oh-so-slightly" pulled off from the desk, especially if done at a very slight angle with the other side of the mouse still firmly pressed against the desk. Like when you turn somewhat rapidly.

The bug seems to occur much less often when I manoeuver because of outright panic (mobs or other danger nearby, in a hurry to get somewhere, etc.), again probably in these situations my nervousness probably causes me to put more pressure on the mouse, firmly "anchoring it" on the desk surface, by opposition to moving it with only very light pressure, by almost "holding" the mouse.

I'll make more regular backups of my world. When the bug happens again through normal gameplay (and it is sure to happen often enough) I'll try to suddenly "not touch the mouse anymore" when it happens, and if it falls in the "forever spinning" mode, then I'll have the 10 seconds needed to fully crash-report-grab it.

HOPEFULLY Minecraft stores more than 10 seconds of debug data, so that you'll ALSO get the entire event including the "before it happens" input data too. IF Minecraft does NOT store more than 10 seconds of crash report, please tell me. If it doesn't even store 10 seconds, and only provide a "snapshot" of things in it's crash report game data, then please tell me also. I'll adjust the way I try to grab the crash report accordingly in order to give you the best type of data possible.

However, since the 13w18a snapshot also requires the new launcher, and that it seems that this is not a bug shared by most players (meaning, not a priority-one bug for most players), can I wait until the next official release (1.5.3 or 1.6, I guess) in order to do and provide this crash report? That would simplify things a lot for me as I never play anything other than the official releases and having both launchers and an official release and a temporary update at the same time seem quite complicated for me. Strangely enough while I'm very good with algorithms I also am crappy with system configuration!). So even though the bug is making me go annoyed-crazy often enough, I'd prefer enduring it a little more and test properly using a true release. Is that okay?

Then I'll post the results here.

IF the bug stops happening completely, then I'll also post this information here.

Thank you.

Ok, sorry my description was wrong here.

#1) It's actually something that happened in 1.3.4 maybe 1.4.7. So maybe it got fixed indirectly through a version change or something.

#2) Seems to happen a lot more near walls and corners, especially from items "falling out of" a crafting table or broken furnace, than right in the middle of the floor. I don't remember if it happened to items deliberately dropped by the player, but I remember it was mostly items falling from breaking stuff.

#3) It seemed to occur only infrequenly. Sometimes not at all. Mostly, near edges. So it greatly depends on the configuration of nearby blocks.

Just close this one bug report here and IF I can see it again, then I'll document it better the next time.

Thanks.

Brad, that video claimns to catch the moment sheep escape fences, but it shows only the "before" and "after" moments, not when it happens! So its only good for wasting the viewers' time with mostly useless blahblah.

Personally, I actually saw a sheep escaqe from it's fenced pen during the game, right in front of my eyes, and only a couple blocks away from me! I was all "What the...? That's just weird!"

So the only important thing to know is that animals can escape even if the player is standing immobile and near the animals, i.e. like you said when no chunk are being loaded/unloaded. And that this escaping can occur even when the animal "density" in the enclosed space is not that big (sheep-to-'fenced area' ratio is less than 2/3). Or even without other animals right beside it.

Steve, I totally agree with you than simply keeping current behavior is way worse than all of the fixes presented here. Its a typical example of having tried to fix some stuff actually made it much worse. As you say, at least the previous behavior was simple enough to understand. Now, it screws up portals 100% of the time lol.

Mojang has made a lot of fixes in the last few updates, I think. Still, we're due to another release this week I hope. 😉

As for fixing difficulty, I'd summarize everything like this:

Solution #1 - The "Not bothering with it" fix "[The "Mojang doesn't have enough time" no-prize fix]. Can't be easier and quicker than that! Crappy solution tho. Most likely solution to be implemented in the short and medium term.

Solution #2 - The "K.I.S.S. IT" (Keep it Stupid Simple) >Steve's Fix. Super easy, fast, simple. Works only with some carefully placed portals, not those were orientation changes or where you want a definite exit direction. Would be ideal in the short term. Truly simply a "rewinding back a bad update decision", and would be way better than the weirdness we have now.

Solution #3 - The "Best Guess without Too Much Hassle " >Markku's Fix. Relatively easy, wouldn't really take more time than Solution #2 since the code for the fix is already done anyway. Would work for most purposes, especially if the player takes care to make sure exactly one side has "obstacles". Maybe in the medium term. If we get lucky.

Solution #4 - The "True Portals Behavior As It Was Originally Intended" >Patrick's Fix. Most solid and works exactly like the player would expect and intends at all times, even with automatically created portals, not just those carefully placed". Only solution adressing all possible cases but also the one definitely that would be a big step up in the time required to code the fix. Thus, not really likely to occur. At all.

Solution #5 - "We finally fixed the portals in this update!" >Mojang's (eventual) fix. Something totally new that will probably surprise us in many ways probably with nice new and superbly original behaviors and portal features, yet still not quite working like it should anyway. Most probable solution in the long run.