
Yes, I know that mate, don't need to elaborate.same... I went over bar packets again, and they are basic as. Nothing has changed within them far as I can see. All you have is header, ID, coords rotation:
[AI][ID] [X coord] [Y coord] [rotation]
@@LAI1234567 8 9 0
Nothing different from what I can see...
The fact that the guy can only walk through ONE side of the bar makes me think its more of a warp, cause warping only warps to a designated piece of furni and not a specific point. He couldn't control which side of the bar he went through, he'd warp to the side which is used to position it.
:8
[/i]
It uses the 'warp' header taken from the way teleports work. The packet looks like this;
[@v][RoomID]/[FurniID]
@@Q@v1234567/7654321
Alex, stop talking about this **** with people who wont understand it, get back to work on the siteIf he were to walk through it by changing 2,1 to 1,1
(which is impossible for a client to chan ge as far as i can see) he'd only be able to walk through one side also.
Like i said earlier:
1.) the space values are not changable for the client as they are included in the XO map on a hierarchy basis as far as i'm aware.
2.) there is only ONE way to walk through furniture and that's using a one-way-door anhd i've already tried exploiting this and got no where apart from some odd bugs.
So i'd say he just did a smooth warp:
walked towards the bar, warped, carried on walking.
It's much easier then changing hard-data ... to change that would be as hard as changing the credit value, because just because you can't see a furniture it dosen't mean the furni is walk-throughable.
Think back to FurniPhotos ... all furni created was possible to walk through and "invisable" furni wasn't walkthroughable.
Think back to ServerSide-tag furni ... all furni was walk-throughable and "invisable" furni wasn't walkthroughable.
Think back to ServeSide-Presents/Trophies ... all furni was walk-throughable and "invisable" furni wasn't walkthroughable.
never has furni been created that is real to the point you can't walk through it - without buying something from the catalogue
(bare in mind you could get cheaper rares etc but not for free.)![]()
I agree to that but i wouldnt of thought you register it in B64 unless its a HEX codeThat's silly. There's no 'bug' in injecting packets out of context. Its not like something has gone wrong somewhere, you're just monitoring what's already there, and then adding to it. You're not finding an unticked box, or an unchecked hex and manipulating it (although most of the time your are lol, but not for things like PIB or drinks or w/e) you're just sending it at a different time.
Obviously with other things that aren't in action right now then finding bugs is how these things come about but as Elliot said, for the most part what we do atm, is just sending packets out of context.
For things like moodlights erroring. Thats not a 'bug' on habbo's part. It's being signed incorrectly, adding an extra char, without registering it in B64.
:rolleyes:
Someone also said something about being able to walk through a mode bar. This is defo possible, what the guy has done is reduced the boundaries of the furni. So where a mode bar or any other bar is normally 2x1, he's changed it to 1x1. Although the graphic of the second side of the bar will still be there, as far as taking up a space is concerned it isn't. I'm not 100% sure how this is done but the only way I can think of atm is some kindof
signing.
I see what you mean, but everything (header included) gets taken into account with B64. So for a moodlight it'd be @@PEVII@G#FFFFFFQPB
Also their are various breaks in a packet, like you pointed out for the hex code in a moodlight, if such a break in data is present, then again B64 is used. For example in a furni sign packet it'd be:
@@RAJ@H12345678@DTRUE / EFALSE
Where the breaks are after the header to introduce the furni ID, and after that to introduce the actual signing.
![]()
Last edited by LoveToStack; 11-08-2008 at 10:56 PM.
Want to hide these adverts? Register an account for free!