It’s to prevent bumping the version and triggering a change filter while still being able to write to it. I agree, it’s a bit weird and the code comment could make it a lot clearer. The only difference really is that either GetComponentDataWithTypeRO or the RW version is called. Both versions of the method return a RefRW which can be used to change data.
I suggested in Discord to rename it to bumpVersion or dontBumpVersion. There were some arguments against it that I don’t remember anymore.
Anyway, the important part is, for most entities method calls that have RW/RO. RW always bumps the version and those will trigger changes in the chunk. To get a good change filter going you have to be very mindful about it otherwise you run into the risk to bump the version every frame regardless of writing or not.
Wow! It is a very useful API. As I understand we can write to component without bumping it’s version. But can we do the same with IJE / IJC? I mean without using ComponentLookup but iterating entities / chunks directly?
I actually do this a lot as well as manually bumping change filters.
I even have a bunch of custom containers and extensions for this purpose, such as a ‘ChangeFilterLookup’ https://gitlab.com/tertle/com.bovinelabs.core/-/blob/0.15.2/BovineLabs.Core/Iterators/ChangeFilterLookup.cs
(Why not just use a regular ComponentLookup you ask? It’s because I have cases where I want to look at a component with a NativeContainer but not read the component data.)
Taking control of your change filters can net some really high performance architecture, but it’s pretty advanced and you really have to know what you’re doing and be careful to maintain it.