00:00 < bridge> Eeeh, the issue with that is we are not allowed to do physics changes, breaking reproducability is also not a great idea 00:00 < bridge> map setting 00:04 < bridge> it doesn't act as an actual cp, just lets you spawn left/right and they should only be allowed at drag parts 00:06 < bridge> learath this automa extension is really awesome but they replaced all their docs with a redirect to a new thing and it's totally different 00:06 < bridge> :feelsbadman: 00:22 < bridge> Hopefully the new docs are better? 00:22 < bridge> it’s for an app 00:22 < bridge> which looks like it serves a similar function but isn’t the same product 00:23 < bridge> python related now? can’t find the original docs 00:23 < bridge> but now im using it to fish 00:24 < bridge> https://cdn.discordapp.com/attachments/293493549758939136/1375962742590013561/image.png?ex=683398a9&is=68324729&hm=a5b2d8fe748530f010bc7b0b847fb4ec358f8a59c783648ac976c9a4ba2afe16& 00:25 < bridge> i got tired of the stupid lack of docs tho so it's just a js block and automa is basically acting as a userscript host 00:45 < bridge> this is true, but then the mapper has to do a lot of extra work :/ 00:46 < bridge> and it really only helps for drag parts unless im misunderstanding 00:46 < bridge> tp bounce issue happens in additional scenarios which wouldnt be fixed w invisible tp 00:49 < bridge> placing the tiles is really just a few minutes work 00:50 < bridge> it seems to make sense only using at drag parts at least. 00:51 < bridge> changing the cto/to tile doesn't seem to be the solution here as learath explained above. 00:51 < bridge> what is the other option? 00:51 < bridge> 00:51 < bridge> also the invis cp still has the secondary purpose 00:52 < bridge> it will fix the bouncing in most parts of the map. it wont be too bad on a non drag part ( hammer fly maybe ) 00:53 < bridge> aoe for example mapped the CP for a non drag part like that so you still have 2 different spawns 00:53 < bridge> https://cdn.discordapp.com/attachments/293493549758939136/1375970075718324224/image.png?ex=68339f7e&is=68324dfe&hm=d1b85f5bf07dd25c260f1e661e6182b1e30dd44a60d44149aecd4a290d748f6b& 00:54 < bridge> this wouldn't really work for drag parts. as they would need to run back to change the cp in case they wanna swap 00:55 < bridge> see now its just getting way too complicated xd 00:55 < bridge> im pretty sure if u fix cto itll be pretty decent such that nobody cares 00:56 < bridge> u can make old maps have old_cto map setting so physics can be changed just fine, idk if learath doesnt like that approach but its worked for bugs in the past 01:01 < bridge> also when tiles are invis the players kinda have to trust that the mapper placed them correctly. its also another thing to test (and itll be kinda annoying to test cus its invis) 01:01 < bridge> hm ye 01:01 < bridge> i just think the secondary purpose is also useful 01:05 < bridge> its probably the most convenient when done right, im just not convinced ppl will "do it right" 01:08 < bridge> a new cto/to tile would probably be good as well 01:08 < bridge> so people will never spawn in the same cto/to as the other player 01:10 < bridge> should be easy to crate 01:10 < bridge> should be easy to create 01:13 < bridge> Tbh idk if we can programatically fix the cto to make it make the person that is about to get dragged land on the correct side easily 01:14 < bridge> what u think abt this idea tho 01:14 < bridge> Maybe take note of the relative position of the first freeze the tee hits wrt the cp tile and nudge that tee to that side? 01:14 < bridge> just prioritize spawning on the same vertical line 01:14 < bridge> that could work 01:14 < bridge> Is it good enough to make people happy would be my concern 01:15 < bridge> the thing abt doing programatically id theres probably wt least one case where its just the opposite side of the correct side 01:15 < bridge> then its just annoying for a few random parts 01:15 < bridge> That's what I'm worried about too 01:15 < bridge> the first freeze is a nice idea though 01:15 < bridge> could pathfind to the nearest freeze too 01:17 < bridge> Pathfind is on the expensive territory 01:19 < bridge> yerp i would just cap it to a small radius but then its kinda useless 01:20 < bridge> actually i can think of parts where you want the dummy to be on the opposite side of the freeze (anything that starts w a throw) 01:21 < bridge> i have a great solution to everything but nobody will hear me out 01:21 < bridge> ddnet needs a reset button that works as kill but resets to the last state of each tee at a checkpoint 01:21 < bridge> the checkpoint can be triggered by shooting or hammering a checkpoint button, similar to i wanna maker (if anyone's played that) 01:22 < bridge> then you can just checkpoint your layout to get the exact same start each attempt 01:25 < bridge> Smells very prone to creating cheats 01:28 < bridge> yes but it would solve everything, trust me 01:28 < bridge> can give unfaily hh parts to the noobs with it 01:30 < bridge> since it resets state i think it would be somewhat safe 01:30 < bridge> need a ddnet formal checker 01:32 < bridge> Rocq proof when? 01:32 < bridge> If only we could get Zwelf twgame to completely match ddnet :/ 01:32 < bridge> If only we could get Zwelfs twgame to completely match ddnet :/ 03:14 < bridge> how does it work?(explanation for dummies pls) 03:28 < bridge> i assume if u hit tele while frozen, u spawn in the direction u were last freezed in 04:04 < bridge> 1820 checkpoints :jaouis: 06:54 < bridge> i like this more 06:54 < bridge> already has happened with a speeder fix 06:55 < bridge> well, im saying either this map setting way or new tele tiles entirely 06:55 < bridge> making a tile that fixes a bug instead of just replacing the thing didnt occur to me as odd until reading all this 06:55 < bridge> making a tile that fixes undesirable behavior instead of just replacing the thing didnt occur to me as odd until reading all this 09:48 < bridge> clang format sucks 09:48 < bridge> https://cdn.discordapp.com/attachments/293493549758939136/1376104570979094608/image.png?ex=68341cc0&is=6832cb40&hm=2e2bb13ee55297df14ec40f9c6384e4960c8921fa3239e5fb384a61968519844& 10:21 < bridge> what is best practice when looping through an enum? 10:21 < bridge> 10:21 < bridge> ```c++ 10:21 < bridge> for(CEvent::EventTypes i = CEvent::EventTypes::EVENT_ONE; i < CEvent::EventTypes::EVENT_LAST; CEvent::EventTypes(i + 1))` 10:21 < bridge> ``` 10:21 < bridge> this was the only solution i could find really :Pepega: 10:21 < bridge> what is best practice when looping through an enum? 10:21 < bridge> 10:21 < bridge> ```c++ 10:21 < bridge> for(CEvent::EventTypes i = CEvent::EventTypes::EVENT_FIRST; i < CEvent::EventTypes::EVENT_LAST; CEvent::EventTypes(i + 1))` 10:21 < bridge> ``` 10:21 < bridge> this was the only solution i could find really :Pepega: 10:21 < bridge> what is best practice when looping through an enum? 10:21 < bridge> 10:21 < bridge> ```c++ 10:21 < bridge> for(CEvent::EventTypes i = CEvent::EventTypes::EVENT_FIRST; i < CEvent::EventTypes::EVENT_LAST; CEvent::EventTypes(i + 1)) {}` 10:21 < bridge> ``` 10:22 < bridge> this was the only solution i could find really :Pepega: 10:24 < bridge> there is no solution 10:24 < bridge> because cpp commitee is sleeping on enum traits 10:24 < bridge> because cpp commitee is sleeping on enum type traits 10:24 < bridge> grrr 10:24 < bridge> grrr indeed 10:24 < bridge> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4428.pdf 10:25 < bridge> meh guess i'll just write a few lines of case return case return case return :angy: 10:25 < bridge> just make an array of all possible values :greenthing: 11:13 < bridge> wb arigreeen 15:16 < bridge> Use an int 15:16 < bridge> Don't use enums as types 20:13 < bridge> Unless you’re personally able to guarantee the type is sequential then I’d advise against doing this at all 20:13 < bridge> it’s also not type safe 23:12 < bridge> https://lottie.github.io/