Too many wheels preventing tank from firing?
by Michael Goldener · in Torque Game Engine · 02/16/2005 (6:42 pm) · 5 replies
Never mind the topic ;) I have to explain my problem more detailed.
I'm currently adding tanks to my game which are made up from a Turret that gets mounted to a WheeledVehicle. Because stock torque allows a maximum of eight wheels on a vehicle and I needed more I simply increased WheeledVehicleData::MaxWheels from 8 to 16. Everything seemed to work just fine until I tried to actually fire the tank's turret. No projectile showed up although a projectile was created on the server. After a loooong time of frustrating debugging I decided to change the number of wheels back to eight, even though I couldn't imagine that this was even remotely related to the problem. But of course it was :)
So I looked at a bunch of places where the number of wheels might be a factor and noticed that WheeledVehicle::packUpdate() sends a lot of data concerning every wheel to the client if the PositionMask is set, which - conveniently enough - gets set on every tick.
I have no profound understanding of torque's networking and wondered how the amount of data sent in this function could have an influence on the (not) ghosting of the projectile. But after some digging I came up with the following theory:
When NetConnection::ghostWritePacket() calls packUpdate(), the amount of data that WheeledVehicle's packUpdate() is writing when the vehicle has 16 wheels is actually enough to fill the packet, so that the ghost-info of the newly created projectile is dropped from the packet. Aside from the surprise that the vehicle's update priority is actually higher than that of a projectile that hasn't yet ghosted to the client I didn't expect this to be a big deal since the projectile's priority increases with every dropped packet. But as it turns out, the vehicle's priority increases as well. This behaviour combined with the fact that the vehicle's priority is already a bit higher because a client-controlled turret is on top of it lead to my problem: The projectile's ghost-packet is never sent.
I would really appreciate it if someone with a better understanding of the subject would tell me if my theory is at all possibly valid before I type even more or try to come up with some crazy solution to the problem ;)
Update: Turns out the vehicle's priority does not increase, but at the time the projectile's priority is higher than the vehicle's it's already out of scope.
I'm currently adding tanks to my game which are made up from a Turret that gets mounted to a WheeledVehicle. Because stock torque allows a maximum of eight wheels on a vehicle and I needed more I simply increased WheeledVehicleData::MaxWheels from 8 to 16. Everything seemed to work just fine until I tried to actually fire the tank's turret. No projectile showed up although a projectile was created on the server. After a loooong time of frustrating debugging I decided to change the number of wheels back to eight, even though I couldn't imagine that this was even remotely related to the problem. But of course it was :)
So I looked at a bunch of places where the number of wheels might be a factor and noticed that WheeledVehicle::packUpdate() sends a lot of data concerning every wheel to the client if the PositionMask is set, which - conveniently enough - gets set on every tick.
I have no profound understanding of torque's networking and wondered how the amount of data sent in this function could have an influence on the (not) ghosting of the projectile. But after some digging I came up with the following theory:
When NetConnection::ghostWritePacket() calls packUpdate(), the amount of data that WheeledVehicle's packUpdate() is writing when the vehicle has 16 wheels is actually enough to fill the packet, so that the ghost-info of the newly created projectile is dropped from the packet. Aside from the surprise that the vehicle's update priority is actually higher than that of a projectile that hasn't yet ghosted to the client I didn't expect this to be a big deal since the projectile's priority increases with every dropped packet. But as it turns out, the vehicle's priority increases as well. This behaviour combined with the fact that the vehicle's priority is already a bit higher because a client-controlled turret is on top of it lead to my problem: The projectile's ghost-packet is never sent.
I would really appreciate it if someone with a better understanding of the subject would tell me if my theory is at all possibly valid before I type even more or try to come up with some crazy solution to the problem ;)
Update: Turns out the vehicle's priority does not increase, but at the time the projectile's priority is higher than the vehicle's it's already out of scope.
#2
to
@Joe: The Tank Pack is overkill for me since I'm basically happy with my tanks. Plus it was more the thought of players not recieving any ghost packet updates just because they're driving a vehicle with more than eight wheels that bothered me than an issue with the tanks.
02/16/2005 (8:22 pm)
To get things to work again I simply decided to give wannabe-ghosts a top priority (the way it's already done with ghost that need to be removed).engine/sim/netGhost.cc: (around line 342) if(walk->flags & GhostInfo::KillGhost) walk->priority = 10000; else walk->priority = walk->obj->getUpdatePriority(&camInfo, walk->updateMask, walk->updateSkipCount);
to
if(walk->flags & GhostInfo::KillGhost) walk->priority = 10000; else if(walk->flags & GhostInfo::NotYetGhosted) walk->priority = 10000; else walk->priority = walk->obj->getUpdatePriority(&camInfo, walk->updateMask, walk->updateSkipCount);
@Joe: The Tank Pack is overkill for me since I'm basically happy with my tanks. Plus it was more the thought of players not recieving any ghost packet updates just because they're driving a vehicle with more than eight wheels that bothered me than an issue with the tanks.
#3
The tank pack addresses this, I believe. I would strongly suggest using it to solve your problem rather than messing with deep innards of the engine.
02/19/2005 (5:06 pm)
That's probably not the best idea, as it means that even very distant objects are going to pop in immediately, and it totally hoses updates in a lot of cases. The fact you have loads of wheels means the updates prob aren't important. Why not only update a few and make the rest virtual?The tank pack addresses this, I believe. I would strongly suggest using it to solve your problem rather than messing with deep innards of the engine.
#4
Anyway, I modified the way WheeledVehicle transmits data to the clients which solved my initial problem without having to mess with deep innards of the engine, as you said.
02/19/2005 (8:09 pm)
Thanks. I had the feeling that assigning such a fixed priority to all wannabe-ghosts wasn't the smartest way to solve the problem. ;)Anyway, I modified the way WheeledVehicle transmits data to the clients which solved my initial problem without having to mess with deep innards of the engine, as you said.
#5
Currently in the game that Me and a few of my friends are trying to make, there is a vehicle that requires 24 wheels total. I increased the maxwheels to 300 in the maxwheels.cc or .h i can't remember. any way i was wondering if you could post what you did to the engine data, cuz the gun on this vehicle is very large.
12/14/2005 (5:57 am)
I was currious,Currently in the game that Me and a few of my friends are trying to make, there is a vehicle that requires 24 wheels total. I increased the maxwheels to 300 in the maxwheels.cc or .h i can't remember. any way i was wondering if you could post what you did to the engine data, cuz the gun on this vehicle is very large.
Torque Owner Joe Maruschak
I don't want to sound too much like an advertisement.. but this sounds like it might work for yoru needs.