this is huge
Holy shit this is awesome! I haven't been able to get these individual plugins to work before, so I can't wait to try these out. Good work.
Had the opportunity to test this shit out and am psyched that it's finally public.
Casting in TF2 is getting BETTER all the time, more than 5 years later, and it's amazing.
Casting in TF2 is getting BETTER all the time, more than 5 years later, and it's amazing.
I'm going to be using this in all of my team's productions.
Feedback so far:
The health bar shouldn't appear for the player you're currently viewing if viewing that player from a first person cam. It flies all over the top of the screen depending on where they're looking. Not good.
The minimap shouldn't have "horizontal pos" and "vertical pos", it should use anchors and offsets. For example, four vars: "anchor_top 1", "anchor_bottom 0", "anchor_right 1", "anchor_left 0" would anchor it to the top right, and then "offset_x 50" would offset it 50 pixels from the right of the screen (to the left of the right side), and "offset_y 10" would offset it from the top that amount. Currently, in order to put the minimap in the bottom right, you need to know the exact resolution of your display in order to make it look decent at all. This means I can't share my exec with my co-caster running a different resolution unless I customize it specifically for him, and I can't because his resolution is above mine.
Other than that, fantastic work. Maybe some more customization options would be nice (change health bar's outline color?) but it's a fine piece of work.
Feedback so far:
The health bar shouldn't appear for the player you're currently viewing if viewing that player from a first person cam. It flies all over the top of the screen depending on where they're looking. Not good.
The minimap shouldn't have "horizontal pos" and "vertical pos", it should use anchors and offsets. For example, four vars: "anchor_top 1", "anchor_bottom 0", "anchor_right 1", "anchor_left 0" would anchor it to the top right, and then "offset_x 50" would offset it 50 pixels from the right of the screen (to the left of the right side), and "offset_y 10" would offset it from the top that amount. Currently, in order to put the minimap in the bottom right, you need to know the exact resolution of your display in order to make it look decent at all. This means I can't share my exec with my co-caster running a different resolution unless I customize it specifically for him, and I can't because his resolution is above mine.
Other than that, fantastic work. Maybe some more customization options would be nice (change health bar's outline color?) but it's a fine piece of work.
text is a bit big, and the black box even more so. probably wouldn't even need that black box if you just give the text an outline. would be pretty cool if when the spectator looks in a direction, if the center of his screen is X degrees close to a person, that persons name fades in no matter what distance they're at. might be weird if they're across the map and you're just flying around, I guess.
It'd be cool if you could somehow display the ammo of the players since that's the only other thing a pov demo could offer over a stv. Not really a big deal though, thanks for the plugins.
yttriumThe minimap shouldn't have "horizontal pos" and "vertical pos", it should use anchors and offsets. For example, four vars: "anchor_top 1", "anchor_bottom 0", "anchor_right 1", "anchor_left 0" would anchor it to the top right, and then "offset_x 50" would offset it 50 pixels from the right of the screen (to the left of the right side), and "offset_y 10" would offset it from the top that amount. Currently, in order to put the minimap in the bottom right, you need to know the exact resolution of your display in order to make it look decent at all. This means I can't share my exec with my co-caster running a different resolution unless I customize it specifically for him, and I can't because his resolution is above mine.
I found a bug with smaller resolutions when looking at this so I'll upload a fixed version soon.
The size of the map is scaled, so if your resolution is 1280*720 and your co-caster is running 1920*1080, then the proportion of width and height is 1.5, so if you have the map horizontal position at 800 then multiplying it by the proportion of width and height should give you 1200 and it should appear in the same place on your co-caster's screen. Using a different aspect ratio obviously means this is harder, it's not a use case I looked at during design.
yttriumThe health bar shouldn't appear for the player you're currently viewing if viewing that player from a first person cam. It flies all over the top of the screen depending on where they're looking. Not good.
I'm aware of this and from memory it can be solved in first person, but then causes unstable display in third person. However my understanding has moved on from then so there might be a solution now. I'll look into it.
I found a bug with smaller resolutions when looking at this so I'll upload a fixed version soon.
The size of the map is scaled, so if your resolution is 1280*720 and your co-caster is running 1920*1080, then the proportion of width and height is 1.5, so if you have the map horizontal position at 800 then multiplying it by the proportion of width and height should give you 1200 and it should appear in the same place on your co-caster's screen. Using a different aspect ratio obviously means this is harder, it's not a use case I looked at during design.
[quote=yttrium]The health bar shouldn't appear for the player you're currently viewing if viewing that player from a first person cam. It flies all over the top of the screen depending on where they're looking. Not good.[/quote]
I'm aware of this and from memory it can be solved in first person, but then causes unstable display in third person. However my understanding has moved on from then so there might be a solution now. I'll look into it.
GentlemanJonI found a bug with smaller resolutions when looking at this so I'll upload a fixed version soon.
The size of the map is scaled, so if your resolution is 1280*720 and your co-caster is running 1920*1080, then the proportion of width and height is 1.5, so if you have the map horizontal position at 800 then multiplying it by the proportion of width and height should give you 1200 and it should appear in the same place on your co-caster's screen. Using a different aspect ratio obviously means this is harder, it's not a use case I looked at during design.
The issue isn't for offset from the top left, specifically. The issue lies in if you want it to be affixed to the bottom right. Let's say, I have a 1600x900 monitor (which I do) and I want the minimap size to be 2 (doubled) and affixed to the bottom right. I have the horizontal_pos set to 1300 and vertical_pos set to 542. For 1600x900, this looks fantastic. However, as soon as you want to give this to another user (1280x720 or 1920x1080), you need to recalculate everything, remembering the size and offsets from max. It's a pain and while you could do it manually with trial and error for smaller resolutions, it's near impossible for larger ones.
Raw pixel offsets with anchors is honestly the best solution. Every decent GUI framework out there, even WinForms, uses this method.
GentlemanJonI'm aware of this and from memory it can be solved in first person, but then causes unstable display in third person. However my understanding has moved on from then so there might be a solution now. I'll look into it.
I think it would be totally acceptable to just disable it in third person as well if you can't find a proper workaround.
I found a bug with smaller resolutions when looking at this so I'll upload a fixed version soon.
The size of the map is scaled, so if your resolution is 1280*720 and your co-caster is running 1920*1080, then the proportion of width and height is 1.5, so if you have the map horizontal position at 800 then multiplying it by the proportion of width and height should give you 1200 and it should appear in the same place on your co-caster's screen. Using a different aspect ratio obviously means this is harder, it's not a use case I looked at during design.[/quote]
The issue isn't for offset from the top left, specifically. The issue lies in if you want it to be affixed to the bottom right. Let's say, I have a 1600x900 monitor (which I do) and I want the minimap size to be 2 (doubled) and affixed to the bottom right. I have the horizontal_pos set to 1300 and vertical_pos set to 542. For 1600x900, this looks fantastic. However, as soon as you want to give this to another user (1280x720 or 1920x1080), you need to recalculate everything, remembering the size and offsets from max. It's a pain and while you could do it manually with trial and error for smaller resolutions, it's near impossible for larger ones.
Raw pixel offsets with anchors is honestly the best solution. Every decent GUI framework out there, even WinForms, uses this method.
[quote=GentlemanJon]
I'm aware of this and from memory it can be solved in first person, but then causes unstable display in third person. However my understanding has moved on from then so there might be a solution now. I'll look into it.[/quote]
I think it would be totally acceptable to just disable it in third person as well if you can't find a proper workaround.
yttriumRaw pixel offsets with anchors is honestly the best solution. Every decent GUI framework out there, even WinForms, uses this method.
welcome to the valve gui framework, designed in 2004
valid point though, something to look into
welcome to the valve gui framework, designed in 2004
valid point though, something to look into
yttriumThe issue isn't for offset from the top left, specifically. The issue lies in if you want it to be affixed to the bottom right. Let's say, I have a 1600x900 monitor (which I do) and I want the minimap size to be 2 (doubled) and affixed to the bottom right. I have the horizontal_pos set to 1300 and vertical_pos set to 542. For 1600x900, this looks fantastic. However, as soon as you want to give this to another user (1280x720 or 1920x1080), you need to recalculate everything, remembering the size and offsets from max. It's a pain and while you could do it manually with trial and error for smaller resolutions, it's near impossible for larger ones.
Raw pixel offsets with anchors is honestly the best solution. Every decent GUI framework out there, even WinForms, uses this method.
I'm not suggesting it's the best way, but the scaling should work and the chances of me coding an anchoring system are very small.
For the 1920x1080 resolution, 1.2 times larger than yours, I'd suggest a left position of 1560 and top of 650. Keep the map scale as 2. For 1280x720, 0.8 times the size of yours, I'd suggest 1040 and 433.
I'd be interested to know if it produces satisfactory results, although you're actually getting a distorted map at the moment because you're on a non-1080p resolution (so the suggested left position above for 1080p won't work because they won't have a pinched map) so you'll want to move it to the left a little when it's fixed as well.
Raw pixel offsets with anchors is honestly the best solution. Every decent GUI framework out there, even WinForms, uses this method.[/quote]
I'm not suggesting it's the best way, but the scaling should work and the chances of me coding an anchoring system are very small.
For the 1920x1080 resolution, 1.2 times larger than yours, I'd suggest a left position of 1560 and top of 650. Keep the map scale as 2. For 1280x720, 0.8 times the size of yours, I'd suggest 1040 and 433.
I'd be interested to know if it produces satisfactory results, although you're actually getting a distorted map at the moment because you're on a non-1080p resolution (so the suggested left position above for 1080p won't work because they won't have a pinched map) so you'll want to move it to the left a little when it's fixed as well.
GentlemanJonI'm not suggesting it's the best way, but the scaling should work and the chances of me coding an anchoring system are very small.
For the 1920x1080 resolution, 1.2 times larger than yours, I'd suggest a left position of 1560 and top of 650. Keep the map scale as 2. For 1280x720, 0.8 times the size of yours, I'd suggest 1040 and 433.
I'd be interested to know if it produces satisfactory results.
Developing an anchoring system wouldn't be hard. I've got a class coming up in a few minutes but when I get back I could even draw up some pseudocode that only contains if statements and definitions for values. I'd happily do the hard work for you if it meant this could be a thing.
Alternatively you could always just have offset from left, right, top, and bottom, and if top is defined, undefine bottom and use top, if the user then defines bottom, undefine top and use bottom, mirrored for left/right. Not sure if that'd be possible with event handlers but I'd assume it would be.
I'm not suggesting it's the best way, but the scaling should work and the chances of me coding an anchoring system are very small.
For the 1920x1080 resolution, 1.2 times larger than yours, I'd suggest a left position of 1560 and top of 650. Keep the map scale as 2. For 1280x720, 0.8 times the size of yours, I'd suggest 1040 and 433.
I'd be interested to know if it produces satisfactory results.[/quote]
Developing an anchoring system wouldn't be hard. I've got a class coming up in a few minutes but when I get back I could even draw up some pseudocode that only contains if statements and definitions for values. I'd happily do the hard work for you if it meant this could be a thing.
Alternatively you could always just have offset from left, right, top, and bottom, and if top is defined, undefine bottom and use top, if the user then defines bottom, undefine top and use bottom, mirrored for left/right. Not sure if that'd be possible with event handlers but I'd assume it would be.
yttriumDeveloping an anchoring system wouldn't be hard.
It's not the difficulty that's stopping me, it's the boredom of implementing it. I'm just not likely to prioritise it over other commitments. Your best bet's to have a crack at it when I release source.
It's not the difficulty that's stopping me, it's the boredom of implementing it. I'm just not likely to prioritise it over other commitments. Your best bet's to have a crack at it when I release source.
GentlemanJon It's not the difficulty that's stopping me, it's the boredom of implementing it. I'm just not likely to prioritise it over other commitments. Your best bet's to have a crack at it when I release source.
oh god source for this masterpiece is going to be a thing get hype
I suggest putting it on something like Github so you can take pull requests that become official.
[size=10]oh god source for this masterpiece is going to be a thing get hype[/size]
I suggest putting it on something like Github so you can take pull requests that become official.
really awesome, I haven't taken a first hand look yet, but from what I can tell, as a caster I will be interested in using the player names, HP number, and player switching controls
That sort of information always takes a second glance to get and when you are trying to mash coherent words together on the fly, sometimes the process of pulling it up makes things all wibbly wobbly and jumbly wumbly — at least for me.
I typically cast in 3rd person (barring some mid rollouts and fights) not only will this info greatly enhance the level of detail that can be given in 3rd person, (i.e. being able to name player movements without speccing them) but I imagine it will make 1st person casting easier (being able to identify team trends by the player hps and player names available within a players view)
I'm excited to test this out!
That sort of information always takes a second glance to get and when you are trying to mash coherent words together on the fly, sometimes the process of pulling it up makes things all wibbly wobbly and jumbly wumbly — at least for me.
I typically cast in 3rd person (barring some mid rollouts and fights) not only will this info greatly enhance the level of detail that can be given in 3rd person, (i.e. being able to name player movements without speccing them) but I imagine it will make 1st person casting easier (being able to identify team trends by the player hps and player names available within a players view)
I'm excited to test this out!
One idea: Since the HP bars can get cluttered up, the only 1 I find useful is the one for the med. This really helps visualize (especially in first person) the progress of a players pick attempt on the med. Additionally, with only 2 bars floating around throughout the map, it would always help visualize the safety or danger of either teams medic.
So my question is, is it possible to display the bar only above the medics?
So my question is, is it possible to display the bar only above the medics?
the only complaint i have is the overheal bar extending from the original health bar. i think it should be shown on the health bar itself as a white bar extending at the max of the buff to the center of the health bar (since full buffs are 1/2 your health). i think this will clean it up and make the health bars take up less clutter. other wise incredible job!
Have you considered implementing a persistent sidebar with health status for all players, similar to what the tournament spectator HUD does? This would avoid the bug where everything is frozen after a pause.
Also, are you taking map requests? ESEA is playing on cp_sunshine_rc1a this week, so I took an image for that map.
cp_sunshine_rc1a
scale: 10.00
pos_x: -10583
pos_y: 9169
[url=http://puu.sh/8ixOc.png]cp_sunshine_rc1a[/url]
scale: 10.00
pos_x: -10583
pos_y: 9169
pretty awesome stuff
that's a lot of information and i think you should try to streamline some of the data
i have a 2 suggestions:
1) make one long vertical bar, on each side, that indicates the team's total health, have it operate just like the individual health bars with the whole overheal indicator extension.
2) create a horizontal bar that indicates ubercharge status in a similar fashion to how csgo does it with economy.
example:
http://i.imgur.com/kNryRlw.jpg
i don't know much about whatever you're doing but it certainly looks doable
that's a lot of information and i think you should try to streamline some of the data
i have a 2 suggestions:
1) make one long vertical bar, on each side, that indicates the team's total health, have it operate just like the individual health bars with the whole overheal indicator extension.
2) create a horizontal bar that indicates ubercharge status in a similar fashion to how csgo does it with economy.
example:
[img]http://i.imgur.com/kNryRlw.jpg[/img]
i don't know much about whatever you're doing but it certainly looks doable
That would be great Hooli but maybe on a much smaller scale. The new tools already take up a lot of space. Perhaps the team health bars could be horizontal along the top?
I've uploaded a version with a bug fix for map proportions on non 1080p resolutions and some other bugs, it's the same download as it was previously.
I've also added some basic commands implementing some of the more basic requests around the text backgrounds and the health bar widths. I'll document these on the 2nd post in this thread.
Regarding new maps, it's a tedious process adding one because although you'd think once you've got all the coordinates lined up it should just snap into place, unfortunately it doesn't and it needs a lot of tweaking and nudging. If anyone has an STV file of a match on Sunshine they can point me to that would be helpful.
I've also added some basic commands implementing some of the more basic requests around the text backgrounds and the health bar widths. I'll document these on the 2nd post in this thread.
Regarding new maps, it's a tedious process adding one because although you'd think once you've got all the coordinates lined up it should just snap into place, unfortunately it doesn't and it needs a lot of tweaking and nudging. If anyone has an STV file of a match on Sunshine they can point me to that would be helpful.
Whipped up a quick cfg where the you use the numpad to switch between speccing the different classes. It goes in 'class-abetical' order (same order on the class select screen) and you use enter to switch between teams you want to select from.
BLU: http://pastebin.com/ZGYBMheJ
RED: http://pastebin.com/3r5XHts5
Create two separate cfg files, one named spectool_blu and one names spectool_red. Pressing ENTER on the numpad switches between the files(there might be a better way to do this but I'm super new to scripting).
For 6s, press the '/' key to select the second soldier and the '*' key to select the second scout
BLU: http://pastebin.com/ZGYBMheJ
RED: http://pastebin.com/3r5XHts5
Create two separate cfg files, one named spectool_blu and one names spectool_red. Pressing ENTER on the numpad switches between the files(there might be a better way to do this but I'm super new to scripting).
For 6s, press the '/' key to select the second soldier and the '*' key to select the second scout
BLoodSireOne idea: Since the HP bars can get cluttered up, the only 1 I find useful is the one for the med. This really helps visualize (especially in first person) the progress of a players pick attempt on the med. Additionally, with only 2 bars floating around throughout the map, it would always help visualize the safety or danger of either teams medic.
So my question is, is it possible to display the bar only above the medics?
Perhaps a button you hold down to hide all visuals except for the medics? That way specs have a easy way to see the medic specific information at a click of a button.
So my question is, is it possible to display the bar only above the medics?[/quote]
Perhaps a button you hold down to hide all visuals except for the medics? That way specs have a easy way to see the medic specific information at a click of a button.