All Projects

When running PlaneShift with classic Mesa OpenGL drivers built in debug mode, my terminal output is spammed with a ton of:
Mesa: User error: GL_INVALID_VALUE in glTexParameter(param)

It turns out that PlaneShift is attempting to set GL_TEXTURE_MAX_ANISOTROPY_EXT to 0.0, which is illegal[1]…legal values are >= 1.0. pslaunch lists “0x” as one of the anisotropy options. Either this is just wrong (and should be removed—bug is in pslaunch), or else it’s supposed to mean “no filtering”, in which case the bug is that the engine still tries to enable it.

[1] http://www.opengl.org/registry/specs/EXT/texture_filter_anisotropic.txt

On client startup, shadowsEnabled is read before it’s initialized. This is clearly wrong.

==16593== Conditional jump or move depends on uninitialised value(s)
==16593== at 0x4BFD2B: psShadowManager::RecreateAllShadows() (shadowmanager.cpp:185)
==16593== by 0x4C0752: psShadowManager::EnableShadows() (shadowmanager.h:55)
==16593== by 0x4C0243: psShadowManager::Load(char const*) (shadowmanager.cpp:128)
==16593== by 0x4C049F: psShadowManager::psShadowManager() (shadowmanager.cpp:67)
==16593== by 0x48D6D2: psCelClient::Initialize(iObjectRegistry*, MsgHandler*, ZoneHandler*) (pscelclient.cpp:146)
==16593== by 0x43CCD4: psEngine::Initialize(int) (psengine.cpp:570)
==16593== by 0x50B6B4: pawsSplashWindow::Draw() (pawssplashwindow.cpp:63)
==16593== by 0x686D2F: pawsWidget::DrawChildren() (pawswidget.cpp:1221)
==16593== by 0x4C6A1A: psMainWidget::DrawChildren() (psmainwidget.cpp:524)
==16593== by 0x6383AF: PawsManager::Draw() (pawsmanager.cpp:606)
==16593== by 0x437C14: psEngine::HandleEvent(iEvent&) (psengine.cpp:867)
==16593== by 0x44BB06: psEngine::EventHandler::HandleEvent(iEvent&) (psengine.h:228)

Today the server was down for several hours due to a broken PVP zone. Such locations are completely non-essential, so the server should start even if they fail to load - it should just complain loudly. Better to have a server with no PVP zone than no server at all.

In the quest “Govell Mihdren Needs Tattoo Ink”, Levrus Dahrenn asks for four items, but all one at a time, in order. He even gives warning text that you need to have all four before giving them.

This should be updated to use the new multiple-item “player gives” syntax, so players can give all four at once with no risk of getting stuck. Also, the text “You’ll need to give me the iron first, but not until you have all four ingredients at the ready.” would no longer be necessary.

Given the following invalid XML script for an AL, the server dies horribly on updating proxlists/sending an AL - probably because it failed to load.

<Examine>
 <Container ID='31337'>
 <Description>A large smith table.</Description>
</Examine>   

(The correct script should be <Container ID=’31337’/> - note slash.)

One can probably reproduce this by taking the / out of a Container element, and logging in at that sector. We just hit this on Laanx; I haven’t tested with trunk.

StatsOp creates incorrect undo scripts for when the original script has adjust=”mul”.

Here is a case which shows the bug:
- Player has CHA 100.
- Script A runs: <cha adjust=”mul” value=”0.5” target=”actor”/> Player now has CHA 100 (50).
- Player equips a weapon which adds +30 to their CHA. Player now has CHA 100 (80).
- Wait. The undo for script A runs. This is <cha adjust=”mul” value=”2.0” target=”actor”/>…which doubles it.
- Player now has CHA 160, as it doubled the 80.

Clearly this is not correct: when the original script halved it, it amounted to -50. When the undo script doubled it, it amounted to +80. The player can repeat this procedure, gaining the extra +30 over and over again.

Progression scripts aren't saved/restored correctly on log out/log in.

For example:

(1) Spawn & drink 1 "Potion of Will".
(2) Note that you now have a +5 buff to Will.
(3) Log out.

Now, only the Undo script is saved to the database—not the original script.

(4) Log in.
(5) Note that you don't have the +5 buff to Will, or any special effects.
(6) Wait.

Finally, the potion will wear off, and the -5 buff to Will takes effect. You now have *less* Will than normal.

(1) Log in as Vengeance.
(2) Target an enemy (NPC or duelist)
(3) “/cast fire warts” a few times
(4) Wait until their HP reaches 0.

Server crash!

#0 0×0000000000495505 in gemActor::HandleDeath (this=0x1d41b50) at src/server/gem.cpp:2129
#1 0x00000000004e2546 in SpawnManager::HandleDeathEvent (this=0xc099f0, me=0x1d66a90)

  at src/server/spawnmanager.cpp:1044

#2 0x00000000007173bc in MsgHandler::Publish (this=0xbf2500, me=0x1d66a90)

  at src/common/net/msghandler.cpp:93

#3 0x00000000004a1133 in gemActor::DoDamage (this=0x1d41b50, attacker=0x1e37990, damage=0, damageRate=0,

  duration=<value optimized out>) at src/server/gem.cpp:2033

#4 0×0000000000677902 in psServerVitals::Update (this=0xcc1de0, now=<value optimized out>)

  at src/server/bulkobjects/../gem.h:614

#5 0x000000000066542d in psCharacter::UpdateStatDRData (this=0x2aaaabddc2d8, now=30678240)

  at src/server/bulkobjects/pscharacter.cpp:1605

#6 0x00000000004945a1 in gemActor::UpdateStats (this=0x1d41b50) at src/server/gem.cpp:2096
#7 0x0000000000498c1a in GEMSupervisor::UpdateAllStats (this=<value optimized out>)

  at src/server/gem.cpp:497

#8 0x000000000051706d in UserManager::UserStatRegeneration (this=0xbe7740)

  at src/server/usermanager.cpp:1338

#9 0x000000000072970d in EventManager::ProcessEventQueue (this=0xbf2500)

  at src/common/util/eventmanager.cpp:94

#10 0x00000000007299ae in EventManager::Run (this=0xbf2500) at src/common/util/eventmanager.cpp:207
#11 0x0000000000591c37 in proxyFunc (param=0x7fff9edca540) at libs/csutil/threading/pthread_thread.cpp:75

/yield currently sets both parties to PEACE. It should end in DEFEAT for the one yielding.

Tuxide reported that he had a stack of 13 Rock glyphs, and a full inventory. He tried to purify the glyph, and lost one. He did this several times, not realizing the server was eating his glyphs.

The bug is in src/server/spellmanager.cpp, StartPurifying. If Add fails, it just deletes the glyph, without resetting the stack count. It should do that.

Also it feels somewhat lame that Add didn’t work, but HowManyCanFit did. I realize HowManyCanFit doesn’t solve that problem, but its name implies that it should.

src/common/net/adminmessage.cpp has:
#include “../../server/globals.h”

The code queries the database - I believe in psDialogManager. Any code dealing with the database is obviously server-specific, and doesn’t belong in src/common. In practical terms, this requires part of the server to be built in order to build the client, which is just wrong.

Likely it’s intertwined with other code which needs to be common. We need to separate the two, and move the server-specific parts into src/server.

Chat bubbles don't use the incoming message filter.

Make sure the incoming message filter is on. Then, steps to reproduce:
(1) Target "Merchant"
(2) "give me a quest"
(3) "done"

You'll see in the chat window, "by the gods you did it!", but in the bubble, "OMG you did it!"

This could probably be a prospect task.

Dueling is broken.

(1) A /challenges B.
(2) B kills A.
(3) A respawns.

Both parties can still attack one another. Note that if A kills B, this is not the case.

(1) Put a Claymore in a Sack
(2) Drop the sack
(3) Pick up the sack

…the claymore’s still in the db with the sack as its parent, but in the server’s model, wasn’t added to the inventory.

It’s possible to get 65534 items. I believe this occurs when the client sends a stack count message which is larger than the item’s actual count. One ought to be able to hack the client to do this; another is to do the following:

Using account “Lady Aren” and a fresh DB… (1) Spawn a Claymore and equip it in your right hand (slot 0)
(2) Spawn 3 Nitroglycerin.
(3) Log out.

(4) Connect to the DB and:
SELECT I.id, name, location_in_parent, parent_item_id, stack_count FROM item_instances I JOIN item_stats S ON item_stats_id_standard = S.id WHERE char_id_owner = 9;

Verify that the Nitroglycerin has a higher UID than the Claymore.

UPDATE item_instances SET location_in_parent = 0 (slot of the Claymore) WHERE id = (the UID of the Nitroglycerin).

This manually forces both into the same slot—shouldn’t be possible, but at one point was triggered by bugs.

(5) Log in again, you should see 3 Nitroglycerin and no Claymore.
- (If you right click on it, you’ll probably view the Claymore.)
(6) Select 3 Nitroglycerin and move them to an empty slot.

Check the DB. You now have 65534 (2^16 + 1 claymore - 3 nitroglycerin) claymores.