Wojta

SESSION: opcode CMSG_CHANGE_SEATS_ON_CONTROLLED_VEHICLE (0x049B) have unprocessed tail data (read stop at 40 from 74)

I get this when I try to change seat in vehicle with accessory. Where is packet size defined? Where can I set to ignore this?

Why this appear? Packet is longer than expected? Unexpected data type in packet?

We could post this to blizz

thx, in http://github.com/Tasssadar/Valhalla-Project/commit/41caefa4f273542654c30686726aa105de322b9b

http://github.com/Tasssadar/Valhalla-Project/commit/d30a4f26c1608ad270135e0a4a87b3dcf2762a16

thanks anti

EDIT: http://github.com/Tasssadar/Valhalla-Project/commit/017a4a0ffd04330a86b1c677ffa201956e4adf86

...and thanks x.e.x

Wojta there is no way to spawn a vehicle instead a creature. And I has come to a conclusion that is right and blizzlike.

In the wintergrasp and the ulduar a vehicles must be spawned by a script.

I think there is no problem as we thought earlier.

Yes..but there are many Q in NR which uses vehicles, and there are pre-spawned here, for example: http://www.wowhead.com/?quest=12326#. or http://www.wowhead.com/?quest=12856#. and theres many more of them but maybe when you click on them, new vehicle spawns and the old one despawns(not die, despawn), so it does not look so horrible but if its not vehicle, you cant see accessories, and in ulduar there are many vehicles near flame levithian(they are flying, http://www.wowhead.com/?npc=33214). Script for spawns like that would be really big )

ArtUrlWWW: never, because I using this GIT for my server

./dbc/BattlemasterList.dbc (exist, but have 31 fields instead 35) Wrong client version DBC file?

http://bitbucket.org/KingPin/trinitycore2/changeset/3cc19474e78c/

Wintergrasp: on trinity its done like OutdoorPvP, so it wont be so easy to port it to mangos....

http://one-b1og.eu/vehicle/ ... ?

BTW looks like we have to start from beginning, I just hope we have enough knowledge

You mean that in this patch they cant turn? But for me it works...not with WASD, but try to hold both mouse buttons and move with it...

TODO: Accesoryes can turn but not move.

And...thats wrong? I mean they are in seats, so they move with vehicle...

The main problem is, that vehicles are creatures. We need to discuss it and choose a right way to implement a vehilces.

We must spawn vehicle, not creature. May be smbd knows a right way to implement it.

It looks like base idea of current patch is wrong

SESSION: opcode CMSG_CHANGE_SEATS_ON_CONTROLLED_VEHICLE (0x049B) have unprocessed tail data (read stop at 40 from 74)

I get this when I try to change seat in vehicle with accessory. Where is packet size defined? Where can I set to ignore this?

//VF_HAS_FUEL                     = 0x0100,                   // TODO : find out what energy type is fuel and implement this

This is used for example in Ulduar vehicles I think...(on TC2 it works, I think we can inspire..)

As i said: When you spawn vehicle(.npc add) its not vehicle, but normal creature.

Flying vehicles does not work? I tried frost wyrm from DK start location, and it cant fly. Maybe just wrong movement type, on rastikzzz's patch it worked fine

Accessories is not complete, when vehicle dies accessory not, etc(but Im working on this)

Thats all I found...

I promise I'll improve my skill in english

Well, I should do the same

http://github.com/Tasssadar/Valhalla-Project/commit/d37214184d416d55dc54b15fb24e97d4af2d8a04 - so for example wintergrasp siege tanks have turrets - and you can shot from them when somebody else drive vehicle!

For a tests it's possible to use the wintergrasp code from TC2.

Can you send me more detailed descriptions about this bugs?

About vehicles or Wintergrasp?

All repos/pathes which implements a vehicle are the same.

Only in Wojta's repo i have seen some improvements.

added

To Wojta; would be fine to unite the vehicle and wintergrasp (but first it must be created) branches. And develop it as one task. How you think?

Well, we can try it, but at first we need to solve some problems with vehicles (steam power, when you spawn vehicle it is only creature etc). But if somebody want, it would be good to write code for Wintergrasp end/start a correct queue players into battle.

Sorry, I wont do this, because insader's branch is (really) custom. But you can clone insiders branch, then pull my branch and solve conflicts...

There is one problem with current vehicle patch - when you spawn for example wintergrasp siege tank, it is NOT a vehicle - it will became vehicle after somebody clicks onto it, and thats wrong. But sadly, I have not enough knowledge to solve this. Please help, if you can

Because my master branch is not clear, I have some patches in there. try...

git clone git://github.com/mangos/mangos.git
cd mangos
git pull git://github.com/Tasssadar/Valhalla-Project.git vehicle
<your dual spec patch>

EDIT: I just ported accessories system from TC2: http://github.com/Tasssadar/Valhalla-Project/commit/ce7dae7565a981a9b5694966ed0fc492e7a02c63

Some issues:

- This mangos patch is different than on TC2, so there are some problems:

You cant see accessories on vehicle before you get on it

When you enter accessories, it despawns and create new vehicle

When vehicle dies, Accessories does not dissapear

- Accessories is hardcoded, I plan to move it into DB table

You are trying to pull my master branch, you have to pull branch named "vehicle"

I created git branch for this patch(260kb patch file sux):

git pull git://github.com/Tasssadar/Valhalla-Project.git vehicle

At least I will keep it up-to-date, and if I will have some time, I will try to improve it.

There should be a diff:

diff --git a/src/game/Unit.cpp b/src/game/Unit.cpp
index 701e5ec..d5c17fa 100644
--- a/src/game/Unit.cpp
+++ b/src/game/Unit.cpp
@@ -3962,6 +3962,50 @@ void Unit::RemoveSingleAuraDueToSpellByDispel(uint32 spellId, uint64 casterGUID,
            dispeler->CastCustomSpell(dispeler, 31117, &damage, NULL, NULL, true, NULL, NULL,casterGUID);
        }
    }
+    // Lava Flows
+    else if (spellEntry->SpellFamilyName == SPELLFAMILY_SHAMAN && (spellEntry->SpellFamilyFlags & UI64LIT(0x10000000)))
+    {
+        Unit* caster = NULL;
+        uint32 triggeredSpell = 0;
+ 
+        if (Aura* dotAura = GetAura(SPELL_AURA_PERIODIC_DAMAGE, SPELLFAMILY_SHAMAN, UI64LIT(0x10000000), 0x00000000, casterGUID))
+            caster = dotAura->GetCaster();
+ 
+        if (caster && !caster->isDead())
+        {
+            Unit::AuraList const& auras = caster->GetAurasByType(SPELL_AURA_DUMMY);	
+            for (Unit::AuraList::const_iterator i = auras.begin(); i != auras.end(); i++)
+            {
+                switch((*i)->GetId())
+                {
+                    case 51480: 
+                    {
+                        triggeredSpell = 64694;
+                        break;
+                    }
+                    case 51481:
+                    {
+                        triggeredSpell = 65263;
+                        break;
+                    }
+                    case 51482:
+                    {
+                        triggeredSpell = 65264;
+                        break;
+                    }
+                    default: 
+                        continue;
+                }
+                break;
+            }
+        }
+        // Remove spell auras from stack
+        RemoveSingleSpellAurasByCasterSpell(spellId, casterGUID, AURA_REMOVE_BY_DISPEL);
+ 
+        // Haste
+        if (triggeredSpell)
+            caster->CastSpell( caster, triggeredSpell, true);	                
+    }
    else
        RemoveSingleSpellAurasByCasterSpell(spellId, casterGUID, AURA_REMOVE_BY_DISPEL);
}

did you read my previous post?

I dont think that crash is related to this patch. 52372 is icy touch....

About sending packets to client:

   static const AuraType auratypes[] =
   {
       SPELL_AURA_MOD_FEAR,     SPELL_AURA_TRANSFORM,                 SPELL_AURA_WATER_WALK,
       SPELL_AURA_FEATHER_FALL, SPELL_AURA_HOVER,                     SPELL_AURA_SAFE_FALL,
-       SPELL_AURA_FLY,          SPELL_AURA_MOD_INCREASE_FLIGHT_SPEED,   SPELL_AURA_NONE
+      SPELL_AURA_FLY,          SPELL_AURA_MOD_INCREASE_FLIGHT_SPEED,   SPELL_AURA_IGNORE_UNIT_STATE
+     SPELL_AURA_NONE
   }; 

I did this in V5b, and as you can try, it does not work

On second thought:

Why not add it here, and send the packet from the handler?

Also, why don't use this to send it in the handler?

if(this->isPassive())
   {
       SetAuraSlot(255);
       SetAuraFlags(19);
       SendAuraUpdate(false);
   }

Is the exact 255 slot needed?

I dont know what version are you watching, but I am using this since V5...

However I think we sholud use something like SpellMod mechanic here - Aura 262,263 spells have EffectSpellClassMask set, and are similar (Allow masked, disallow masked, modify masked)

PS. 263 is set implictly - allows only one spell

I have not any experiences with that....

to lynx3d: no, execute works fine, i tested this.

to darkstalker: so you suggest to implent this with getAurasByType()? Maybe i am not enought experienced, but i dont know why its better. please, explain.

Hello,

I have one problem:

2009-11-30 20:49:15 ERROR:HandleMoveNotActiveMover: incorrect mover guid: mover is 0000000000000229 and should be 0000000000000229 instead of 553

And I have these questions:

1. Can this crash server? Because after that follows "Segmentation Error" and server crashs.

2. When client sends this packet?

3. What this packet doing?

Thanks for answers

EDIT: There was something else which causes crash, but anyway, what this packet doing?

bump...stop fast-owls!