[MOD 0.16 - 1.1] Portals

[Bilka]

Version 0.2.8 is out.

- Added remote functions
- Added custom events
- Nicer entity code

Remote functions and events are documented in the first post here, on github, on the mod portal and in the mod files.

[Bilka]

Version 0.2.9 is out.

- Renamed remote functions related to events
- Events now pass player_index instead of player (for consistency with vanilla)
- on_player_teleported now passes entrance_portal instead of old_position
- Removed useless item

[wvlad]

Hi, there is a bug that sometimes causes animations from previous portals never being removed. I can't figure out the repro steps, it just happens. Could you look into this please?

May be don't search for animation each time and just store its entity id instead so that no strange things may happen.

[Bilka]

Storing stuff is expensive which is why I'm not doing it. I'm planning a complete rework of the mod for 0.16 which should fix the issue. But without repro steps I can't help you at all, since that particular thing never occured for me.

[Sander_Bouwhuis]

Luckily I haven't seen those bugs. I really use this a mod a LOT.

Thanks for this and for maintaining it for v0.16!

[wvlad]

Here is the video of this bug https://www.dropbox.com/s/z7eipbcs3x666 ... 9.swf?dl=1

Expensive because you should not store entities at all, only their ids. This is how their serialization system works.

[Bilka]

1. Entities don't have id's. Some entity types can have a unit number but that's not an id
2. Smoke can't have a unit number. I cant store something the entity doesn't have.
3. Storing a unit number doesn't help much, if i want to find the entity associated with it i have to search all surfaces everywhere which absolutely murders performance
4. What serialization by whom are you talking about?
5. Why is that file an swf? I cant open that on my phone :/ The next time I'll be near my pc is Thursday

[wvlad]

1. Entities don't have id's. Some entity types can have a unit number but that's not an id

I meant number of course.

2. Smoke can't have a unit number. I cant store something the entity doesn't have.

Didn't know that.

3. Storing a unit number doesn't help much, if i want to find the entity associated with it i have to search all surfaces everywhere which absolutely murders performance

You are right, that's a shame that there is no get_by_number function.

4. What serialization by whom are you talking about?

I mean if you have a table of entities stored in global they will corrupt your save at some count because of incorrect serialization making very long data (above limits).

5. Why is that file an swf? I cant open that on my phone :/ The next time I'll be near my pc is Thursday

It shows that when I place a portal the label and the portal itself are created correctly under my cursor but the animation shifts 1 extra unit top-left by itself. Therefore it isn't consistent with the actual portal position and can't be found at expected position when removing.

[Bilka]

The entity saving in global is only a problem if you use them as table keys instead of values afaik. What you describe seems more like an issue that i have observed but believe to be the fault of the base game. What color is the animation that is misaligned? Is it orange, blue, or gray?

[wvlad]

Right, table keys.

Both are misaligned but it's not always. I can't figure out what affects it. I "fixed" it temporarily by editing the script to make search area bigger but the visuals are still broken.

[Bilka]

Well, 0.16 now allows what I need for my portals to only consist of two things, the portal itself and the label, so you can consider the animation bug fixed for 0.16

[FerrariMAF]

Hi Bilka, I found a bug in this version. The portals are leaving the nunber everywhere.

https://www.dropbox.com/s/9fvnakwtyjxwo ... l.png?dl=0


I think it happens when a players click and drag to build portals.

[Bilka]

Hi Bilka, I found a bug in this version. The portals are leaving the nunber everywhere.
I think it happens when a players click and drag to build portals.

That's known, and not reproducible reliably. It also happened in version 0.2.9, but I cant find the issue, since it seems to lie with the base game. Sometimes the portals place correctly, sometimes the text is offset from the portal, which is also built offset from the one in the cursor. At one point I though that it might get triggered by the player teleporting while they are placing a portal, but I havent been able to get the game into that state reliably. Here's some gifs:

images

0.15, weird placement:

0.15, placement inside buildings despite showing red:


0.16 (pre release), portal and label are offset to each other:

You seem to have encountered the bug shown in the last gif. Ususally putting the portal gun away and saving + reloading fixes the placement issue.

[Quezler]

I have found a way to reproduce the orphaned numbers in .16:

press the rotate button while holding the portal gun to make the issue appear, and rotate it again to disable the issue again, works infinitely.

[Bilka]

I have found a way to reproduce the orphaned numbers in .16:

press the rotate button while holding the portal gun to make the issue appear, and rotate it again to disable the issue again, works infinitely.

Thank you!!!! This means that I can fix the issue

[Quezler]

Please also include a way to remove the already present orphaned numbers from the current version of the mod, our world is filled with them :p

[Bilka]

0.3.1 is out:

• Fixed that portals could be rotated, which lead to orphaned numbers (viewtopic.php?p=328141#p328141)
• Added a script to remove orphaned numbers from the world when it is loaded in this version, this is run automatically
• Fixed migration

[Quezler]

loading a map from the previous version with the update you just made:

[Bilka]

Ah damn this is related to the bug I just fixed :/

New version is attached because the mod portal doesnt let me upload a new file...

[Bilka]

Version 0.3.2 is out:

• Fixed migration of broken portals