| Time |
Nick |
Message |
| 00:50 |
MTDiscord |
<exe_virus> I got a lot more into the nitty gritty of testing on this cache for entity in area and radius checks. My current solution has one key nuance that is different from current behavior, and I can make it exactly match current behavior, but wanted clarification: |
| 00:51 |
MTDiscord |
<exe_virus> Right now, when an entity is to be added during iteration, it is saved until the end of iteration. |
| 00:52 |
MTDiscord |
<exe_virus> In my version, that entity is added as soon as the current mapblock chunk is done being operated on. So: in my branch, you might find a newly added entity from that current get objects in radius/area call, in that calls iterator. But in master, you'll get it on next call, not the current. Thoughts? Should I keep my slightly faster updating one? |
| 01:54 |
|
TheCoffeMaker_ joined #minetest-dev |
| 02:24 |
|
SoniEx2 joined #minetest-dev |
| 04:00 |
|
MTDiscord joined #minetest-dev |
| 04:19 |
|
YuGiOhJCJ joined #minetest-dev |
| 04:38 |
|
fluxionary joined #minetest-dev |
| 06:01 |
[MTMatrix] |
<grorp> #14614 |
| 06:01 |
ShadowBot |
https://github.com/minetest/minetest/issues/14614 -- Entity spawned in `on_step` not visible to `get_objects_inside_radius` |
| 07:35 |
|
Thomas-S joined #minetest-dev |
| 07:35 |
|
Thomas-S joined #minetest-dev |
| 10:27 |
|
Thomas-S joined #minetest-dev |
| 10:27 |
|
Thomas-S joined #minetest-dev |
| 15:41 |
|
fluxionary joined #minetest-dev |
| 18:49 |
|
Niklp joined #minetest-dev |
| 18:51 |
|
Niklp joined #minetest-dev |
| 19:02 |
MTDiscord |
<josiah_wi> Not easily fixable and ExeVirus fixes it accidentally. What a legend. |
| 19:09 |
MTDiscord |
<luatic> if i understand ExeVirus correctly, this "fix" only works sometimes, so it's not a reliable fix |
| 19:11 |
MTDiscord |
<luatic> i'm not quite sure why this wouldn't be easily fixable however. the modify safe map basically just consists of two maps: one to hold the current state (in which entries may be marked as deleted), and one to hold the newly added entries. |
| 19:11 |
MTDiscord |
<luatic> what if we just checked the second map if we got a miss in the first one? |
| 19:21 |
MTDiscord |
<exe_virus> oh, well my map uses an iterator, and that iterator would be invalidated if the entity was added to the current block. I could just search the pending entity list at the end of iteration before adding them, but then: what do you do about new ones added while iterating that vector.... well it is just a vector, could just use .size() as the check on a normal for loop and.... what about deletes.... |
| 19:23 |
MTDiscord |
<exe_virus> and modify safe map.... If I ask for an object while we are iterating, we shouldn't have any issues now that we are using other structures for entity iteration |
| 19:26 |
MTDiscord |
<luatic> well, my data structure is strictly a spatial index. it is not used (and should not be used) for iterating entities to run on_step callbacks. |
| 19:27 |
MTDiscord |
<exe_virus> ah, nevermind: mine won't be used that way either: mine does out of order IDs |
| 19:28 |
MTDiscord |
<luatic> i don't think the ID order matters |
| 19:28 |
MTDiscord |
<luatic> the only reason we have it is because it seems to somehow (?) fix an issue but it is not clear how this works in general |
| 19:28 |
MTDiscord |
<exe_virus> then I guess it can be used for that. Let's hold off on making this unmergable and keep it simple, and look into further fixes later please 🙂 |
| 19:28 |
MTDiscord |
<luatic> the problem is, i couldn't reproduce the issue last time i tried, even though i would not expect it to work in general |
| 19:29 |
MTDiscord |
<luatic> ExeVirus: agreed |
| 19:29 |
MTDiscord |
<luatic> this would be in a separate PR |
| 19:45 |
MTDiscord |
<exe_virus> also: the reason ordered IDs matter I believe is for attached objects: we want the parent to be updated first, and attached object second. That's how I remember it at least |
| 20:00 |
|
grorp joined #minetest-dev |
| 20:18 |
MTDiscord |
<exe_virus> Ready for review: https://github.com/minetest/minetest/pull/14643 |
| 20:26 |
grorp |
merging #14743 in 10 min |
| 20:26 |
ShadowBot |
https://github.com/minetest/minetest/issues/14743 -- Android: Fix back button sometimes not working as ESC by grorp |
| 20:45 |
|
grorp left #minetest-dev |
| 20:50 |
|
rubenwardy joined #minetest-dev |
| 21:06 |
MTDiscord |
<luatic> ExeVirus: yes, i know, but the thing is, in general there is no guarantee that the parent will have a smaller id than the child. |
| 21:09 |
sfan5 |
the "order the map to fix attachment chains" thing is broken, I think we discussed it here |
| 21:09 |
MTDiscord |
<luatic> yes |
| 21:10 |
MTDiscord |
<luatic> i wonder how to reproduce the attachment issues however |
| 21:10 |
MTDiscord |
<luatic> recently i tried attaching a stack of boxes to a "racecar" in devtest and i didn't see anything (i also tried creating & attaching the entities in different orders, since the map is ordered) |
| 21:38 |
MTDiscord |
<exe_virus> Personally, without looking at the engine, I assume we attach entities to their parent, so a parent has a list of children. And those children have a list of children. And children know when they are attached... Â So just loop over everyone, skipping attached entities, and when a parent has children, update the children then. |
| 21:39 |
MTDiscord |
<luatic> yes, this should be simple to solve properly recursively |
| 21:39 |
MTDiscord |
<luatic> i wanted to do that, but as said, first i'd need a proper reproducer for the issue. and my rudimentary attempt at that failed. |
| 21:48 |
MTDiscord |
<jordan4ibanez> If I create a DOM for minetest formspecs and add in new features that we've been asking for, will this pr immediately get shot down? |
| 22:35 |
|
panwolfram joined #minetest-dev |
| 23:24 |
MTDiscord |
<exe_virus> No, vrob has such a PR already |
| 23:25 |
MTDiscord |
<mistere_123> you could help him with it though; he doesn't have much time available for it. |
