02:24 < TeeSlayer> Is it intended that the search function in the server browser doesn't use the "Type", but only "Server" and "Map"? 02:26 < TeeSlayer> I know that it's possible to filter by type in "Server filter", but I think most people don't use that feature. They only use the bottom text field. 02:28 < TeeSlayer> The consequence of this is that (empty) servers that don't put everything in sv_name don't get much attention. 10:54 <@Dune> TeeSlayer: well, the gametype filter is there for that :/ 13:28 < TeeSlayer> Dune: why not both? 13:29 <@Dune> because it's strangely redundant? 13:30 < TeeSlayer> well as explained above, I don't think that 13:30 < TeeSlayer> do I see that correctly? would #1539 solve the info change problem I 13:30 < TeeSlayer> 'm having? 13:30 < TeeSlayer> ehm, I mean https://github.com/teeworlds/teeworlds/issues/1201 13:31 < TeeSlayer> about changing the local client's info 13:32 <@Dune> I don't see how that's linked in any wya 13:34 < TeeSlayer> is there any reason why this got changed? that now the client doesn't care about what the server is saying about its own info 13:36 <@Dune> the client info change happened many years ago, I can't answer you 13:37 < TeeSlayer> hm.. mods like infection and catch16 are heavily impacted by this, to the point that it probably wouldn't be worth porting/writing them. zcatch is kinda ok without that I guess. 13:38 <@Dune> yeah, I know 13:48 < Learath2> client doesn't care about what the server is saying? 13:52 < TeeSlayer> Learath2: you can't change how the player perceives its own color/skin 13:52 < TeeSlayer> only how others look like 13:53 < Learath2> Huh, really? I wonder what the cause of that patch was 13:53 <@Dune> Cause you have to destroy characters to change player info, Learath2 13:54 <@Dune> TeeSlayer: there might be workarounds though. e.g. if the mod constraint is that others must be the same color as you, you can just change others to match the client? :) 13:55 < Learath2> Dune: destroy characters as in the entity CCharacter? 13:56 <@Dune> Since players info must now be constant in a game, you have to destroy them and rebuild them (like a leave/join) if you want to change them server-side 13:56 <@Dune> I haven't messed with this much myself so I could be wrong but that's the idea 13:56 < TeeSlayer> Dune: I don't think any mod needs this^^ 13:56 <@Dune> I thought in some mods, colors are represented by teams, TeeSlayer 13:57 <@Dune> teams are represented by colors* 13:57 < TeeSlayer> so then you have two colors? 13:57 <@Dune> the idea is to have more than two teams with a color system iirc 13:57 < TeeSlayer> hm 13:57 <@Dune> you might want to ask our expert @Lordsk 13:58 < TeeSlayer> but that messes up the scoreboard I think 13:58 < TeeSlayer> if multilpe teams are possible 13:58 < TeeSlayer> and you can choose the color for each team 13:58 <@Dune> huh, there is a misunderstanding 13:58 < bridge> [teeworlds] Yeah the client ignores any new client_info with its own client_id 13:58 <@Dune> the idea is you have a deathmatch type mod with colored tees, that's all 13:59 <@Dune> and you can "infect" people to bring them to your team 13:59 <@Dune> now technically you wouldn't be able to port such a mod from 0.6 13:59 < TeeSlayer> fair enough, that works for infection (not sure about infection class though :D) 13:59 <@Dune> but you could work around it by sending to the client allies as the same color as him 13:59 < Learath2> what did keeping player info constant bring to the table? 14:00 <@Dune> no idea - that change was done like 6 years ago 14:00 <@Dune> iirc a PR by some guy I don't know 14:01 < bridge> [teeworlds] we should really enable the old behaviour though 14:01 <@Dune> yes, but we can't 14:02 < bridge> [teeworlds] I mean we could not ignore client_info to self in 0.7.3 14:02 <@Dune> sure, but that wouldn't achieve anything 14:03 <@Dune> you can't tell if the client supports it or not 14:03 < bridge> [teeworlds] It would fix mods trying to modify client info 14:03 < bridge> [teeworlds] that's a non issue 14:04 < bridge> [teeworlds] this is a mod only thing anyway 14:04 <@Dune> you still wouldn't be able to properly make a mod like this because 0.7.2 and below don't support it 14:04 < Learath2> Who stayt on old versions anyways? 14:04 < Learath2> stays* 14:04 < bridge> [teeworlds] It would mean <0.7.2 ignores it 14:05 < bridge> [teeworlds] so it's fine 14:05 < TeeSlayer> everybody's on steam now. best package manager for gamers 14:05 < Learath2> besides mods are free to do whatever they want, including just dropping clients < 0.7.3 with the message, "Update to play mod xyz" 14:05 <@Dune> TeeSlayer: I'm pretty confident that isn't true 14:05 < TeeSlayer> ^^ 14:06 <@Dune> Learath2: I'm not sure if encouraging that is the best course of action 14:06 < Learath2> Encouraging people to update their client is not a good idea? 14:06 <@Dune> Barring access to servers without a client update is debatable 14:07 < Learath2> Or encouraging mods to drop players that they can't possibly support? 14:07 <@Dune> If a server is not compatible, it shouldn't be listed as compatible in the server browser, right 14:07 < bridge> [teeworlds] do clients even send their version? 14:07 <@Dune> remember when you get dropped for wrong hashversion 14:07 <@Dune> they do on connect 14:08 < Learath2> Hmm, good question, we've been sending it for ddrace for a loong time now. Don't remember if vanilla sends it 14:08 < Learath2> Dune: We don't list mods by default on the server list anyways, no? 14:08 < bridge> [teeworlds] ah yes of course 14:08 <@Dune> there is no default really 14:08 <@Dune> Teeworlds, Favorites and All are the default filters now :) 14:09 < TeeSlayer> Learath2: mods should appear in "All" 14:10 <@Dune> by the way with PNG8 I get `[5c519732][game/png]: failed to open file. filename='data/ui/gametypes/race.png'` @LordSk :( 14:10 < Learath2> I mean it sounds fairly reasonable to me, if there was any way to work around the issue I might agree with you but this is a case of a mod just simply not being able to support a given client 14:10 < koomi> Learath2: it's encouraging the *creation* of mods that can't support older (but supposedly compatible because 0.7) clients that would be problematic 14:10 <@Dune> Sure but I mean what's questionable is whether you want to add features in Teeworlds that can only be supported by doing that Learath2 14:11 <@Dune> yeah, that's my point 14:11 < Learath2> It's not encouraging anything, there is literally no benefit to not support older versions, it only limits your audience 14:12 < Learath2> It allows for other interesting mods for people who are updated though 14:12 <@Dune> The only way to use that feature is to make this server hack that drops older 0.7 clients. correct, Learath2? 14:12 <@Dune> (or to make it optional) 14:12 < koomi> yes it does, it makes doing that an accepted practice and will limit the mods available to those stuck on older 0.7 clients 14:13 < Learath2> koomi: stuck? stuck how? besides how does punishing people who do upgrade sound any more "moral" to you? 14:13 < koomi> because that's the packaged version in a stable distro for example 14:14 < koomi> or because newer versions have issues that one wants to avoid 14:14 < Learath2> So because some people can't enjoy a mod without downloading a tarball no one should? 14:15 <@Dune> that's distorting the point :( 14:16 < bridge> [teeworlds] I think the problem is different though, as it only affects mods 14:16 < TeeSlayer> well theoretically it should be possible to add an option for the server whether that new feature is being used 14:16 < koomi> Learath2: false dichotomy, the choice is between going the easy but incompatible route or the hacky ugly but compatible route 14:17 < Learath2> there is no hacky ugly but compatible route 14:17 < TeeSlayer> so vanilla and other 0.7.3 mods won't drop old 0.7 clients 14:17 < bridge> [teeworlds] Turning the option on won't change anything for anyone unless the modder decides otherwise 14:17 < TeeSlayer> the alternative would be to wait for another 5 years until 0.8 arrives :D 14:17 <@Dune> Adding a client-side feature that encourages the server to drop older clients while supposedly being in a compatible (0.7) version is debatable at best imo. If it's not compatible, it shouldn't broadcast itself as such 14:18 < bridge> [teeworlds] The dropping client part is a decision on the modder part though? 14:18 <@Dune> I mean, we had some non-compatible features like 64 clients. Should we have added that to a 0.6.6 and dropped clients that didn't upgrade to 0.6.6 for 64player modded servers or made that a 0.7? 14:18 < bridge> [teeworlds] I could do a mod right now that drops half the people at random 14:18 < koomi> LordSk: yeah but it's enabled/encouraged by a potential feature of the official client 14:19 < bridge> [teeworlds] I would call it thanos 14:19 <@Dune> Same goes there, it's only for mods, teeworlds could have extended the player limit for 0.6.6 and +. But isn't that a poor solution? 14:19 < Learath2> You can't regulate which clients a mod wants to accept. Would you ban all servers that refuse to serve 0.7.2 from the master list? 14:19 <@Dune> Of course not? 14:20 < koomi> Learath2: in which case? for zcatch you can just send the color updates and older clients will ignore them, you would still get a playable game 14:20 <@Dune> But you could debate the idea of introducing a feature that can only be used by servers that drop early clients, falsely broadcasting themselves as compatible 14:20 < Learath2> koomi: barely playable IMHO, you'd have to hack in some kind of indicator of currently captured tees, for infection class there is no workaround that I can think of 14:21 <@Dune> why can't infection work, Learath2? I think I'm not familiar enough with that mod, maybe you could explain :) 14:21 < Learath2> re-introducing a feature that many players from the previous iteration of the game would like to see 14:22 < Learath2> you do realize that most of the 0.7 players would be coming from 0.6 and not steam right? 14:22 < bridge> [teeworlds] So there one alternative right, wait for 0.8 14:22 < koomi> yeah I'm not familiar with infection either, but zcatch without colors would be just fine IMO 14:22 <@Dune> I would like that feature to be reintroduced if there was a nice way :) 14:22 < bridge> [teeworlds] and we're stuck with this system for eons 14:22 < Learath2> Dune: infection is possible, infection class introduces classes, your skin/color represents your class 14:23 <@Dune> is it critical that the player knows his own class? can it be changed by the server? 14:23 < Learath2> yes and yes 14:23 < koomi> again, you can just introduce handling of client updates in future clients, but please please don't make dropping older but supposedly compatible clients a common accepted thing for mods to do 14:25 < Learath2> you say that like it would be detrimental, I fail to see how the 10 odd servers that would run infection class not accepting the 5 odd people stuck on an archaic distro is detrimental to the entire game 14:26 < Learath2> Besides dropping old clients is already common practice for block servers that get a huge share of the players, they literally drop everything except latest ddnet and latest ath 14:27 <@Dune> any non-backwards compatible feature could have been introduced like that 14:27 <@Dune> anything in 0.7 could have been done in a 0.6.6 afaik 14:27 <@Dune> but that would be very ugly, wouldn't it 14:28 <@Dune> (see the example with introducing a feature allowing mods to use 64p and thus encouraging to drop <0.6.5 clients) 14:28 < koomi> Learath2: maybe my fears are unfounded but IME making that sort of incompatibility acceptable often leads to lots of fragmentation in the user base 14:28 < koomi> and block is trash anyways :-P 14:28 < Learath2> 0.7 is a major change, respecting the server for playerinfo is a very very minor change that would only affect mods that HAVE to use that feature 14:29 < Learath2> koomi: yeah, but around 50% of the community plays block and if ddrace is ported over they'll be one of the major groups coming over to 0.7 14:29 < TeeSlayer> Learath2: it already is 14:29 < koomi> then please don't do it? :-P 14:29 < TeeSlayer> Learath2: I host a copy love box and blmap4 server 14:29 < TeeSlayer> on 0.7 :P 14:30 < TeeSlayer> blmapv3royal can't be supported yet though 14:30 < Learath2> Oh yeah, Dune was working on a minimal ddrace, didn't think you finished it though 14:30 < Learath2> s/you/he/ 14:30 < TeeSlayer> Sadly I haven't seen anybody blocking on my block server yet xD 14:31 <@Dune> Learath2: it's actually a very small amount of code 14:32 < Learath2> Dune: we introduced 64p in a way that supports all clients, ddwar ddrace and ddnet could have easily dropped older clients and called it a day 14:32 <@Dune> yeah I know 14:32 < Learath2> But in that case there definitely was a workaround 14:33 < Learath2> Quite an unpleasant one I have to admit, but it worked decent enough that we didn't have to drop anyone 14:33 <@Dune> https://github.com/axblk/teeworlds/compare/race...Dune-jr:ddr 14:33 <@Dune> the mod is not even 300 lines of code :) 14:34 < Learath2> Anyways, it's not a feature I'm interested in. I just find it interesting that you are all so strongly opposed to such a minor change 14:34 <@Dune> I would love to see that changed back :/ 14:34 < bridge> [teeworlds] Also for the infection class thing, couldn't you just broadcast the class to the client? 14:35 <@Dune> that's a good point - other clients info can be changed, and the local client can be informed via broadcasts 14:35 < Learath2> I mean sure as a workaround you could put it up in broadcast 14:35 <@Dune> TeeSlayer ^ 14:37 < Learath2> Never being able to introduce a feature because a released version doesn't support it is just a concept that sounds insane to me 14:38 < TeeSlayer> Dune: are you talking about the current version? as a workaround? 14:38 < Learath2> (for a game that is) 14:38 <@Dune> yes TeeSlayer 14:38 < bridge> [teeworlds] I'm still for enabling the feature though, I just meant you don't need to drop the "incompatible" clients 14:38 <@Dune> Learath2: it's just saying that compatibility-breaking changes should be kept for compatibility-breaking versions 14:38 < bridge> [teeworlds] with the broadcast workaround 14:39 < Learath2> If I was going for a fork of teeworlds one of the first things I'd be doing would be introducing an ISUPPORT message so the client and server can negotiate features 14:40 <@Dune> then you would drop out major versions and broadcast a minimum required version for each server? 14:40 < Learath2> @LordSk as soon as you enable it the only thing you can do is to hope that mod developers don't just end up dropping clients assuming you agree that dropping old clients is a bad idea it just opens a can of worms 14:41 <@Dune> (by dropping out major versions I mean all version updates would be on an equal foot) 14:41 < Learath2> Yeah something like that, either the server registers with the master a list of features it needs or a minimum version 14:42 <@Dune> I see pros and cons :) 14:43 <@Dune> But that could work well 14:43 < bridge> [teeworlds] Honestly I agree with what you are pointing out 14:44 < bridge> [teeworlds] However we don't have any stats (I think?) that allows us to know what client version people are running 14:44 < bridge> [teeworlds] And the game population is already low as it is 14:45 < bridge> [teeworlds] Thinking about a perfect solution only applies to a perfect world 14:45 < Learath2> I mean if you don't want servers discriminating towards game version best way to make sure is to not send the version :) 14:45 < bridge> [teeworlds] Where there are millions of players all running somehow different verisons 14:45 < TeeSlayer> Dune: could you give me a tip which method to use? I'm not entirely sure what is meant by that. LordSk did it like this: https://github.com/LordSk/teeworlds/blob/mod/zomb/src/game/server/gamemodes/zomb.cpp#L913 (while ignoring the local player) 14:46 <@Dune> we only have stats on server versions - there are like 12 servers out of 70 0.6.x servers that use 0.6.5? 14:47 <@Dune> TeeSlayer: just send a broadcast for self info? 14:47 < Learath2> As in use the broadcast to indicate which class you are instead of the skin 14:48 < TeeSlayer> but that's just textual, isn't it? 14:48 < Learath2> Well it is a workaround :D 14:48 < TeeSlayer> well ok 14:49 < TeeSlayer> I'm not porting infection atm, but zcatch^^ 14:49 < bridge> [teeworlds] You could color the text TeeSlayer 14:49 < Learath2> Can you do color broadcasts nowadays? If so maybe you could use a color to indicate class 14:49 < TeeSlayer> Learath2: yes, but you have to enable it in the settings 14:49 <@Dune> @LordSk keeps this secret :D 14:49 <@Dune> but yeah you can 14:50 < Learath2> Anyways, I have about 5 data structures I need to code up in C, so bbl :) 14:50 <@Dune> (just a tease on how we need someone to write a presentation post on broadcast colors :p) 14:58 <@Dune> this says speeds are in pixels/s https://www.teeworlds.com/?page=docs&wiki=server_tuning 14:58 <@Dune> I wonder what "pixel" means in context 15:04 < TeeSlayer> Dune: btw the default cursor in the gamer client looks horrible. everything else is amazing though^^ 15:05 <@Dune> huh I didn't change that afaik 15:05 <@Dune> https://github.com/Dune-jr/teeworlds/blob/gamer/datasrc/ui/gui_cursor.png 15:05 <@Dune> this? 15:06 < TeeSlayer> no the ingame cursor 15:06 <@Dune> oh crap, mistakenly uploaded a random modified game.png 15:07 <@Dune> game.png changes weren't on purpose 15:08 <@Dune> goddamn git changing it during a merge 15:11 < bridge> [teeworlds] yeah blame the tool Dune 😄 15:12 <@Dune> I do, @LordSk. `git pull upstream master` committed a ton of cmake changes, and drowned the game.png change 15:12 <@Dune> didn't notice 15:13 < bridge> [teeworlds] I was just kidding 15:59 < TeeSlayer> does anybody know where I can find the source code for the AI? 16:45 <@Dune> which AI? 16:46 < bridge> [teeworlds] the bot server one? (https://github.com/nheir/teeworlds/tree/server_bot0.7) 17:26 <@heinrich5991> Dune: a tile is 32 "pixels" 17:26 <@heinrich5991> or rather an ingame unit 17:26 <@heinrich5991> it's the smallest unit ingame 18:29 < TeeSlayer> @LordSk Thanks. Client bot would be cool, but I'll figure something out 18:29 < TeeSlayer> I need to debug zcatch xD 18:35 < TeeSlayer> I think PostTick() in player.cpp should also check whether m_ViewPos really exists in the last else if. I had a segfault there right after the game ending. It probably doesn't happen in Vanilla since I had to modify DeadSpecMode so that people can respawn within a round. 18:36 < TeeSlayer> https://github.com/teeworlds/teeworlds/blob/master/src/game/server/player.cpp#L133 20:59 < rand> you can trick the client, instead of changing the the color of a client, you change those of everyone else (for zcatch i guess) 21:00 < rand> the drawback is that if somebody touch you, his whole team get your color instead of you getting the team color 21:01 < rand> about dropping client, as far as the protocol is compatible, regardless the client accepting client_info IG, the client can also play with a degraded gametype 21:02 < rand> with a nice message like, "you need the version >1.2 to fully experience this game" 21:03 < rand> because teeworlds will surely get a 1.0 version 21:29 < TeeSlayer> rand: thanks for the info. sounds nice :) 21:30 < TeeSlayer> about the other issue: the source code in the Teeworlds server is okay, nothing to change there. it was my mistake after all xD 21:32 <@Dune> I see heinrich5991, thanks 23:01 < Paprikamajonesi> Welcome to play new free MMO browser game :) --> https://www.avabur.com/?ref=18774 23:22 < TeeSlayer> >free >ref