Some issues of framework about defaultecs HOT 4 OPEN

Also i think you should probably drop support for .NET Standard 1.1

The reason is quite simple. Old projects that may still use it probably wont adopt it, since ECS framework is a core thing, you plug it in at the start of development, not after you already released your game or close to it.

And new projects even in worst-case scenario will probably have access to at least .NET Standard 2.0, since they will most probably use newer engines, or write their own.
Last Unity version that didnt support 2.0 is somewhere around 2017, and is no longer supported, for example.

Dropping it, instead, will allow to upgrade some things, like runners.

from defaultecs.

1. You think useBuffer should be true by default then? Normally bad usage should be picked up by the analyzer but I now there is some cases not detected yet. I have some ongoing changes not pushed yet but I can't find the time to finish it >_<
2. Oh that's a big miss of me, I didn't pay attention when adding the TrimExcess I'll fix that thank for reporting it.
3. Someone suggested a version with safety check incorporated in the lib (to get better errors message in case that occurs). I'm probably going to go this road, creating a DefaultEcs.Debug package or something to better help find those kind of issues. Currently I'm trying to split DefaultEcs.Serialization from the main package so it'll be the big next refacto.

Thanks for reporting all that :)

from defaultecs.

1. You think useBuffer should be true by default then? Normally bad usage should be picked up by the analyzer but I now there is some cases not detected yet. I have some ongoing changes not pushed yet but I can't find the time to finish it

The thing here is that not everyone is running the analyzers in the first place. So making potentially risky default behaviors and then pray analyzer catch the misuse is probably not the best idea.

2. Oh that's a big miss of me, I didn't pay attention when adding the `TrimExcess` I'll fix that thank for reporting it.

Lightweight version would be nice too. I mean, the moment you start to take entities from outside of EntitySet output is when IsAlive stops being a debug thing, and thus, its performance starts to matter.

3. Someone suggested a version with safety check incorporated in the lib (to get better errors message in case that occurs). I'm probably going to go this road, creating a DefaultEcs.Debug package or something to better help find those kind of issues. Currently I'm trying to split DefaultEcs.Serialization from the main package so it'll be the big next refacto.

Well, the whole idea is to receive adequate errors when you do not expect said errors. To give you an example of why, the demo of the game i'm working on is now on steam, some people encounter bugs.... and i have no clue what's that about, because its not a debug build, there is no lines specified in the logs... so, when errors happen most of the time i have no clue where to even start.
I mean, debug package wouldnt hurt, i guess, but i imagined something more primitive that will make it into release builds as well.

from defaultecs.

falling into the pit of success instead of favoring the 5% edge case hum, it's probably the saner option.

the demo of the game i'm working on is now on steam, some people encounter bugs.... and i have no clue what's that about, because its not a debug build

ouch yeah for something as complex as a video game it's difficult to expect everything to be catched during development. Maybe losing some cycles to return an easy to track exception is wiser...

from defaultecs.