SL21W41: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
|||
(11 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
[[SL21W40|◄ SL21W40]] | [[SL21W42|SL21W42 ►]] | [[SL21W40|◄ SL21W40]] | [[SL21W42|SL21W42 ►]] | ||
<br /> | |||
*Cleanup Week 2 | |||
**Completely remove Desktop-special case as a screen, use dynamically created ScreenModel internally to reduce complexity | |||
***Got rid of most of the special caching / update flags for desktop this way | |||
***Code reduction as the general purpose cache now works nicely | |||
***'''Add a quick board comparison/equality check by comparing screen-size first (+ tile element count second)? Needed? The BoardHash should do this already right?''' | |||
**Fix: Screen not refreshing on first open (Land manager) | |||
**'''Fix: Screen Statistics-system no longer correct''' | |||
**Removed '''current money''' from screen as it makes caching nearly impossible. | |||
***'''=> Always changing information should not be part of Header/Footer''' | |||
***'''=> "Adspace" on top could now be a seperate screen !''' | |||
***'''=> "Adspace" on right could now be a separate screen !''' | |||
***'''Separation of these spaces would make caching much more effective (board / pre render caching)''' | |||
**Fix: Plant interaction | |||
***Fix hitbox positioning of plants | |||
***Fix hitbox count for cubic plants | |||
***Fix screen position interaction on cubic plants | |||
***Added pixel-perfect interaction for plants (transparent interactions are ignored) | |||
***'''Hitbox shadows/Plant shadows are annoying/random? can we disable those?''' | |||
****'''Try placing as riding on armorstand. Might remove shadow''' | |||
****'''Try different spawn-order. Hitbox first frames later''' | |||
****'''Try spawning 0.01 blocks higher/lower''' | |||
****'''Try different materials''' | |||
****'''Try adding other metadatas''' | |||
*Nils intro to Kadi / Chunkli design | |||
**'''General setup of Stasi-Plugin, based on Chunkli Api''' | |||
***'''Think/Test persistence layer''' | |||
***'''Make sure we respect shulker boxes in some way?''' | |||
***'''95% of data is archival data mostly? Important is mostly just worldchanges ~7 days + chat ~3 month; rest can be slow / compressed?''' | |||
***'''Most likely PostgreSQL + time-series => Timescale db? on an external logging server with batched, async, streamed inserts?''' | |||
****'''Specifically the data compression would be handy here for non-confirmant itemstacks where all data needs to be logged and not just a LibId''' | |||
****'''"Small datasets typically see no performance advantage on TimescaleDB vs PostgreSQL (in fact, they might be slightly slower)"''' | |||
****'''"The queries run (they should typically be time-oriented restriction clause)"''' | |||
***'''We need to test couchbase for this''' | |||
****'''Assuming the search/query times are 'ok' and the datasize is 'ok' as well we should probably opt for having only one DB as long as possible to reduce complexity''' | |||
****'''Even "optimized" documents like ('''https://blog.couchbase.com/the-series-on-time-series-in-couchbase-episode-1/) '''are probably not worth it until far later in the project.''' | |||
**'''Test Geospatial as a save/search format''' | |||
***https://docs.couchbase.com/server/current/fts/fts-supported-queries-geo-spatial.html | |||
***https://blog.couchbase.com/how-to-geospatial-polygon-search/ | |||
***https://blog.couchbase.com/geospatial-search-how-do-i-use-thee-let-me-count-the-ways/ | |||
***'''We can use 0.001 as one block in lat/lon''' | |||
***'''1.000 would be the block at X 1000''' | |||
***'''Y would be altitude, not directly searchable in geospatial data typically''' | |||
***'''A blockchange at X -54_321 and Y 150 and Z 765 would be saved as { lat: -54.321, lon: 0.765, alt: 150 }''' |
Revision as of 21:27, 16 October 2021
- Cleanup Week 2
- Completely remove Desktop-special case as a screen, use dynamically created ScreenModel internally to reduce complexity
- Got rid of most of the special caching / update flags for desktop this way
- Code reduction as the general purpose cache now works nicely
- Add a quick board comparison/equality check by comparing screen-size first (+ tile element count second)? Needed? The BoardHash should do this already right?
- Fix: Screen not refreshing on first open (Land manager)
- Fix: Screen Statistics-system no longer correct
- Removed current money from screen as it makes caching nearly impossible.
- => Always changing information should not be part of Header/Footer
- => "Adspace" on top could now be a seperate screen !
- => "Adspace" on right could now be a separate screen !
- Separation of these spaces would make caching much more effective (board / pre render caching)
- Fix: Plant interaction
- Fix hitbox positioning of plants
- Fix hitbox count for cubic plants
- Fix screen position interaction on cubic plants
- Added pixel-perfect interaction for plants (transparent interactions are ignored)
- Hitbox shadows/Plant shadows are annoying/random? can we disable those?
- Try placing as riding on armorstand. Might remove shadow
- Try different spawn-order. Hitbox first frames later
- Try spawning 0.01 blocks higher/lower
- Try different materials
- Try adding other metadatas
- Completely remove Desktop-special case as a screen, use dynamically created ScreenModel internally to reduce complexity
- Nils intro to Kadi / Chunkli design
- General setup of Stasi-Plugin, based on Chunkli Api
- Think/Test persistence layer
- Make sure we respect shulker boxes in some way?
- 95% of data is archival data mostly? Important is mostly just worldchanges ~7 days + chat ~3 month; rest can be slow / compressed?
- Most likely PostgreSQL + time-series => Timescale db? on an external logging server with batched, async, streamed inserts?
- Specifically the data compression would be handy here for non-confirmant itemstacks where all data needs to be logged and not just a LibId
- "Small datasets typically see no performance advantage on TimescaleDB vs PostgreSQL (in fact, they might be slightly slower)"
- "The queries run (they should typically be time-oriented restriction clause)"
- We need to test couchbase for this
- Assuming the search/query times are 'ok' and the datasize is 'ok' as well we should probably opt for having only one DB as long as possible to reduce complexity
- Even "optimized" documents like (https://blog.couchbase.com/the-series-on-time-series-in-couchbase-episode-1/) are probably not worth it until far later in the project.
- Test Geospatial as a save/search format
- https://docs.couchbase.com/server/current/fts/fts-supported-queries-geo-spatial.html
- https://blog.couchbase.com/how-to-geospatial-polygon-search/
- https://blog.couchbase.com/geospatial-search-how-do-i-use-thee-let-me-count-the-ways/
- We can use 0.001 as one block in lat/lon
- 1.000 would be the block at X 1000
- Y would be altitude, not directly searchable in geospatial data typically
- A blockchange at X -54_321 and Y 150 and Z 765 would be saved as { lat: -54.321, lon: 0.765, alt: 150 }
- General setup of Stasi-Plugin, based on Chunkli Api