All Projects

( from: http://qelserv.quadronyx.org/forums/index.php?topic=15.msg318#msg318 )

If you attempt to flee during combat preparation and actually succeed, the battle still takes place.

Creatures move in a very stupid way and inevitably end up stuck and/or blocking paths etc. Whilst paths will be fixed in maps by making them wider, creatures should probably not stop on any narrow area anyway and should, in general, “think” about where they’re going

At some point the client should be “cleaned” of all the truly ridiculous RAW_TEXT scraping code and changed to support simple server messages. These will eventually interfere with “normal” functionality.

At the moment, all actors can see all other actors on the map they are on. Instead they should have a limited range of vision.

If you attack someone in a PK area, and whilst in the PENDING fight state they leave the PK area, server lag occurs as the server tries to initiate combat.

If a player takes multiple of a non-stackable item, in one go, from a bag where they are stacked, their carry capacity gets screwed. ATM this is only causing an issue with #airdrop but could potentially cause other issues if we choose to allow bags to be non-stack exempt.

When equipping an item that is stackable (and you have more than one), it equips ALL of that item, not just one.

Despite the changes for  FS#47  the CLIENT doesn’t sent the right number of items to pick up as it expects items in bags to be stacked.

Since stacking in the bag is reasonable, and because it’ll save a client modification at this stage, bags should be made to support stacking of non-stackable items.

Creature’s can currently spawn anywhere within their given rectangle. This includes levels that aren’t necessarily possible to get to or from (say for example, a table). This means the creatures are currently taking up a useless slot, limiting the number of creatures people can fight, and using up unnecessary thinks, trying to find a way out.

Placement should be more intelligent, perhaps opting for something within a few height levels of norm, or of the spawns center.

NPCs buying and selling needs to work betterer (and completely).

If whilst in pending combat state (i.e. you just clicked to attack a player/creature from a few steps away and start moving towards them, but combat hasn’t actually started yet) you click to move elsewhere, just after the combat animations start you then do a ‘step or two’ of the move animation in the direction you clicked, then flick back to combat animations fighting your opponent.

It looks weird and can mess up the rotation of the combat participants.

When you move in eq potion with cooldown visiblity of cooldown dissapear, but it still has cooldown.

Seems the client paths for 3D objects has changed to a flat directory vs the old tree style. Maps will need to be modified.

At present, the original configuration is lost once you modify the modes of the
mouse. An option to return the mouse to it’s factory defaults would be
advantageous.

The built dist package is named “ratslap-0.2.0.tar.gz” regardless of architecture.

Would be nice to be able to save and load profiles.

The mode names should be simpler than “F3”, “F4” and “F5”. They were only named
this way as that was the hex code for the mode, hardly user friendly.

We should have a musl build for a lean standalone binary version.

From https://github.com/krayon/ratslap/issues/2 :

https://github.com/jpotier wrote:

  I may be tired, but I don't get how to set say key 1 to my button G4.
  Actually, apart from calling
      ./ratslap -p f3-5
  I don't understand how you actually set a modified mode. Should I edit the
  source code and recompile?

https://github.com/thomasluquet wrote:

  Same thing, for me, the documentation it is not really clear for me...

  BTW, i try to make a draw of the mouse and the buttons, is it ok ? (i can
  send you the .odg if you want)

From GitHub Issue #9 by adrfantini:

I have a very weird behaviour here. After having modified many buttons to
suit my needs, I have the following problem.

I cannot assign many software mouse Buttons to many hardware buttons.
Assigning keys seems to always work tho.

Say I am in this situation:
...
  sudo ratslap --p F3
  Left Click (But1):   Button1
  Right Click (But2):  Button2
  Middle Click (But3): Button3
  G4:                  
  G5:                  
  G6:                  
  G7:                  
  G8:                  ModeSwitch
  G9:                  DPICycle
...
Now let's try to modify it with:
  sudo ratslap --modify F3 --G4 Button4
Result:
  sudo ratslap --p F3
  Left Click (But1):   Button1
  Right Click (But2):  Button2
  Middle Click (But3): Button3
  G4:                  
  G5:                  
  G6:                  
  G7:                  
  G8:                  ModeSwitch
  G9:                  DPICycle
Nothing! Let's try assigning keys instead:
  sudo ratslap --modify F3 --G4 LeftAlt+K
  Left Click (But1):   Button1
  Right Click (But2):  Button2
  Middle Click (But3): Button3
  G4:                  LeftAlt + K
  G5:                  
  G6:                  
  G7:                  
  G8:                  ModeSwitch
  G9:                  DPICycle
Works...

In short, I can seem to bind mouse Buttons anymore!

However, some, like sudo ratslap --modify F3 --G7 Button9 work, while others,
like sudo ratslap --modify F3 --G7 Button5 do not.

QB#118 shows that unrecognised parameters (such as “button5”) fail silently,
assigning 000000h instead of reporting an error.