Teeworlds - bridge

Teeworlds

IRC / bridge

One-way IRC channel bridge. If you want to be able to send messages to IRC, contact @Dune or @heinrich5991. https://www.teeworlds.com/?page=docs&wiki=rules/irc_rules

Between 2020-05-22 00:00:00Z and 2020-05-23 00:00:00Z

I am experiencing a weird bug, I want to make some kind of portal teleportation, works fine but if there is a freeze inbetween the portal positions the tee arrives frozen, if theres a teleporter between, tee will use that teleporter

00:11

I am just setting the core position, which always worked and also still works for teleporters

00:12

it gets set from inside another entitiy class, that one has its own ENTTYPE_, maybe its because its enttype is larger than the character ones?

00:12

nope its not, mh i have no idea

you could make a test map and make a breakpoint to the freeze effect. then inspect the call stack when you hit the freeze

i did a dbg_break now

00:17

well, i see that the handletines is in post core tick

00:17

but i dont know why it should get frozen

00:18

i know its some kind of order, but i dont know whcih (?), because from the ConTeleport command it also just sets the position

the freeze effect comes from handletiles in postcoretick?

yes

(ConTeleport does its stuff between two ticks)

öh

00:19

wym

ConTeleport sounds like a console command

yea, its the rcon tele cmd

the server lets the world tick every 20ms. during that tick handling, your tile code happens and after that postcoretick is called

00:20

conteleport only gets called while the server is not ticking the world

no, postcoretick is called in chr::tick, but after the charactercoretick happened

(the server is singlethreaded, while it's trying to tick the world it can't do anything else like handle rcon commands)

whats the right approach now? like whats the plan?

00:22

do i need to set the pos from inside the character? so i need to mark it so it can teleport itself?

I'm currently looking at how teleporting by tiles is handled

probably AFTER the core tick happened

00:23

well not probabaly, it is

good. so make it happen for your teleport as well, I guess

00:24

e.g. by having a bool m_Tele and vec2 m_TeleTo

00:24

which gets checked after the character tick has happened

it should already, because the ENTTYPE of my portal is > then ENTTYPE_CHARACTER, which means the whole portal entitie should be ticked after the character, so also after the character tick

00:24

I also tried setting position from portal::tickdefered, but that also didnt work

00:25

*also fter the character CORE tick

log the current world ticks in the respective tick functions and check whether you're actually called after the core tick

00:26

I'm off for tonight, good night

00:27

the rule to debugging things that should not happen: try to confirm/reject the things you believe to be true

00:27

if you think you're getting called after the character, verify it

character, Tick: 487
[2020-05-22 02:31:47][hi]: portal, Tick: 487
[2020-05-22 02:31:47][hi]: character, Tick: 488
[2020-05-22 02:31:47][hi]: portal, Tick: 488
[2020-05-22 02:31:47][hi]: character, Tick: 489
[2020-05-22 02:31:47][hi]: portal, Tick: 489

00:32

portal happens after character, as i thought

Why is your portal ticking at all? This sounds like you are asking for trouble, there is a reason we handle all the tiles in the character entity

@fokkonaut then also check at what point the freeze detection ticks

@Learath2 portal is not a tile, its an entitiy xd

11:38

and its not placed by a tile from editor

not placed from editor is an interesting constraint

Handle tiles captures all movements since the last tick. m_PrevPos is saved in Tick(), m_Core.Move() happens in TickDefered() and HandleTiles() is called in the next Tick() (so everything in HandleTiles is delayed by one tick). You might try also setting m_PrevPos to the new position

12:04

One of the many ugly physics things...

that sounds like it should work, let me try that

12:27

and yes, it actually does, thanks alot

nice :)

https://paste.zillyhuhn.com/MG a player was able to join using the name "(connecting)" and then continue playing with a different name (see id=1)

Your name is connecting until you are Server()->ClientIngame()

Exported 49 message(s)