DDraceNetwork - general

Ryozuki

but ye the literal 4 is an rvalue

specifically a prvalue

1

@bloha dm me if ur online =)

08:52

?

08:53

observation of

08:53

?

Which exact language is this?

rus

OFC | dqepb

Click to see attachment 🖼️

@gerdoe Want to take a look?

ah

08:59

the hell

08:59

its used in two places xd

09:00

never accept translates without another player approve

09:02

kinda used to have one translation in only one place

Does it make sense to use two different translations in the two places?

09:03

Then we should split them I guess

yeah since in menu bar its "spectate"

09:04

but наблюдать in russian is just "to spectate"

09:04

its okey o have it in menu bar but in game its like "To Spectate: Player"

09:05

hurts the eye a bit

09:08

"наблюдать" in menu bar and in game its more "наблюдение за: somebody" than "наблюдать: somebody"

im looking for team to finish Springlobe 3

@Colo-Colo

Colo-Colo:

@COCOMELON @Moderator cool pfp this dude got (edited)

@deen interesting how in map jao shooter it will look like GWjiangLoveHeart

@murpi @Robyt3 you can modify the DDnet bot ?

11:12

or you are not in this part?

OFC | dqepb

@murpi @Robyt3 you can modify the DDnet bot ?

add: 1. show online or offline player 2. how long is his current session in the game 3. how many points he has in ddrace/gores

ever heard of /points command?

kinda strange

The new feature seems cool but it makes me feel dizzy

Arch Linux dummy gigachad

texnonik

kinda strange

this looks like the POV's from @Im 'corneum ! https://youtu.be/H7q2QHsEETw (edited)

corneum

Unreachable by Themix Playthrough (unreleased 5 star dummymap)

11:28

~~love the vids~~

texnonik

kinda strange

cuz dummy teleportating to nowhere every shot xd

Steinchen

Arch Linux dummy gigachad

texnonik

kinda strange

@Vy0x2 Any way to fix it?

I wonder How does it look while swapping?

maybe some delay or smoother transition after teleport

Pipou

The new feature seems cool but it makes me feel dizzy

maybe it'll get a bit smoother, but the same happened with smooth zooming ^^

1

I want a feature that makes spec always follow Konsti

deen

@Vy0x2 Any way to fix it?

it will happen with maps where teleports are a bit far , in this it's way too far so it's can't go that far very fast . Would be good if teleport blocks 500 is good transition , for my map no need it's no need at all ...

11:55

probably few maps have teleports far

This new feature from #announcements looks amazing

What the heck is that map from #announcements

13:20

BelinhoBR

What the heck is that map from #announcements

Unbalanced 3

No

13:38

@mbvxoxo

13:38

bro in here

xd

OFC | dqepb

xd

Did you make it?

no

13:48

found

13:48

https://www.stupidedia.org/stupi/DDNet

DDNet

13:49

alt wiki

13:49

deen

@Vy0x2 Any way to fix it?

Over the last months i tested this, i couldnt get a setting where every possible situation could be covered with one setup. I had to increase the "sensitivity" of zooming/camera movement for small teams, and decrease it for big team0 teams. Some scenarios are not meant to be for a smooth camera movement, and i think this map is a good example where it makes no sense to use multiview. There are also maps where you go into a teleport and one player is on the left side of the map, and one player is on the right side.. How should this be dealt with? If the distance is too big, prefer one player? At which distance can i spectate both again? Big team0 teams shouldnt be split up when they are very far away.. The only special case i did is: If people are far away and in freeze for 3,5 seconds, they get ignored until they are unfrozen again. That made sense in big team0 maps but is causing some rare "bugs" where someone is longer than 3 seconds in freeze but gets unfrozen since the design of the map.. I think we have to accept that sometimes it doesnt work (with some maps) and sometimes it works pretty solid. If you want to twerk a bit (for demos maybe?), you could use this two commands: spectate_multiview <id> - to only spectate some people even if they are in the same team cl_multi_view_zoom_smoothness 1300 - (in ms) to twerk how fast the zoom should be. bigger team = slower (higher number), smaller team = faster (lower number) I think it would be too complicated if i make multiple "profiles" for dummy map, two player team, big team0 team etc. @Patiga @texnonik

1

1

OFC | dqepb

Click to see attachment 🖼️

That article is already 8 years old, was written by DoNe

Vy0x2

Over the last months i tested this, i couldnt get a setting where every possible situation could be covered with one setup. I had to increase the "sensitivity" of zooming/camera movement for small teams, and decrease it for big team0 teams. Some scenarios are not meant to be for a smooth camera movement, and i think this map is a good example where it makes no sense to use multiview. There are also maps where you go into a teleport and one player is on the left side of the map, and one player is on the right side.. How should this be dealt with? If the distance is too big, prefer one player? At which distance can i spectate both again? Big team0 teams shouldnt be split up when they are very far away.. The only special case i did is: If people are far away and in freeze for 3,5 seconds, they get ignored until they are unfrozen again. That made sense in big team0 maps but is causing some rare "bugs" where someone is longer than 3 seconds in freeze but gets unfrozen since the design of the map.. I think we have to accept that sometimes it doesnt work (with some maps) and sometimes it works pretty solid. If you want to twerk a bit (for demos maybe?), you could use this two commands: spectate_multiview <id> - to only spectate some people even if they are in the same team cl_multi_view_zoom_smoothness 1300 - (in ms) to twerk how fast the zoom should be. bigger team = slower (higher number), smaller team = faster (lower number) I think it would be too complicated if i make multiple "profiles" for dummy map, two player team, big team0 team etc. @Patiga @texnonik

the way i see it in the video, is that there is no prediction for tele tiles

14:07

or at least no transition

Vy0x2

Over the last months i tested this, i couldnt get a setting where every possible situation could be covered with one setup. I had to increase the "sensitivity" of zooming/camera movement for small teams, and decrease it for big team0 teams. Some scenarios are not meant to be for a smooth camera movement, and i think this map is a good example where it makes no sense to use multiview. There are also maps where you go into a teleport and one player is on the left side of the map, and one player is on the right side.. How should this be dealt with? If the distance is too big, prefer one player? At which distance can i spectate both again? Big team0 teams shouldnt be split up when they are very far away.. The only special case i did is: If people are far away and in freeze for 3,5 seconds, they get ignored until they are unfrozen again. That made sense in big team0 maps but is causing some rare "bugs" where someone is longer than 3 seconds in freeze but gets unfrozen since the design of the map.. I think we have to accept that sometimes it doesnt work (with some maps) and sometimes it works pretty solid. If you want to twerk a bit (for demos maybe?), you could use this two commands: spectate_multiview <id> - to only spectate some people even if they are in the same team cl_multi_view_zoom_smoothness 1300 - (in ms) to twerk how fast the zoom should be. bigger team = slower (higher number), smaller team = faster (lower number) I think it would be too complicated if i make multiple "profiles" for dummy map, two player team, big team0 team etc. @Patiga @texnonik

ye that's the problem there are way to different maps ...

14:09

also there is map when you can be in freeze and use laser to unfreeze . what will happen with camera ?

Iza

the way i see it in the video, is that there is no prediction for tele tiles

Since the distance between the players is a lot, it is moving also very fast, almost instant. There is a transition, its just very small

texnonik

also there is map when you can be in freeze and use laser to unfreeze . what will happen with camera ?

If the players are not too far away from each other, it should work.

Lookin for clan

Vietnamlı Sincap

Lookin for clan

join my clan : jao fan

texnonik

join my clan : jao fan

how was the map called? (edited)

Vy0x2

how was the map called? (edited)

"jao shooter"

1

Vy0x2

Over the last months i tested this, i couldnt get a setting where every possible situation could be covered with one setup. I had to increase the "sensitivity" of zooming/camera movement for small teams, and decrease it for big team0 teams. Some scenarios are not meant to be for a smooth camera movement, and i think this map is a good example where it makes no sense to use multiview. There are also maps where you go into a teleport and one player is on the left side of the map, and one player is on the right side.. How should this be dealt with? If the distance is too big, prefer one player? At which distance can i spectate both again? Big team0 teams shouldnt be split up when they are very far away.. The only special case i did is: If people are far away and in freeze for 3,5 seconds, they get ignored until they are unfrozen again. That made sense in big team0 maps but is causing some rare "bugs" where someone is longer than 3 seconds in freeze but gets unfrozen since the design of the map.. I think we have to accept that sometimes it doesnt work (with some maps) and sometimes it works pretty solid. If you want to twerk a bit (for demos maybe?), you could use this two commands: spectate_multiview <id> - to only spectate some people even if they are in the same team cl_multi_view_zoom_smoothness 1300 - (in ms) to twerk how fast the zoom should be. bigger team = slower (higher number), smaller team = faster (lower number) I think it would be too complicated if i make multiple "profiles" for dummy map, two player team, big team0 team etc. @Patiga @texnonik

i think a way to fix this would be to set a main tee for the multview, and have a grace period for the zoom out, and also a limit, simply dont zoom out if its too much

14:41

well i say this not fully knowing the extend of the feature rn xd

Vy0x2

Over the last months i tested this, i couldnt get a setting where every possible situation could be covered with one setup. I had to increase the "sensitivity" of zooming/camera movement for small teams, and decrease it for big team0 teams. Some scenarios are not meant to be for a smooth camera movement, and i think this map is a good example where it makes no sense to use multiview. There are also maps where you go into a teleport and one player is on the left side of the map, and one player is on the right side.. How should this be dealt with? If the distance is too big, prefer one player? At which distance can i spectate both again? Big team0 teams shouldnt be split up when they are very far away.. The only special case i did is: If people are far away and in freeze for 3,5 seconds, they get ignored until they are unfrozen again. That made sense in big team0 maps but is causing some rare "bugs" where someone is longer than 3 seconds in freeze but gets unfrozen since the design of the map.. I think we have to accept that sometimes it doesnt work (with some maps) and sometimes it works pretty solid. If you want to twerk a bit (for demos maybe?), you could use this two commands: spectate_multiview <id> - to only spectate some people even if they are in the same team cl_multi_view_zoom_smoothness 1300 - (in ms) to twerk how fast the zoom should be. bigger team = slower (higher number), smaller team = faster (lower number) I think it would be too complicated if i make multiple "profiles" for dummy map, two player team, big team0 team etc. @Patiga @texnonik

yea I recognize this is a problem with no perfect solution, the multi-view looks really good as-is! in case it is not intended, in the two commands you gave you write multi-view differently, which is a tiny bit confusing. I do see how teleporting players ruin this view a lot and it can't be fixed nicely. Zooming out a lot makes the spectating useless but without zooming we don't see all tees. To add my own opinionated view: either stay on the remaining tees until every tee is gone and not zooming out to far or switching side once the majority is gone. thanks for implementing this awesome feature :D

Ryozuki

i think a way to fix this would be to set a main tee for the multview, and have a grace period for the zoom out, and also a limit, simply dont zoom out if its too much

I could think of a delay if the distance changes way too much in one frame yes, good idea thanks!

Patiga

yea I recognize this is a problem with no perfect solution, the multi-view looks really good as-is! in case it is not intended, in the two commands you gave you write multi-view differently, which is a tiny bit confusing. I do see how teleporting players ruin this view a lot and it can't be fixed nicely. Zooming out a lot makes the spectating useless but without zooming we don't see all tees. To add my own opinionated view: either stay on the remaining tees until every tee is gone and not zooming out to far or switching side once the majority is gone. thanks for implementing this awesome feature :D

Hmm i was also worried about this. I have spectate_multiview because of this