SL21W41: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
No edit summary |
||
(4 intermediate revisions by the same user not shown) | |||
Line 7: | Line 7: | ||
***Got rid of most of the special caching / update flags for desktop this way | ***Got rid of most of the special caching / update flags for desktop this way | ||
***Code reduction as the general purpose cache now works nicely | ***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 not refreshing on first open (Land manager) | ||
**Removed '''current money''' from screen as it makes caching nearly impossible. | **Removed '''current money''' from screen as it makes caching nearly impossible. | ||
***'''=> Always changing information should not be part of Header/Footer''' | ***'''=> 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: Plant interaction | ||
***Fix hitbox positioning of plants | ***Fix hitbox positioning of plants | ||
Line 20: | Line 19: | ||
***Fix screen position interaction on cubic plants | ***Fix screen position interaction on cubic plants | ||
***Added pixel-perfect interaction for plants (transparent interactions are ignored) | ***Added pixel-perfect interaction for plants (transparent interactions are ignored) | ||
*** | ***Hitbox shadows/Plant shadows are annoying/random? can we disable those? | ||
**** | ****! We can only show F3 Hitboxes + Shadows OR NO F3 hitbox and no shadows! | ||
*Nils intro to Kadi / Chunkli design | *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 } | |||
Stasi couchbase result => Works super well, Geospatial does not really help. |
Latest revision as of 23:23, 3 November 2022
- 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)
- 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?
- ! We can only show F3 Hitboxes + Shadows OR NO F3 hitbox and no shadows!
- 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
Stasi couchbase result => Works super well, Geospatial does not really help.