All Projects

if you set your skill via setskill, you don't get notified, so the skillist doesn't update

if a directory has been removed completely pslaunch only removes the files that resided in that directory, however it doesn’t remove the empty dir.

it should check whether the directory is empty after removing the files and should then remove the directory.

it’d be nice to have pre- and postupdate scripts in pslaunch to be able to perform extra tasks like updating dependencies (e.g. installing a new msvc version), resetting certain config settings, etc.

pslaunch has serious issues if the mirrors in updaterinfo.xml/updateservers.xml differ from the local ones - most notably if the IDs change (e.g. one server is removed or they’re reordered in general)

the bgloader needs a load range of at least 200, else it won’t work
additionally the load range shall not be set if bgloading isn’t enabled (simply because it doesn’t make sense)
patch to set 200 as minimum load range if camera view range is too small and not set it at all if bgloading is disabled

the bgloader needs a load range of at least 200, else it won’t work
patch to set 200 as minimum load range if camera view range is too small

updating shadows is rather slow as it computes the actual difference between the main player and the target for each known GemObject resulting in many unneeded csVector3 allocations and computations
I propose to speed this up using the bounding boxes already available for all GemObjects which results in only one allocation during shadow checking: the one of the box around the main actor for the shadow range

patch to implement this speed up

the bgloader loads everything based on a on-need basis - however as the podium sector isn’t connected to any sector, it’s not considered needed and therefore never loaded resulting in the chardolls not having a background.

EDIT: as it may not be obvious: this only happens while having background loading enabled

setting the loading range for the backgroundloader doesn’t have an instant effect. it only occurs upon moving far enough (10% of loading range which equals 11% of the viewing range) which may be impossible to reach (e.g. viewing range 50→1000).
this may be fixed by applying this patch

due to some reason(probably compiler optimization?) the coordinates retrieved from the persistWorld message end up being in the wrong order (z,y,x instead of x,y,z) for me.
this may be fixed by applying this patch which simply sets the parts one by one instead of constructing and object and then copying it

that fence texture is partly wrong which looks pretty odd
/pos:
hydlaa_winch -5.17 -10.76 -335.67

bt from gdb:

Program received signal SIGINT, Interrupt.
0x00000000007802ef in psEffectAnchor::Update (this=0x2aaac7153a00, elapsed=4294966764) at src/common/effects/pseffectanchor.cpp:232
232 while (life > animLength)
(gdb) bt
#0 0x00000000007802ef in psEffectAnchor::Update (this=0x2aaac7153a00, elapsed=4294966764) at src/common/effects/pseffectanchor.cpp:232
#1 0x00000000007a6d59 in psEffectAnchorBasic::Update (this=0x2aaac7153a00, elapsed=4294966764) at src/common/effects/pseffectanchorbasic.cpp:95
#2 0x000000000076e3c3 in psEffect::Update (this=0x2aaac7146090, elapsed=4294966764) at src/common/effects/pseffect.cpp:572
#3 0x000000000079be9d in psEffectManager::Update (this=0x2aaac4471f70, elapsed=4294966764) at src/common/effects/pseffectmanager.cpp:400
#4 0x00000000004726c6 in psEngine::Process3D (this=0xc58d000, ev=<value optimized out>) at src/client/psengine.cpp:961
#5 0x000000000048429d in psEngine::EventHandler3D::HandleEvent (this=<value optimized out>, ev=@0xfffffdec) at src/client/psengine.h:545
#6 0x00002ad64094ad32 in csEventTree::Dispatch (this=0xc00fe30, e=@0x2aaab2e45bb0) at /home/soak/src/cs/libs/csutil/cssubscription.cpp:576
#7 0x00002ad64094af28 in csEventTree::Notify (this=0xc00fe30) at /home/soak/src/cs/libs/csutil/cssubscription.cpp:546
#8 0x00002ad640934e25 in csEventQueue::Notify (this=0x7465677261543a30, name=@0xfffffdec) at /home/soak/src/cs/libs/csutil/cseventq.cpp:240
#9 0x00002ad6409354f3 in csEventQueue::Process (this=0x2ad640e42cb0) at /home/soak/src/cs/libs/csutil/cseventq.cpp:256
#10 0x00002ad6409a0a1e in csDefaultRunLoop (r=0x2ad640e420e0) at /home/soak/src/cs/libs/csutil/generic/runloop.cpp:99
#11 0×0000000000479081 in main (argc=<value optimized out>, argv=<value optimized out>) at src/client/psengine.cpp:1942
(gdb) print life
$1 = 4.29496678e+09
(gdb) print animLength
$2 = 10

this will take ~429496678 subtractions… nobody will wait that long
therefore I propose to apply this patch patch for a huge speedup in case life » animLength

marking this high as I get this lockup a lot lately

EDIT: fixed patch

confirmed by me, CXDamian and Thom:

only occurs with shadows enabled, though didn’t happen before
gfx cards:
ATI HD 5770 for me, ATI HD 4870 for CXDamian and NVidia GTX260M for Thom

screenshots are by CXDamian, looks very similiar here, though

currently all packets are just sent out as they’re produced. this might lead to a full input queue on the client side resulting in packets not being dropped and resent.
this can lead to rather obscure bugs, e.g. not being teleported into/out of a guild house or not spawning all items in a guild house as outlined in PS#2059

therefore it’d be nice to limit the amount of packets that’s sent within a certain amount of time or to introduce some a better control mechanism.
e.g. the client could send a packet to the server that it’s input queue filled up and send another packet once it’s under a certain threshold, again.

this would require a per-client packet queue, but could also help to better detect and disconnect a locked up client (e.g. if the server side packet queue for the client is filled up because the client one is still filled the server could disconnect this client due to a deadlock).

requested by Botanic:
setskill should accept relative values (+/-x) additionally to total ones

being on a mount should change the pov in my opinion as the character is sitting on the mount, so the pov is way higher than usual which isn’t reflected atm.
that’s most recognizable while playing in first person.

all kind of medium severity quest bugs, mostly dialogue options showing up at the wrong time

in the svn db all races have set scale to 0 which makes them invisible. this should be -1 instead to not scale the models.

during that quest you have to solve a riddle, though with the new quest system you get 2 choices instead of an input answer choice of which one is so obviously wrong, that this part of the quest isn’t challenging at all, anymore which takes away the meaning of this step in my opinion, as it’s supposed to be a hard riddle even our amazing riddle master couldn’t solve. therefore it’d be nice to replace the 2 choices with an input dialog like for other quests, so that part is actually challenging, again.

client crashes while facing certain items - tested on ezpc(npcroom1) and laanx(hydlaa_plaza)
in both cases the client crashes shortly after logging in
backtrace ( full )

PS: r5448
CS: r33643

if you have items having odd weights (e.g. rings: 0.03, goblet: 0.6) their size is rounded down for size calculation.
therefore the contained size may be smaller than the actual size as only full numbers are counted.

the problem may be fixed by this patch

am at ps r5413 and cs r33628 (both HEAD as by writing) and have serious problems with the new input system.
while everything works alright in the chat input for example, some input seems to have serious issues.

e.g. I have normal wsad binding for movement. hitting them results in a permanent movement and hitting them again doesn’t do anything.
on the other hand I have the alternates bound to the cursor keys and those work perfectly alright.
additionally I have bound the small inventory to u, the normal one to i - neither of those work.
on the other hand self defined shortcuts(e.g. several spell casts, sit, a /who, …) work exactly as expected.

last tested revision that worked as expected was r5402 that didn’t have any of the described issues.

there’s a Hall of Mirrors effect around the teeth of the pterosaur:

during a group duell (using /groupchallenge) you aren't asked for a confirmation in order to kill your opponents which results in unwanted kills
additionally I'm not too sure about the circumstances under which a group should count as defeated, but all members of the opposing group were either defeated or dead and the group battle didn't end.
furthermore after yielding the character didn't sit down as usually during duells and I could still attack one of the members of the opposing group after my own one yielded
after challenging the players of the opposing group normally and either defeating them or yielding, you cannot attack them anymore, though

the key definition of MouseMove is placed under the wrong category in options→keys
it’s placed under camera instead of movement which doesn’t make sense

patch to place it in the according category

tried using cs r33573, ps r5298, both built with –enable-debug
after logging in the client stops with a failed assertion at the character selection screen:

Assertion failed: !socket.IsValid()
Location: src/client/charapp.cpp:823
Call stack:
/home/soak/src/planeshift/psclient [0x41a09d]
/home/soak/src/planeshift/psclient [0x41a3d7]
/home/soak/src/planeshift/psclient [0x47a03c]
/home/soak/src/planeshift/psclient [0x48df89]
/home/soak/lib/libcrystalspace-1.9.so [0x2b259bd848cd]
/home/soak/lib/libcrystalspace-1.9.so [0x2b259bd84988]
/home/soak/lib/libcrystalspace-1.9.so(_ZN12csEventQueue6NotifyERKN2CS8StringIDINS0_12StringSetTag7GeneralEEE+0x8e) [0x2b259bd6c66c]
/home/soak/lib/libcrystalspace-1.9.so(_ZN12csEventQueue7ProcessEv+0xbd) [0x2b259bd6c72b]
/home/soak/lib/libcrystalspace-1.9.so(_Z16csDefaultRunLoopP15iObjectRegistry+0×234) [0x2b259bddc020]
/home/soak/src/planeshift/psclient [0x479ec5]
/lib64/libc.so.6(libc_start_main+0xf4) [0x39c241d974]
/home/soak/src/planeshift/psclient(gxx_personality_v0+0×471) [0x4084f9]

Program received signal SIGTRAP, Trace/breakpoint trap.
DebugBreak () at ./include/cssysdef.h:876
876 }
(gdb) bt
#0 DebugBreak () at ./include/cssysdef.h:876
#1 0x00002b259bd1f911 in CS::Debug::AssertMessage (expr=0x790e39 “!socket.IsValid()”, filename=0x790d25 “src/client/charapp.cpp”, line=823, msg=0×0) at /home/soak/src/cs/libs/csutil/csassert.cpp:80
#2 0x000000000041921a in psCharAppearance::ProcessAttach (this=0x2aaab561d800, meshWrap={<CS::Memory::CustomAllocated> = {<No data fields>}, obj = 0x7fff7a26dd70}, socket={<CS::Memory::CustomAllocated> = {<No data fields>}, obj = 0x7fff7a26dd60})

  at src/client/charapp.cpp:823

#3 0x000000000041a09d in psCharAppearance::ProcessAttach (this=0x2aaab561d800, factory={<CS::Memory::CustomAllocated> = {<No data fields>}, obj = 0x7fff7a26df60}, meshFactName=0x7fff7a26de90 “tools#pick01a”, socket=

    {<CS::Memory::CustomAllocated> = {<No data fields>}, obj = 0x7fff7a26df50}) at src/client/charapp.cpp:816

#4 0x000000000041a3d7 in psCharAppearance::CheckLoadStatus (this=0x2aaab561d800) at src/client/charapp.cpp:882
#5 0x000000000047a03c in psEngine::Process3D (this=0x12064a20, ev=@0x2aaab86d5590) at src/client/psengine.cpp:906
#6 0x000000000048df89 in psEngine::EventHandler3D::HandleEvent (this=0x2aaabc1c3e30, ev=@0x2aaab86d5590) at src/client/psengine.h:532
#7 0x00002b259bd848cd in csEventTree::Dispatch (this=0x11b8a5d0, e=@0x2aaab86d5590) at /home/soak/src/cs/libs/csutil/cssubscription.cpp:576
#8 0x00002b259bd84988 in csEventTree::Notify (this=0x11b8a5d0) at /home/soak/src/cs/libs/csutil/cssubscription.cpp:546
#9 0x00002b259bd6c66c in csEventQueue::Notify (this=0x2b259c2b2540, name=@0x2b259c2b27d8) at /home/soak/src/cs/libs/csutil/cseventq.cpp:240
#10 0x00002b259bd6c72b in csEventQueue::Process (this=0x2b259c2b2540) at /home/soak/src/cs/libs/csutil/cseventq.cpp:256
#11 0x00002b259bddc020 in csDefaultRunLoop (r=0x2b259c30eec0) at /home/soak/src/cs/libs/csutil/generic/runloop.cpp:99
#12 0x0000000000479ec5 in main (argc=1, argv=0x7fff7a26e3d8) at src/client/psengine.cpp:1896

if I smelt ores, I get 2 exp messages, e.g. if I smelt 45 gold ores I get:
"You gained some experience points and 3 progressions points!" and "You gained some experience points and 2 progressions points!"
similar if I cast a gold stock, I get "You gained some experience points and 1 progression point!" and "You gained some experience points."

in my opinion no fall damage should be applied if the position was reset due to an out of bounds position.
could be fixed by this patch

e.g. if you were standing at bd fortress and fell through the ground because of a not perfectly working bgloader(having alwaysrunnow disabled), you are moved to bdout and die

relaxing sleep seems to have the wrong spell animation. at least it’s not the same as it was in the RC and in 0.4.
(it has the effect electrotouch used to have i think)

each time you log in with your character and then successfully quit a newline is added to the end of planeshift.cfg
while not very severe, it grows the config file constantly and is a bit annoying

to reproduce:
- make sure there’s only one newline at the end of planeshift.cfg
- start psclient
- log in and select character
- once spawned ingame quit the client
- tail planeshift.cfg → there’s an additional newline

note: doesn’t seem to occur for pslaunch.cfg, psclient.cfg and psserver.cfg though

the part at the arms is transparent while sitting

for me NPC voices play very fast making it impossible to understand.
it at least plays 10x as fast as it should.

soundsysrenderer is set to software and other sounds play perfectly alright, e.g. thunder, background music, ambient sounds, etc.

to reproduce it on a trunk server with svn database:
- /runscript create_familiar
- run it again
you only see one familiar now named “Char’s Familiar” - do /pet name test
you see two familiars now, one named “Char’s Familiar” and “Test” - do /pet dismiss - one disappears
- do /pet dismiss again - message that you don’t have a pet summoned appears

the 2nd pet that you cannot dismiss will stay even after logging out, but will disappear on a server restart after which everything works as expected

pretty self descriptive - to reproduce an example of a consequence of it being allowed:
1) log into a server with svn db as guest
1a) find Mount1 - optional, just to be able to verify it better
2) do /pet 0, summon
2a) move a bit to see the pet you summoned - you should see Mount1 twice now, once where it spawned, once where you summoned it
3) do /pet dismiss

final result:
the Mount1 that was originally spawned disappears while the one you summoned stays

I got some weird lighting issues on my ATI 4830 HD that puts checkerboard-like lighting in nearly all areas.
If I adjust the brigthness up/down and back afterwards, everything looks perfectly alright.
It works perfectly on the very same system with my nvidia GeForce 6800 GT.

OS: Scientific Linux 5.2 x86_64
gfx drivers tried:
ATI: fglrx 9.11 x86_64 (from ati.amd.com)
nvidia: binary driver by nvidia (version 185.18.14 - packaged with Scientific Linux)

PS#2384 and PS#338 seem to have addressed the same issue

as an example, here’s a screenshot of East Hydlaa (HoM was due to corrupted art, but I got similiar effects with up-to-date release art) and one of Hydlaa Plaaza (this one was with art of the RC2 client):

there are spots you can see through for the male Ylian model - see screenshot

sacks stack while buying them which should not be possible as you cannot stack them once bought
solution needs an extra case for containers in psserverchar.cpp - HandleMerchantBuy

personalizing an item name doesn’t always work right now
source: src/server/psserverchar.cpp

if (CacheManager::GetSingleton().BasicItemStatsByNameExist(personalisedName) > 0)
    personalisedName.AppendFmt(" (%zu)", CacheManager::GetSingleton().ItemStatsSize()+1);

this does not guarantee that there’s not already an item with that name, yet
it’s easiest to reproduce on a local server with only you logged in

say there are 500 items in the database at the moment you start testing
if you buy the first personalized item, you get “item_name (501)” if you buy the second, you get “item_name (502)” now sell the one named “item_name (501)” there are 501 items in the database now, therefore if you try to buy the very same item now, the personalized name would be “item_name (502)” - though there’s already an item with this name which causes the creation of the item to fail and therefore you cannot buy a new one.

possible fix:

for(int i = 0; CacheManager::GetSingleton().BasicItemStatsByNameExist(personalisedName) > 0; i++)
    personalisedName.AppendFmt(" (%zu)", CacheManager::GetSingleton().ItemStatsSize()+1+i);

that’s very dirty, tho, so suggestions for a better way are welcome

the merchants in the npcroom have only 1 item of each kind. it’d be nice if they’d have more for testing, probably a stack each like on laanx

even with bgloading set to world, the client should load the map the char is currently on before getting ingame.
the way it is now, it’s - at least for me - very likely the char just keeps falling after logging in because the map is not loaded, yet.

tested on hydlaa plaaza/hydlaa east

to be removed - error on my side

tested on local trunk server.
hint during the load screen says “this is version crystal blue”

pslaunch let’s you select resolutions not supported which will result in a failed X request if you start the client.
tried on Scientific Linux 5.2 x86_64

using trunk client/cs build today
gfx card: ATI 4830 HD
gfx driver: fglrx 9.11
os: scientific linux 5.2 x86_64

note: appears only while looking outside in, not while standing inside

it is possible to jump REALLY high(even higher than the mounts already do) by unmounting your mount right before reaching the highest point of the jump.
this will result in your char getting thrown up from the mount kinda jumping off of it.
might be possible to avoid falling damage that way, too additionally the position of the mount reported seems to get corrupted that way. after the 2nd try i couldn’t remount the rivnak although i was standing in it getting the too far away message.

EDIT: managed to bork another mount this way. this time the target context didn’t appear (neither using right click nor using /targetcontext, though it was targetable and hp did shop up properly)

EDIT2: they mounts aren’t really “borked”, but their position is not shown correctly in the client. while they sink to the ground in the client, they actually remain where you unmounted them. you do see the real position if you mount/unmount anything nearby for an instant after which they start sinking to the ground, again

note: this is fixed by ingoring the height of the mount right now, still there are some methods for this method, e.g. if the mount is really high up, you cannot get the targetcontext, you can still mount it using /mount, anyway

if ezpc goes down, the message popping up says to check laanx.fragnetics.com which is wrong for ezpc