[pheadxdll]

We already have announcer lines warning about incoming sentry busters. Adding additional lines is redundant and would probably clip with the announcer lines.

[Powerlord]

Originally Posted by pheadxdll We already have announcer lines warning about incoming sentry busters. Adding additional lines is redundant and would probably clip with the announcer lines.

Sounds would only clip if they're on the same channel. The announcer uses channel 7 (aka SNDCHAN_VOICE2) exclusively.

Incidentally, for what Benoist3012 posted, you can also just do a GetRandomInt(1, 100) and Format that into the randomnum string if you really want it to work like MvM.

As for sounds, I noticed you're using the client playgamesound... I was wondering if there was a particular reason you're doing that.

Since SM 1.6, SDKTools can now both precache and play sounds directly from game sound files now. Including emitting sounds directly from entities.

In fact, PrecacheScriptSound exists explicitly to precache MvM sounds because the game doesn't precache them on its own for non-MvM modes.

[pheadxdll]

No no powerlord. The announcer lines we have currently would indeed play at the same time as the sentry buster concepts would play. This is the sort of behavior we do not want.

To answer why I am using playgamesound, I tried using those new natives to play gamesounds on another project and they were not reliable. playgamesound always works and suits my needs.

[Potato Uno]

Wait a minute, this requires SM 1.8... the developer's branch sourcemod?? Why?

Also you should mention that on the OP too since the stable branch is the one (1.7) that is most encouraged here.

EDIT: For custom maps, it sounds like here we're at the mercy of mappers to edit their map to support STT if it doesn't work right out of the box. Is it possible by some chance to use Stripper: Source to insert in entities (after inspecting a decompiled bsp) to make the tank work, or not?

Stripper is way more preferred than recompiling a decompiled map.

[pheadxdll]

At one point it did. I could probably downgrade it but I didn't see any reason. Are you having problems with 1.8?

Most of those map entities are for map makers to extend STT and are not needed for basic functionality. The parenting stuff (to prevent the tank from becoming stuck) can be set in stt.cfg. I'm not sure why you brought up stripper. The map entities are there for map makers to do extra things with STT, such as open gates when intermission begins.

[Potato Uno]

Okay, looks like I need to reread the wiki another 2 more times since I must have fully misunderstood it. Thanks for the clarification!

And no I don't have a problem with it, and since you already are at 1.8 and it will be the next stable, stick to it. Just mention in the OP 1.8 is needed since most people are running 1.7.

[Oshizu]

Been getting quite lots of crashes from this gamemode, any advices pheadxdll?
Crash logs from accelerator:

1 hour ago     linux-gate.so + 0x420
4 hours ago     materialsystem_srv.so!CMaterialVar::GetStringValue() const + 0x1a8
23 hours ago     server_srv.so!CTFNavArea::ComputeInvasionAreaVectors() + 0x1aa
yesterday     linux-gate.so + 0x420
 yesterday     vphysics_srv.so!IVP_Hull_Manager::delete_hull_manager() + 0x25
yesterday     materialsystem_srv.so!_fini + 0x591c

[Powerlord]

Originally Posted by pheadxdll At one point it did. I could probably downgrade it but I didn't see any reason. Are you having problems with 1.8?

Given that there was (at least) a 19 day period (starting here at git5531) in the last 4 weeks where the latest 1.8 snapshot would randomly crash on Linux servers (and ALWAYS crash during server shutdown) due to asserts left in the code, yes. And that was with just stock plugins loaded.

I haven't tested to see if the new sourcepawn git module from 5 days ago fixed it.

[pheadxdll]

I'll downgrade next version to 1.7 but that likely won't fix any of your crashes Oshizu. The nav patch was meant to fix CTFNavArea::ComputeInvasionAreaVectors() and other nav related crashes that stem from CTFPlayer::OnNavAreaChanged. The nav patch is disabled on plr_hightower_event so skeletons will function so theoretically the patch could still be effective, just turning it on and off makes it less effective.. I suspect these nav related crashes are caused by the tank.

The other common crashes that I am aware of are:

• CTFGameRules::ShutdownCustomResponseRulesDict s() when the round starts
• IVP_Hull_Manager::delete_hull_manager() on level shutdown and other misc vphysics related crashes. (IVP_Polygon::IVP_Polygon)
• Running out of edicts on thundermountain
• "Fatal Error: classname missing from entity!" on thundermountain
• CEconItemView::NetworkVar_m_NetworkedDynamicA ttributesForDemos

These types of crashes that are not caused directly from the plugin are very hard to diagnose. I can't make any promises. On my server I had one crash in the last 24 hours. About 2-3 is normal unfortunately.

[Benoist3012]

Originally Posted by pheadxdll I suspect these nav related crashes are caused by the tank.

Really I never get one problem with tank and nav with MvT.
Have you changed something on the nav?