Coding Task List - Before IB2 Initial Release

[zach_holbrook]

Wow! Seven years...

[Dorateen]

[slowdive]

That sounds/looks really cool with the scripts for factions. We are still getting through the “moving in” phase and my work area is looking better. Hopefully I can get back to IBx soon. I will probably be targeting MacOS, iOS, Android, and ChromeOS. It will be exactly the same thing/code as the PC version just using xamarin to target other platforms.

[zach_holbrook]

I've run into a bug with the waypoint placement button on area maps. After I select or place a prop, the toolset sometimes defaults to WP placement mode and other buttons cease working until the map is closed. I've also found that saving in this state can lead to a crash.

[youngneil1]

[slowdive]

Installing VS 2019 at the moment with Xamarin. Looks like there have been some updates to SkiaSharp as well. I may try and look into moving to normal Xamarin instead of Xamarin.Forms for IBx. This way I can target more platforms such as MacOS. Xamarin.Forms only has Android, UWP, and iOS as official targets. We'll see though, may be too messy. Xamarin.Forms is nice because almost 100% of code is shared with all platforms.

[youngneil1]

[youngneil1]

Currently I am optimizing how the engine handles the mover choke points (squares that have waypoints for many props) that directly lie on a map border (like on a road that leads into the next map). This is a surpsingly complex subject- at least when I want to maintain smooth walking from one area to the next - as the pathfinding (and therewith alternative route calculation for eg walkign around another prop) itself does not work cross different areas. I will allow the presence of multiple props on a choke point square, but at the same time make sure that those immediatly move away from choke points, keeping the time of overlapse as small as possible.

[youngneil1]

I think I have a working solution for the chokepoint/bottleneck problem described above:

1. Movers between neighbouring areas are allowed to stack with other movers of all kinds on area departure and arrival waypoints directly on map border (crossover waypoints). This is an exception to the one mover per square rule.
2. To minimize potential mutliple movers on one square situations, they will immeditaley leave such crossover waypoints on area border, overriding any departure time settings.
3. All of this is only true for time driven movers on crossover waypoints between areas (on each side of area border). All other situations still adhere to the one mover per square rule. Arrival locations for movers teleporting/spawning into an area without smooth transition will respect the one mover per square rule - in occupied arrival square cases the code tries to find a fitting alternative nearby arrival location. Movers targeted toward a non-neighbouring area will also not enter an occupied departure waypoint square - instead they will simply teleport from where they are towards the non-neighbouring area when the time has come. Both behaviours - teleport in arrival and teleport off departure - are flagged with "Just arrived here" and "Heading off" floating messages respectively.

First playtesting of this looks very promising ...

[youngneil1]

IB v179 released - no liabilities, no warranties, use at your own risk:

https://www.dropbox.com/s/uzipfav0ka53v ... 9.zip?dl=0

- implemented solutions for chokepoint/bottleneck spots concerning waypoints of movers on the same spot (see above); this goes a long way in making the placement of movers in the toolset a fire and forget process - the little buggers are much better at getting aorund/through each other even in very complex, crowded, cross-multi-area scenarios now