All Projects

A system message like “your messages to … are being ignored” could be useful for several reasons:

* you have forgotten that you are on somebodies’ ignore-list
* you don’t even know that you are
* you want to see if you *still* are one somebodies’ ignore list

It could be useful for several reasons:

* less confusion (not wondering why you don’t get an answer)
* less time wasted (you’re not trying to contact that player anymore)
* may lead to rethinking your behaviour (and possibly trying to contact that player by other means if you are serious to improve the relationship with that player again, if you want to tell them you’re sorry or something).

While I see the risk of stalkers (so that ignored players try to contact you with other chars), I think it could also lead to better relationships between players or “fixing” some broken ones.

I would like to find out which players ignore me (for whatever reason). Therefore a command to print such a list would be nice. While this is more out of curiosity, I think it could also lead to rethinking among players if they find out they’re ignored by lots of (or certain) players.

Hello,

I haven’t been able to start pslaunch and psclient for a while on my G4 iMac (PPC). Walktest on the other hand works. Here is the gdb-output:

pslaunch: http://pastebin.ca/1436041

psclient: http://pastebin.ca/1436035

I think if players could load and save their description, this would add a lot to a more dynamic roleplay. Reasons:

- It would be far more easier to rearrange/change portions of the description when being able to use an external editor
- given the limited space in the description window, it is not really easy to compare different sections of ones description. Using your usual texteditor could possibly lead to a more consistent description.
- Players could prepare descriptions in advance for future RPs, in case they are planning to change their characters
- Players could go back to an older description, once a certain RP is done (think about people being hooded for example or playing rogues for a while).

Basically,it would allow players to react on certain changes in their own or in others roleplays far more easily.

okay, this is how to reproduce the bug:

1. set an away-message
2. switch to another tab
3. wait until somebody sends you a message. You switch back to tell-tab automatically (only if the tells are not redirected to the main-tab!)
4. As you are in tell-tab now, you see the message sent to you as well as your own auto-reply
5. switch to another tab again.
6. The tell-tab still blinks, although there is no new message.

I *think* this is related to an inconsistent behaviour regardind auto-switching to tell-tab. It does this auto-switching *only* if an away-message is set. If none is set, the tab just blinks. It *seems* as if the auto-switching is not properly recognized as a switch to the tell-tab. But doing it manually via mouse is.

Hi,

this is an illogical behaviour. To reproce it:

* put a chest in your inventory
* open a chest, so you see what is in there. Leave that window open
* move that chest into another slot in your inventory
* try to put something into the chest-window.

It does not work. You get the message “… does not fit in that slot”. The only way to drop something into the chest again is to put the chest into the same inventory-slot where it has been before.

From a users-perspective, this is completely illogical because to a user the chest is still the same, no matter *where* in his inventory it is. Obviously a window representing the chests-contents is bound somehow to the inventory-slot, not the chest itself (as long as it stays open, that is).

PS: I tried it with a sack also, and it is just the same.

PPS: Another effect of the same problem is this: Open a container that lies within your inventory. Put some items in the container and let the containers window open. Then move the container itself to another inventory-slot. The items in the container-window disappear until you put the container into the inventory-slot where it has been before

Here’s a real problematic situation:

Let’s say one has two sacks in the inventory. One is empty, the other one is filled. What happens if you try to sell the “empty” one? You can’t. The reason: If you start to trade with an NPC and try to get info on a selected item (like a sack), you only get the weight of the item (the sack) itself. It does not add what is in the sack, so there is absolutely no way to tell which one is the empty and which one is the filled sack. The same goes for glyph sacks. I suspect that is a problem with every container you sell.

The info-window (visible when clicked on the “eye”) should either show the “real” weight of a container or show a counter, representing the items which are in a container.

It does not make sense that you can put two swords in one slot, but not two armor pants. The inventory-wndow is no representation of a real item anyway, just an overview of what the player is holding. And therefore I think *all* items should be stackable in the inventory.

I have either crashes half-way when the Ojaroad2-map is loaded (the progress bar is filled to 1/3) or with a message saying “loading region failed”. In the latter case the progress-bar is filled completely.

With the help of Caarrie and others I have made a gdb-output also:

http://pastebin.ca/1090228

the problem occurs on an iMac G4, 1GHz, 2GB RAM with a GeForce4 MX (64 MB)

I have tried to load the Oja-map itself (the town) and it works. But whenever I try to enter the Ojaroad2-map or load the game with a character already on that map, the crash happens

Hello,

sometimes PS doesn’t load any textures at all. This has happened with the new 0.4.xx-version only but never before.And here is how the screen looks like in those cases:
http://img176.imageshack.us/my.php?image=picture5zw6.png

There are at least two situations in which that seems to happen everytime:

1. When running PS in fullscreen, regardless the resolution
2. When I restart PS by hitting the “relaunch”-button (the client crashes everytime it is ended, no matter how, and OSX shows a requester then, saying “… quit unexpectedly - ignore/report/relaunch”

If I use “ignore” and start the client anew, it works fine.

This to make it possible to improve roleplay for bad characters like robbers and such:

1) A status-field for all items, stating if it can be robbed or not (settable by the owner.
Thieves would see them (more and more of them with a higher thievery-skill). This way, the owner himself decides what he theoretically would willing to “give” a robber without knowing exactly what will be stolen. This could include a certain amount of money, say, settable by the owner as well.
Stealing should only be encouraged in a roleplay-manner (meaning that stealing without doing or saying anything should be discouraged; writing that he/she sneaks up to the victim could be an example. Writing something after the robbery, like “x runs away snickering” could be another). And quest-items should be excluded from robbery automatically.

The client crashes when using the Quit-button on the character-selection screen (at start), when clicking the “server connection failed”-requester or when quitting it regularly. Happens everytime.
OSX shows a”the application psclient_static quit unexpectedly…” message

hello,

(while I refer to tab-clicks I actually think the following happens whenever you click anywhere in the window but the main area)

The problem is as follows. When you click on one of the tabs in chatwindow, the blinking cursor in the input-field disappears. But you are still able to use up-/down-arrowkeys to scroll through the texts you typed. This is “right” from a technical point of view (as the window is still “selected”), but it is wrong from a users perspective, because of this:

1. When the user “sees” that the inputfield isn’t selected anymore (no blinking cursor), it should *not* have focus anymore and therefor should not respond to any keystrokes.
2. while the up-/down-arrow keys influence the inputfield in that mode, the right-/left-arrow keys move the character from left to right. This is inconsistent behavior. Either the inputfield should have focus completely (then the character should not move at all, no matter what keys are used) or it should loose focus completely and all keys to move the character should work as expeced. Refer to these two modes as “text-mode” and “play-mode” if you like).
3. The problem gets worse if a user hasn’t set an alpha-value for an unfocused window. Then he has no way to determine if the window still has focus or if it has not. Other than to try it out, that is.

The solution to this is simple: The text field should *never* loose focus, no matter where the user clicks in the chatwindow. As long as the window has focus, the text-input should have too (and therefore the cursor should blink).