All Projects

Once we have parties ( FS#45 ), we will be able to have party drops.

4 ways this can be done:

1. You drop many bags around with % of loot, first in best dressed.
2. You drop 1 bag but when a player takes items, it gives a % to each in the party instead of all to the one.
3. You don’t “drop” at all, just allocate items straight to the party members.
4. Drop 1 bag. But once it’s picked up, all other party members automatically get a bag under their feet, opened, containing their % of the spoils.

Whilst the most complicated, the 4th option sounds the most attractive and flexible from a player perspective.

A party system where you can “party up” with people and go on missions together. Perhaps an NPC interface that allows you to select the people from those around you for your party or something.

NOTE: Different to guilds ;)

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

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.

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.

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

Quote from: collardhills on 2008-11-13, 02:50:29

It seems if you click somewhere, and someone/thing is next to you, or gets in your way (even in an open map) you just stop, until the thing moves. On main server, you move around the object/person whenever this happens. Could you implement the same thing here?

This is indeed the case as no actor checking occurs while navigating at this point.  At least not until it finds an actor in the next square in sequence.

The channel system needs to be checked to confirm everything is working properly (active channel might not be working correctly for example).

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.

Dropping an inventory item on to an equipped item, should swap with that item. Undecided as to whether it should swap with what you drop it on, or the equipment of the same type you have equipped (ie if you drop a sword onto a shield, should the new sword swap for the shield or your existing equipped weapon).

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.

Trading should support transferring items to/from storage as well as inventory.

( 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.

QELServ needs to be the BEST ... just BEST ... ever!

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.

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.

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)