| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
are enabled or not in a static member of class Particle instead of an instanced member of Being.
|
|
Also some related chenges elsewhere
|
|
Ad start eAthena's GuildHandler
|
|
|
|
|
|
I just discovered that the X,Y offsets aren't handled
the same way between eAthena and Manaserv to draw the player's character.
So, this patch hopefully fix the walk on water bug.
There are some glitches left:
- Like walking diagonally to a blocked corner.
- Or Some times the character miss a blocked tile and correct its route.
- The character's name is drawn in the wrong place for Manaserv client.
- The playerBox draws the player at the wrong location; He's not centered at login
and isn't diplayed at all in equipment window...
But anyway, it's better than before.
I'll go on for some polishing before continuing. Some cleanups
are becoming vital for code's understanding.
|
|
The current code tells that the character must stop in the middle of a tile
when the tile to the north is blocking.
But even now with respecting this, the player is still on water. So, what to do?
Correct the water tile?
|
|
|
|
|
|
What's left is working on player corner handling and directions while walking.
|
|
- Making sure that keyboard and mouse are fully working on eAthena.
- Making sure the mouse code isn't broken again.
There are some glitches left but it's coming!
What's left to be fixed:
- Come a little closer to walls (localPlyer::nextStep() improvement to be done).
- Adapt the next Step range according to the being speed. (again in nextStep()).
- Handle more nicely player's direction when walking diagonally.
- Get player's speed from server.
Enjoy :)
|
|
TMWserv client.
|
|
By removing a stopWalking() call on each being->logic() because of setWalkingdir()
when the current path wasn't empty.
|
|
|
|
I'll go step by step, in order no to screww everything...
I also removed hard coded ticks reference in game.cpp
|
|
|
|
Also removed an (now) unuseful debug piece of information.
Thanks Kage for reporting this case.
|
|
|
|
The only case left in mouse movement is that the client doesn't check
for walkability of the destination point when you click on a unwalkable point.
Let me explain this NASTY bug:
The bug remained in the Being::SetDestination() function,
when recalculating the path from tiles to pixels.
The changeX and changeY variables went crazy when (endX - startX) gave a negative value.
That why the given path became random, and the player went anywhere.
This didn't happened to monsters, NPCs, and when walking using the keyboard
because the patnodes system isn't used for movement up to 1 tile at a time.
I removed some dead code (in viewpoint.cpp), made the keyboard navigation a little
bit more bearable, and fixed this client bug.
Now, I'll be up to finish fixing the movement system using mouse (What's remaining is a joke
next to what I had to do to discover this...),
and I'll look at a third time to the keyboard system which is a bit raw, just for now...
Regards,
P.S.: Kage, I'd like to get a three-cheese pizza!
|
|
|
|
|
|
went on vacation.
|
|
|
|
Move stuff only needed for Players into Player (like slots and sprite
limits). Move name handling into Being (no need for three copies of
this code). Clean up terminology (including Map terminology). Remove
hair-related variables.
|
|
Better for future use.
|
|
|
|
Step two (updating the headers in all po files) should preferably wait
till importing from Launchpad and updating the po files.
|
|
|
|
|
|
|
|
|
|
|
|
Please turn on -Wall, and if you don't notice your warnings, also turn
on -Werror.
|
|
Also some other small merges
|
|
* Merged a few split strings
* Fixed some spellings and wordings
* Turned a couple of std::cout and std::cerr into logger messages
|
|
|
|
|
|
|
|
SkillHandler::up moved to PlayerHandler::increaseSkill
|
|
Still need to find where to attach LocalPlayer::pickedUp for TMWServ.
|
|
THe experience message queue is now a general queue for serial
messages (ie: not messages like battle messages that should be done
immediately).
|
|
|
|
|
|
|
|
gui (very, very hackish)
|
|
helped a bit
|
|
Looked pretty good so I removed annoying debug information.
Also should note that movement between two players is still off.
|
|
|
|
|
|
Tried to make the client continue attacking (it does not need to send
attack packets, but just continue playing attack animation and sounds).
Now logs a warning when a weapon is found without an attack-range (I
keep finding weapons with an attack-range of 0 which makes it hard to
target monsters).
|
