reserved for public demo link & major changelogs

YOU CAN DO IT BLUEE :D

It's really cute watching the name tags run round the map :3

Even though they do take up some space, I think being able to see who exactly is where would be better than just class icons.

This is fucking awesome man, sadly I can't really help with it. Keep up the great work bluee.

Are you gonna have first person spec mode too with webgl?

literally carrying esports on your back

Maybe you've seen this already but there's a somewhat related project here:

https://github.com/eilgin/tf2-map-overview

This plugin records a JSON file of positions / camera angles which can then be played back in a webpage afterwards. Demo here: http://www.thomas-jouannic.fr/mapoverview/

In any case perhaps there might be something useful in there, or maybe the author would be interested in helping you out.

I would love to help but only if you don't mind teaching someone who knows literally nothing about the source SDK or networking. I know enough C++ to code, but not enough to develop real projects, if that makes any sense.

afaik that project died. It was cool when jimbomcb posted his proof of concept, but I think the effort in basically recreating Source in webgl outweighs the benefits of being able to do first person spec in a browser.

This is amazing. Thank you so much for your efforts. I wish I knew more C++ so I could help.

the saviour

If the dots could somehow indicate class, that would probably helpful Not sure what the best way to do that without cluttering it up, though. The names are nice but when people are next to each other its counter productive.

Would be kinda neat if you could click on the minimap and it'd take you there in spec mode, I don't know how feasible this is but would be neat if you saw a bunch of players going towards a choke or something.

Literally saving competitive TF2.

it's not dying, he's just helping it grow bigger

change the dots to the class icons

Wow, you're fucking amazing dude

That was the most obvioous but then I thought they might have to be too big for it to be effective. Medic and demo seem like they would work well enough but scout and particularly soldier might be less pretty. Not really sure though.

Also, if class icons were used names would probably be unnecessary if a distinction was made between roamer and pocket (just an R and a P would suffice, but this would be team specific so not at all straightforward). This would probably also make the size of the icon a non issue (as it would be a lot less cluttered).

Color the dots like Dota 2 does
then you can cut down on battlefield clutter and just use a color coded key on the side to say who/what class/etc

Why not class icons AND names?

Maybe just colored class icons if the names make it too cluttered?

Also, you should integrate this (http://teamfortress.tv/forum/thread/1210-huge-status-monitor) into the project. Sigma did a great job on it, and it's just awesome for speccing live matches.

#20, too much clutter on screen at once imo. I could make them toggle on with a key, but by default I prefer the class icon method.

#21, thanks for linking that, had a few people talking about it and never got around to looking for it.

i think something interesting would be to make little custom icons for different types of class, because it would be trivial to cut down on how noisy/detailed the icons are that way
you could have one for each of offense/defense/support, or if that's not good, you could have one for the base HP levels of each class, or, or, or...

To add to this, I don't think it's necessary to really put names above each icon. I feel just class icons is enough, to reduce clutter.

Like, for example, I think this would be must useful for holds, which splits the team in two, combo and flank. Combo classes are all different, so you class icons are enough in telling who is who (so long as you know who the pocket is).

I wouldn't mind helping out on the server side, although I'm busy for the next week or so trying to push an Android app out the door at my current job...

Looking through the code, I'd bet that your crash probably comes from your very conservative use of memory when it comes to strings. Things like make me nervous:

char *buffer = (char*)malloc(1 + 4*2 + strlen(weapon.ToCStr()));
int length = sprintf(buffer, "%c%d:%d:%s", WSPacket_PlayerDeath, victim, attacker, STRING(weapon));

Don't forget, this plugin is running on a server that's using hundreds of megabytes of memory. Don't hesitate to allocate 1k here in order to prevent a buffer overflow. Better yet, find out if Valve has their own blessed string class that you should be using to prevent this sort of thing, or see if you can use the string class in the standard library (http://www.cplusplus.com/reference/string/string/) and call c_str() whenever needed.

changing tf2 spectatoring right here

By the logs I got out of it it seems to be me not closing some connections properly, trying to send data to clients who have left.
The strings are using 'string_t' in the Source SDK, which as far as I can tell is Valve's way of doing strings.

You are right about memory though, I am cutting it close with some functions and will probably change it to be safer. I figured using exactly as much memory as needed was best way to go around it, but when the server is using MBs of memory as you say, I probably shouldn't be overly worried about a few wasted bytes here and there, when they all get freed quickly after anyway.

Thanks for having a look through it!

All good. Looking at https://developer.valvesoftware.com/wiki/String it seems that string_t is just a typedef for char *, so you need to be careful.

Another thought is that you should replace sprintf with snprintf, which takes a size parameter and will avoid buffer overflows. (I'm tellin ya man, ya gotta look out for them.) You could rewrite the code above to:

#define BUFFER_SIZE 1024

char *buffer = (char*)malloc(BUFFER_SIZE);
int length = snprintf(buffer, BUFFER_SIZE, "%c%d:%d:%s", WSPacket_PlayerDeath, victim, attacker, STRING(weapon));

That way if whatever the string format gets expanded to is greater than BUFFER_SIZE, then the end of the text is truncated. The client getting incomplete data is better than the server crashing.

Also, log the hell out of everything. When you get crashes and need to figure out what happened, they're your only resource. You want to be able to trace what happened up to the crash.

Okay, that's all from me... Good job so far, and good luck!

Wasn't aware of sprintf vs snprintf. Thanks for the tips, very appreciated

Amazing work, man! I'm wondering why you're converting the SourceMod plugin to a VSP?

Edit: More specifically, if the reason is performance, why you're not moving to a SM extension.