Re: [hlcoders] Linux dedicated game server won't load any sound scripts or soundscapes
Found the issue. Turns out the dedicated server depot for SDK 2013 lacks 2 libs: scenefilecache.so and soundemittersystem.so. While games as CS:S work fine without those, mods complain about those missing files and server shuts down with this message: AppFramework : Unable to load module soundemittersystem.so! Unable to load interface VSoundEmitter002 from soundemittersystem.so So I copied those from the client repository and that was my mistake. You either create a symlink from their respective _srv versions or just copy and rename them, never take the ones meant for clients. That solves the error related to game_sounds_manifest.txt load, not the soundscapes manifest one though. TL:DR linux dedicated server is broken, it won't even load and trying to fix it may cause further issues. > > File encoding was one of the things I looked at before posting here, in any > case I repeat that linux client is able to load sound scripts and > soundscapes when listen server is created. They are the same base sound > scripts, same game libs, etc. The SDK bin directory may differ a bit I > guess since dedicated servers require a few different libs. > > I tried a gcc 4.8 compile just in case. No improvement, the stock SDK build > shows same issue. I don't really know what else to try. > > To be honest, I'd not care anymore about this mess if it wasn't because the > current version of my mod on Steam is a nice engineered backdoor disguised > as game. It's not my fault, I merged the fixes the first day they were > available, I can't just ship a mod that gets near 2 million installs > without sounds working properly. > > Thanks anyway. > > > > >It's probably the encoding of the txt file. > >>>* On Tue, Oct 6, 2015 at 12:31 AM, Rebel Yell >>><http://gmail.com> > >>><https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders > >>><https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders>>> wrote: > *>>* >* I decided to compile the stock SDK 2013 code today and the linux build > *>* *>* outputs the same error message when dedicate server is loading: > *>* *>>* CSoundscapeSystem::Init: Manifest > 'scripts/soundscapes_manifest.txt' with > *>* *>* bogus file type 'ls/extinguish2_subrect', expecting 'file' > *>* *>>* Also note that these message errors appear no matter if > *>* *>* soundscapes_manifest.txt is present or not, it's like the actual file > isn't > *>* *>* used at all. > *>* *>>* My linux test machine uses Ubuntu 12.04.3 x86 and I compiled the > code with > *>* *>* gcc 4.6 > *>* *>>* Do you guys think there's an error in my setup or this engine build > isn't > *>* *>* functioning properly? > *>* * > *>> > > ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders
Re: [hlcoders] Linux dedicated game server won't load any sound scripts or soundscapes
File encoding was one of the things I looked at before posting here, in any case I repeat that linux client is able to load sound scripts and soundscapes when listen server is created. They are the same base sound scripts, same game libs, etc. The SDK bin directory may differ a bit I guess since dedicated servers require a few different libs. I tried a gcc 4.8 compile just in case. No improvement, the stock SDK build shows same issue. I don't really know what else to try. To be honest, I'd not care anymore about this mess if it wasn't because the current version of my mod on Steam is a nice engineered backdoor disguised as game. It's not my fault, I merged the fixes the first day they were available, I can't just ship a mod that gets near 2 million installs without sounds working properly. Thanks anyway. It's probably the encoding of the txt file. > > > On Tue, Oct 6, 2015 at 12:31 AM, Rebel Yell <https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders>> wrote: > > >* I decided to compile the stock SDK 2013 code today and the linux build > *>* outputs the same error message when dedicate server is loading: > *>>* CSoundscapeSystem::Init: Manifest 'scripts/soundscapes_manifest.txt' > with > *>* bogus file type 'ls/extinguish2_subrect', expecting 'file' > *>>* Also note that these message errors appear no matter if > *>* soundscapes_manifest.txt is present or not, it's like the actual file > isn't > *>* used at all. > *>>* My linux test machine uses Ubuntu 12.04.3 x86 and I compiled the code > with > *>* gcc 4.6 > *>>* Do you guys think there's an error in my setup or this engine build isn't > *>* functioning properly? > * > > ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders
Re: [hlcoders] Linux dedicated game server won't load any sound scripts or soundscapes
I decided to compile the stock SDK 2013 code today and the linux build outputs the same error message when dedicate server is loading: CSoundscapeSystem::Init: Manifest 'scripts/soundscapes_manifest.txt' with bogus file type 'ls/extinguish2_subrect', expecting 'file' Also note that these message errors appear no matter if soundscapes_manifest.txt is present or not, it's like the actual file isn't used at all. My linux test machine uses Ubuntu 12.04.3 x86 and I compiled the code with gcc 4.6 Do you guys think there's an error in my setup or this engine build isn't functioning properly? ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders
[hlcoders] Linux dedicated game server won't load any sound scripts or soundscapes
I'm getting this new error after the code merge from latest push on github. No sounds that originate from server will play for clients, and most dedicated servers for my mod are Linux based so this is a critical bug for me. In essence: my Linux dedicated server build won't load any sound script. Related console error: *CSoundEmitterSystemBase::BaseInit: Manifest 'scripts/game_sounds_manifest.txt' with bogus file type '', expecting 'declare_file' or 'precache_file'* The returned string is null, right? The source script file itself is perfectly normal. It doesn't make any sense, no related issues on Windows OS and even the listen server on Linux works fine. In a similar manner, soundscapes won't load either. This other issue isn't new actually, it happened before the latest SDK update. Again, only in Linux dedicated. Console error: *CSoundscapeSystem::Init: Manifest 'scripts/soundscapes_manifest.txt' with bogus file type 't', expecting 'file'* ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders
Re: [hlcoders] Source SDK 2013 Release
Ignore this... I found the problem on my side, a header file differing in a way that won't terminate Windows build but crashes Linux and OSX. Quite a weird one, I actually got after it when the Windows build begun to crash in same manner than others. Yay for consistency. -- -- > Hello, any news regarding this? > > >I'll take a look. It's possible we broke the CModelInfo ABI in a way that > >* sourcetest doesn't hit. > *> > >* A crash issue here. After merging the code I get both Windows and Linux > *>>* server running, Windows client working fine too but Linux and OSX clients > *>>* will crash after map load, here's the trace: > ** 0 engine.dylib0x0a87105f > *>>* CModelInfo::GetModelType(model_t const*) const + 31 > *>>* 1 client.dylib0x1d114ea9 > *>>* CClientLeafSystem::NewRenderable(IClientRenderable*, RenderGroup_t, int) > + > *>>* 121 > *>>* 2 client.dylib0x1d115010 > *>>* CClientLeafSystem::CreateRenderableHandle(IClientRenderable*, bool) + 96 > *>>* 3 engine.dylib0x0a8f3529 > *>>* CStaticPropMgr::LevelInitClient() + 169 > *>>* 4 engine.dylib0x0a763c31 CL_FullyConnected() + 49 > *>>* 5 engine.dylib0x0a73d067 > *>>* CClientState::SetSignonState(int, int) + 823 > *>>* 6 engine.dylib0x0a7200bb > *>>* CBaseClientState::ProcessPacketEntities(SVC_PacketEntities*) + 219 > *>>* 7 engine.dylib0x0a8d4776 > *>>* CClientState::ProcessPacketEntities(SVC_PacketEntities*) + 182 > *>>* 8 engine.dylib0x0a8d47ab non-virtual thunk to > *>>* CClientState::ProcessPacketEntities(SVC_PacketEntities*) + 27 > *>>* 9 engine.dylib0x0a68fc98 > *>>* SVC_PacketEntities::Process() + 24 > *>>* 10 engine.dylib0x0a8914eb > *>>* CNetChan::ProcessMessages(bf_read&) + 843 > *>>* 11 engine.dylib0x0a891c6c > *>>* CNetChan::CheckReceivingList(int) + 380 > *>>* 12 engine.dylib0x0a8926ff > *>>* CNetChan::ProcessPacket(netpacket_s*, bool) + 751* > > ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders
Re: [hlcoders] Source SDK 2013 Release
Hello, any news regarding this? I'll take a look. It's possible we broke the CModelInfo ABI in a way that > sourcetest doesn't hit. > > A crash issue here. After merging the code I get both Windows and Linux >> server running, Windows client working fine too but Linux and OSX clients >> will crash after map load, here's the trace: >> >> 0 engine.dylib0x0a87105f >> CModelInfo::GetModelType(model_t const*) const + 31 >> 1 client.dylib0x1d114ea9 >> CClientLeafSystem::NewRenderable(IClientRenderable*, RenderGroup_t, int) + >> 121 >> 2 client.dylib0x1d115010 >> CClientLeafSystem::CreateRenderableHandle(IClientRenderable*, bool) + 96 >> 3 engine.dylib0x0a8f3529 >> CStaticPropMgr::LevelInitClient() + 169 >> 4 engine.dylib0x0a763c31 CL_FullyConnected() + 49 >> 5 engine.dylib0x0a73d067 >> CClientState::SetSignonState(int, int) + 823 >> 6 engine.dylib0x0a7200bb >> CBaseClientState::ProcessPacketEntities(SVC_PacketEntities*) + 219 >> 7 engine.dylib0x0a8d4776 >> CClientState::ProcessPacketEntities(SVC_PacketEntities*) + 182 >> 8 engine.dylib0x0a8d47ab non-virtual thunk to >> CClientState::ProcessPacketEntities(SVC_PacketEntities*) + 27 >> 9 engine.dylib0x0a68fc98 >> SVC_PacketEntities::Process() + 24 >> 10 engine.dylib0x0a8914eb >> CNetChan::ProcessMessages(bf_read&) + 843 >> 11 engine.dylib0x0a891c6c >> CNetChan::CheckReceivingList(int) + 380 >> 12 engine.dylib0x0a8926ff >> CNetChan::ProcessPacket(netpacket_s*, bool) + 751 > > ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders
Re: [hlcoders] Source SDK 2013 Release
A crash issue here. After merging the code I get both Windows and Linux server running, Windows client working fine too but Linux and OSX clients will crash after map load, here's the trace: 0 engine.dylib0x0a87105f CModelInfo::GetModelType(model_t const*) const + 31 1 client.dylib0x1d114ea9 CClientLeafSystem::NewRenderable(IClientRenderable*, RenderGroup_t, int) + 121 2 client.dylib0x1d115010 CClientLeafSystem::CreateRenderableHandle(IClientRenderable*, bool) + 96 3 engine.dylib0x0a8f3529 CStaticPropMgr::LevelInitClient() + 169 4 engine.dylib0x0a763c31 CL_FullyConnected() + 49 5 engine.dylib0x0a73d067 CClientState::SetSignonState(int, int) + 823 6 engine.dylib0x0a7200bb CBaseClientState::ProcessPacketEntities(SVC_PacketEntities*) + 219 7 engine.dylib0x0a8d4776 CClientState::ProcessPacketEntities(SVC_PacketEntities*) + 182 8 engine.dylib0x0a8d47ab non-virtual thunk to CClientState::ProcessPacketEntities(SVC_PacketEntities*) + 27 9 engine.dylib0x0a68fc98 SVC_PacketEntities::Process() + 24 10 engine.dylib0x0a8914eb CNetChan::ProcessMessages(bf_read&) + 843 11 engine.dylib0x0a891c6c CNetChan::CheckReceivingList(int) + 380 12 engine.dylib0x0a8926ff CNetChan::ProcessPacket(netpacket_s*, bool) + 751 I'm quite sure my SDK bin/ directory is up to date with the beta_test branch files since my mod is standalone (Fistful of Frags), I triple checked that. So I don't see where the problem is, maybe wrong engine (or other) library for Linux/OSX? ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlcoders
Re: [hlcoders] Muzzle flash showing in every view space.
I wish it's some model issue because I'm not aware of any modification in the muzzle filtering, and I'm the only one messing the source code. Also take in mind, as I said in first message, this issue doesn't happen in our rifles/shotguns, they use CTempEnts::MuzzleFlash_Shotgun_ There could be something broken in CTempEnts::MuzzleFlash_Pistol_, but that got discarded once I checked that pistols using shotgun muzle code keep failing. Don't know if I should check something more, but our code is pretty much default in every thing else related to muzzle events. Well, let's see if some additional checking in our weapon models solves this issue. This is also odd because the same guy that made some working models should know how to do the rest. I did some testing myself, tried with HL2MP 357 but couldn't see the world model for some reason, so that test was inconclusive. Ángel Oliver (R_Yell) - Original Message - From: Ben Everett [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Friday, March 09, 2007 1:34 AM Subject: RE: [hlcoders] Muzzle flash showing in every view space. Forsaken had that issue before, it turned out to be a problem with the actual models. If I recall, it was how the parent bones were setup as well as the bone/attachment orientations for the muzzle effect. If that isn't it, what Minh said about the effect not being filtered could be the problem. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Minh Sent: Thursday, March 08, 2007 5:39 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Muzzle flash showing in every view space. -- [ Picked text/plain from multipart/alternative ] hmm that is very weird. So basically, another player fires, and a muzzleflash sprite gets created on every player, not just the one doing the firing... Seems like the dispatcheffect is not being filtered properly (ie. your sending the muzzleflash event to the wrong clients). It's really hard to tell without seeing your code. - Original Message - From: REBEL [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Thursday, March 08, 2007 3:03 PM Subject: Re: [hlcoders] Muzzle flash showing in every view space. Okay, this is even better than a screenshot. I made a small video where the issue can be seen quite well. Hope it helps you: http://www.sendspace.com/file/m55otq That ghost muzzle cannot be seen in world view, and it doesn't spawn exactly in weapon's muzzle attachment. If character ducks that muzzle keeps showing in the same coordinates, it doesn't modify its position if player doesn't move. That test was made with a modified c_te_legacytempents file which produces more smoke but the muzzle issue happens the same with default c_te file. That's important because thats the place where muzzle sprites are created AFAIK, so default code makes the same effect. Ángel Oliver (R_Yell) - Original Message - From: Minh [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Thursday, March 08, 2007 7:54 PM Subject: Re: [hlcoders] Muzzle flash showing in every view space. -- [ Picked text/plain from multipart/alternative ] DoMuzzleFlash() doesn't actually create the sprite on the screen. As far as I can tell, it sets a parity bit on an entity. Why dont you take a screenshot to show us what your problem is. If you're having problems capturing muzzleflashes (since they happen so fast). Just use the command host_timescale 0.1 That will slow down the game to 10% of the normal speed. Original Message - From: REBEL [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Thursday, March 08, 2007 7:56 AM Subject: Re: [hlcoders] Muzzle flash showing in every view space. Thank you very much for the replies, I'm trying to dig into this issue but wasn't able to discover anything ATM. Our weapons cloned from 357 code are pretty much the same than default, only modified some values related to accuracy, etc. I'm using the latest SDK from November, all code the muzzleflash code wasn't touched. There were a few additions to c_te_legacytempents, so I tried with default file and no improvements. there are TWO events that are responsible for creating the muzzleflash. One of the events is embedded in the view model's primary attack sequence. The 2nd event is embedded inside the world model (w_357.cpp) I noticed there is no pPlayer-DoMuzzleFlash(); in my weapon_357.cpp, there wasn't any by default. It exist on other weapons, but not in the 357. I tried to comment the other event in basecombatweapon_shared and nothing happened, muzzleflash works the same so this confusses me a lot. Is pPlayer-DoMuzzleFlash() supposing to do something in multiplayer? At this point I have the doubt if we really did something wrong with the weapon models. Could a wrong muzzle attachment cause this? Ángel Oliver (R_Yell) - Original Message - From: Minh
Re: [hlcoders] Muzzle flash showing in every view space.
Seems I got it, there is a second CTempEnts::MuzzleFlash which is maked as
obsolete and for some reason is still working except for CS. Once I got rid
of it that ghost muzzle is gone. A few days wasted in this, how hard is the
coder's life :D. Thank you for your time guys, I really appreciate it.
//-
// Purpose: Play muzzle flash
// Input : *pos1 -
// type -
//-
void CTempEnts::MuzzleFlash( const Vector pos1, const QAngle angles, int
type, ClientEntityHandle_t hEntity, bool firstPerson )
{
#ifdef CSTRIKE_DLL
return;
#else
//NOTENOTE: This function is becoming obsolete as the muzzles are moved over
to being local to attachments
Ángel Oliver (R_Yell)
- Original Message -
From: REBEL [EMAIL PROTECTED]
To: hlcoders@list.valvesoftware.com
Sent: Friday, March 09, 2007 11:53 AM
Subject: Re: [hlcoders] Muzzle flash showing in every view space.
I wish it's some model issue because I'm not aware of any modification in
the muzzle filtering, and I'm the only one messing the source code. Also
take in mind, as I said in first message, this issue doesn't happen in our
rifles/shotguns, they use CTempEnts::MuzzleFlash_Shotgun_
There could be something broken in CTempEnts::MuzzleFlash_Pistol_, but that
got discarded once I checked that pistols using shotgun muzle code keep
failing. Don't know if I should check something more, but our code is pretty
much default in every thing else related to muzzle events.
Well, let's see if some additional checking in our weapon models solves this
issue. This is also odd because the same guy that made some working models
should know how to do the rest. I did some testing myself, tried with HL2MP
357 but couldn't see the world model for some reason, so that test was
inconclusive.
Ángel Oliver (R_Yell)
- Original Message -
From: Ben Everett [EMAIL PROTECTED]
To: hlcoders@list.valvesoftware.com
Sent: Friday, March 09, 2007 1:34 AM
Subject: RE: [hlcoders] Muzzle flash showing in every view space.
Forsaken had that issue before, it turned out to be a problem with the
actual models. If I recall, it was how the parent bones were setup as well
as the bone/attachment orientations for the muzzle effect.
If that isn't it, what Minh said about the effect not being filtered could
be the problem.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Minh
Sent: Thursday, March 08, 2007 5:39 PM
To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] Muzzle flash showing in every view space.
--
[ Picked text/plain from multipart/alternative ]
hmm that is very weird. So basically, another player fires, and a
muzzleflash sprite gets created on every player, not just the one doing the
firing...
Seems like the dispatcheffect is not being filtered properly (ie. your
sending the muzzleflash event to the wrong clients). It's really hard to
tell without seeing your code.
- Original Message -
From: REBEL [EMAIL PROTECTED]
To: hlcoders@list.valvesoftware.com
Sent: Thursday, March 08, 2007 3:03 PM
Subject: Re: [hlcoders] Muzzle flash showing in every view space.
Okay, this is even better than a screenshot. I made a small video where the
issue can be seen quite well. Hope it helps you:
http://www.sendspace.com/file/m55otq
That ghost muzzle cannot be seen in world view, and it doesn't spawn
exactly in weapon's muzzle attachment. If character ducks that muzzle keeps
showing in the same coordinates, it doesn't modify its position if player
doesn't move.
That test was made with a modified c_te_legacytempents file which produces
more smoke but the muzzle issue happens the same with default c_te file.
That's important because thats the place where muzzle sprites are created
AFAIK, so default code makes the same effect.
Ángel Oliver (R_Yell)
- Original Message -
From: Minh [EMAIL PROTECTED]
To: hlcoders@list.valvesoftware.com
Sent: Thursday, March 08, 2007 7:54 PM
Subject: Re: [hlcoders] Muzzle flash showing in every view space.
--
[ Picked text/plain from multipart/alternative ]
DoMuzzleFlash() doesn't actually create the sprite on the screen. As far as
I can tell, it sets a parity bit on an entity.
Why dont you take a screenshot to show us what your problem is. If you're
having problems capturing muzzleflashes (since they happen so fast). Just
use the command
host_timescale 0.1
That will slow down the game to 10% of the normal speed.
Original Message -
From: REBEL [EMAIL PROTECTED]
To: hlcoders@list.valvesoftware.com
Sent: Thursday, March 08, 2007 7:56 AM
Subject: Re: [hlcoders] Muzzle flash showing in every view space.
Thank you very much for the replies, I'm trying to dig into this issue but
wasn't able to discover anything ATM. Our weapons cloned from 357 code are
pretty much
Re: [hlcoders] Muzzle flash showing in every view space.
Thank you very much for the replies, I'm trying to dig into this issue but wasn't able to discover anything ATM. Our weapons cloned from 357 code are pretty much the same than default, only modified some values related to accuracy, etc. I'm using the latest SDK from November, all code the muzzleflash code wasn't touched. There were a few additions to c_te_legacytempents, so I tried with default file and no improvements. there are TWO events that are responsible for creating the muzzleflash. One of the events is embedded in the view model's primary attack sequence. The 2nd event is embedded inside the world model (w_357.cpp) I noticed there is no pPlayer-DoMuzzleFlash(); in my weapon_357.cpp, there wasn't any by default. It exist on other weapons, but not in the 357. I tried to comment the other event in basecombatweapon_shared and nothing happened, muzzleflash works the same so this confusses me a lot. Is pPlayer-DoMuzzleFlash() supposing to do something in multiplayer? At this point I have the doubt if we really did something wrong with the weapon models. Could a wrong muzzle attachment cause this? Ángel Oliver (R_Yell) - Original Message - From: Minh [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Wednesday, March 07, 2007 7:50 PM Subject: Re: [hlcoders] Muzzle flash showing in every view space. -- [ Picked text/plain from multipart/alternative ] This might have something to do with the fact that there are TWO events that are responsible for creating the muzzleflash. One of the events is embedded in the view model's primary attack sequence. The 2nd event is embedded inside the world model (w_357.cpp) Check to make sure you are not calling both.. I have a similar problem when I switch to third person mode and I fire my gun. Both events get called and I can see two muzzle flashes. - Original Message - From: Ryan Sheffer [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Wednesday, March 07, 2007 9:43 AM Subject: Re: [hlcoders] Muzzle flash showing in every view space. -- [ Picked text/plain from multipart/alternative ] We had this problem and fixed it, it was long ago though and I cant remember. My friend might remember so ill get back to you if I find the answer. On 3/6/07, John Sheu [EMAIL PROTECTED] wrote: On Tuesday 06 March 2007 11:32 am, REBEL wrote: I got a problem with muzzle flash, basically when a player shoots the muzzle can be seen in world, its view space and... the rest of view spaces of other players if they are using the same gun (or one coded from the original 357). This only happens when weapon is a 357 revolver clone. We got 3 weapons cloned from 357 and all of them are bugged. There are also a few shotgun cloned weapons which don't suffer that problem. First thought is, some class member got marked static somewhere along the line? -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- ~skidz -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Muzzle flash showing in every view space.
Okay, this is even better than a screenshot. I made a small video where the issue can be seen quite well. Hope it helps you: http://www.sendspace.com/file/m55otq That ghost muzzle cannot be seen in world view, and it doesn't spawn exactly in weapon's muzzle attachment. If character ducks that muzzle keeps showing in the same coordinates, it doesn't modify its position if player doesn't move. That test was made with a modified c_te_legacytempents file which produces more smoke but the muzzle issue happens the same with default c_te file. That's important because thats the place where muzzle sprites are created AFAIK, so default code makes the same effect. Ángel Oliver (R_Yell) - Original Message - From: Minh [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Thursday, March 08, 2007 7:54 PM Subject: Re: [hlcoders] Muzzle flash showing in every view space. -- [ Picked text/plain from multipart/alternative ] DoMuzzleFlash() doesn't actually create the sprite on the screen. As far as I can tell, it sets a parity bit on an entity. Why dont you take a screenshot to show us what your problem is. If you're having problems capturing muzzleflashes (since they happen so fast). Just use the command host_timescale 0.1 That will slow down the game to 10% of the normal speed. Original Message - From: REBEL [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Thursday, March 08, 2007 7:56 AM Subject: Re: [hlcoders] Muzzle flash showing in every view space. Thank you very much for the replies, I'm trying to dig into this issue but wasn't able to discover anything ATM. Our weapons cloned from 357 code are pretty much the same than default, only modified some values related to accuracy, etc. I'm using the latest SDK from November, all code the muzzleflash code wasn't touched. There were a few additions to c_te_legacytempents, so I tried with default file and no improvements. there are TWO events that are responsible for creating the muzzleflash. One of the events is embedded in the view model's primary attack sequence. The 2nd event is embedded inside the world model (w_357.cpp) I noticed there is no pPlayer-DoMuzzleFlash(); in my weapon_357.cpp, there wasn't any by default. It exist on other weapons, but not in the 357. I tried to comment the other event in basecombatweapon_shared and nothing happened, muzzleflash works the same so this confusses me a lot. Is pPlayer-DoMuzzleFlash() supposing to do something in multiplayer? At this point I have the doubt if we really did something wrong with the weapon models. Could a wrong muzzle attachment cause this? Ángel Oliver (R_Yell) - Original Message - From: Minh [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Wednesday, March 07, 2007 7:50 PM Subject: Re: [hlcoders] Muzzle flash showing in every view space. -- [ Picked text/plain from multipart/alternative ] This might have something to do with the fact that there are TWO events that are responsible for creating the muzzleflash. One of the events is embedded in the view model's primary attack sequence. The 2nd event is embedded inside the world model (w_357.cpp) Check to make sure you are not calling both.. I have a similar problem when I switch to third person mode and I fire my gun. Both events get called and I can see two muzzle flashes. - Original Message - From: Ryan Sheffer [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Wednesday, March 07, 2007 9:43 AM Subject: Re: [hlcoders] Muzzle flash showing in every view space. -- [ Picked text/plain from multipart/alternative ] We had this problem and fixed it, it was long ago though and I cant remember. My friend might remember so ill get back to you if I find the answer. On 3/6/07, John Sheu [EMAIL PROTECTED] wrote: On Tuesday 06 March 2007 11:32 am, REBEL wrote: I got a problem with muzzle flash, basically when a player shoots the muzzle can be seen in world, its view space and... the rest of view spaces of other players if they are using the same gun (or one coded from the original 357). This only happens when weapon is a 357 revolver clone. We got 3 weapons cloned from 357 and all of them are bugged. There are also a few shotgun cloned weapons which don't suffer that problem. First thought is, some class member got marked static somewhere along the line? -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- ~skidz -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http
[hlcoders] Muzzle flash showing in every view space.
This is a multi-part message in MIME format. -- [ Picked text/plain from multipart/alternative ] Hi, I got a problem with muzzle flash, basically when a player shoots the muzzle can be seen in world, its view space and... the rest of view spaces of other players if they are using the same gun (or one coded from the original 357). This only happens when weapon is a 357 revolver clone. We got 3 weapons cloned from 357 and all of them are bugged. There are also a few shotgun cloned weapons which don't suffer that problem. Our muzzle flash code was modified to include a smoke effect from BG2 mod. I was thinking in a possible bug there, but 357 guns are also failing when they use shotgun muzzle code, so this must be a issue related to my 357 code. I'm also discarting a model issue, we checked them and all seemed okay. Any help will be really appreciated, thanks and regards. -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
