Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Deprecating IJobForEach, good replacement patterns

Discussion in 'Entity Component System' started by snacktime, Mar 13, 2020.

  1. snacktime

    snacktime

    Joined:
    Apr 15, 2013
    Posts:
    3,356
    I think I understand not wanting to support codegen for IJobForEach types and lambda's. But lambda's are not generally used for where Entities.ForEach can easily end up. With large amounts of code inlined in a single place. Inlining a lot of our job chains is a non starter. And I'm struggling to find patterns that don't just result in a lot of duplication and indirection with Entities.ForEach.

    Anyone found any tricks for managing this?
     
    phobos2077 and cultureulterior like this.
  2. snacktime

    snacktime

    Joined:
    Apr 15, 2013
    Posts:
    3,356
    Ah nm it's only IJobForEach top level generic that is going away.
     
  3. Joachim_Ante

    Joachim_Ante

    Unity Technologies

    Joined:
    Mar 16, 2005
    Posts:
    5,203
    Having a static method that gets called from the lambda method can be quite useful for more complex loops.

    When you want to drop down to the lowest level, you can also switch to IJobChunk. This also gives you control over the per chunk for loop over all entities in that chunk.
     
  4. snacktime

    snacktime

    Joined:
    Apr 15, 2013
    Posts:
    3,356
    Ya that works but that's pure indirection that stems from being forced to inline. It might very well be the lesser evil I don't know what factors went into the decision. But at this point I'm not ready to give up finding a better approach.
     
  5. snacktime

    snacktime

    Joined:
    Apr 15, 2013
    Posts:
    3,356
    So the use of extension methods here I think provides some possible solutions. At the very least being able to abstract away the indirection to some extent. Will have to play around with some approaches.
     
  6. RoughSpaghetti3211

    RoughSpaghetti3211

    Joined:
    Aug 11, 2015
    Posts:
    1,697
    Firsts I’ve heard of deprecating IJobForEach. Does anyone have a link where I can catchup on this I don’t see anything in the depiction sub forum.
     
  7. charleshendry

    charleshendry

    Joined:
    Jan 7, 2018
    Posts:
    95
  8. snacktime

    snacktime

    Joined:
    Apr 15, 2013
    Posts:
    3,356
    I think it's likely the lambda's will evolve a bit. Nobody making a large production game is going to inline everything that's just not happening. Neither is the amount of indirection created with the naive approach. But it looks relatively easy to fix you just might have to do it yourself for a while.
     
    R0man likes this.
  9. snacktime

    snacktime

    Joined:
    Apr 15, 2013
    Posts:
    3,356
    Another annoying thing about lambda's is auto complete fails mostly.
     
    R0man, ippdev and FONTOoMas like this.
  10. Antypodish

    Antypodish

    Joined:
    Apr 29, 2014
    Posts:
    10,753


    Sorry, but I don't get it.
    We had nice IJobForEach, to reduce overhead of of IJobChunk, now is getting removed?
    I like IJobForEach for its simplicity and similarity to other type of jobs, including IJobChunk.
    I shifted from IJobChunk to IJobForEach number of jobs.
    I really dislike whole Lambda approach. Call me archaic, but is just me.
     
  11. snacktime

    snacktime

    Joined:
    Apr 15, 2013
    Posts:
    3,356

    I think it makes sense if you look at the big picture. Unity doesn't target just professional developers. They need to keep their amateur market make things very accessible, and sometimes their target is split also. Like with shader graph where you have both artists and developers. I can see why they like lambda + builder pattern and how it fits into the bigger picture. This works due to having source. That gives them the ability to not have to create solutions to fit every part of their target market perfectly, or punt on some things at least for the time being.

    Lambda + builder is emphatically not appropriate for a pretty big surface area here. So will be interesting to see how this all evolves. I don't think it strikes a balance right now that can last.
     
  12. eizenhorn

    eizenhorn

    Joined:
    Oct 17, 2016
    Posts:
    2,683
    I’m also don’t like lambda pattern (even if codegen better) and forcing us to use it over IJobForEach, they inconvenient (for me), ugly looks and absolutely not readable, if I want declare logic above and schedule it all later at the end of OnUpdate in nice structured block - I can't (s**t) ForEach forces me use Schedule at the end, for me code less structured and become real mess, previously I have nice shiny system with required declarations and another file - with nice readable and structured jobs implementations and now all this become giant ugly monster system ALL-IN-ONE, all this inlining - ugly with all this .WithBlaBla.WithoutBlaBla.WithAnotherBlaBla.WithAgainAndAgain, code suggestions performance really bad (no matter VS/Rider, on hi-end hardware spec ryzen 9 3900x, 64Gb 3200Mhz RAM, M2 SSD, and it’s very annoying). We have IJobChunk at least. It’s first time I’m disappointed by decision Unity made about DOTS :(
     
    Last edited: Mar 15, 2020
    R0man, phobos2077, Vincenzo and 9 others like this.
  13. desertGhost_

    desertGhost_

    Joined:
    Apr 12, 2018
    Posts:
    259
    I spent a good portion of yesterday translating systems using IJobForEach to Lambdas (using SystemBase instead of JobComponentSystem).

    I agree that having repeated With[...] calls are not the cleanest looking and it feels messy, but I think that Lambdas are better overall due to there more direct display of intent. Whereas jobs require lots of boilerplate, the Lambdas basically state directly what I want the system to do. I really like HasComponent and GetComponent in SystemBase.

    Here are some issues I see with the current Lambda:
    1. Instead of having to use WithAll, WithNone, etc. a FromQuery function would be nice. I know there is a WithStoreEntityQueryInField function that stores the created query, but I want to be able to define the intent of query explicitly on create. This would allow the developer to explicitly define the query using GetEntityQuery and eliminate having a lot of With[...] functions.
    2. I think HasComponent and GetComponent in SystemBase are really convenient, but I find myself not able to use it very much. The problem is that I use a lot of static methods and many of these methods use a ComponentDataFromEntity and/or a BufferFromEntity. This means that I still have to explicitly define variables of these types in a SystemBase system.
     
    phobos2077, Orimay, Enzi and 2 others like this.
  14. Zec_

    Zec_

    Joined:
    Feb 9, 2017
    Posts:
    148
    I also was against the lambda syntax at first but have gotten over that and somewhat enjoy it for simpler jobs. The main thing that is annoying for me is that the codegen lambda alternative is not supported yet for Editor systems due to exceptions during compilation.

    error DC0032: Entities.ForEach Lambda expression exists in JobComponentSystem MyEditorSystem marked with ExecuteAlways.  This will result in a temporary exception being thrown during compilation, using it is not supported yet.  Please move this code out to a non-jobified ComponentSystem. This will be fixed in upcoming 19.3 releases.


    The only alternative for editor systems are thus IJobChunk. It's a bit annoying to have to convert all my editor systems with IJobChunk as the only alternative as it makes every single small job so large and bulky.

    I wish they would have fixed this first, before deprecating IJobForEach, as this means I'm likely to rewrite these systems twice, once now and once again when the actual codegen support arrives.
     
  15. desertGhost_

    desertGhost_

    Joined:
    Apr 12, 2018
    Posts:
    259
    You could always suppress the warnings on IJobForEach until the fix comes in or IJobForEach is removed (whichever comes first).
     
  16. Guedez

    Guedez

    Joined:
    Jun 1, 2012
    Posts:
    827
    I was about to ask about the subject. I really liked the clean IJobForEach
    I guess I will leave the ones I already have implemented like that for now.
    I don't see why it's being removed. Some new feature is being added that is not compatible with them?
     
    phobos2077 and Antypodish like this.
  17. MNNoxMortem

    MNNoxMortem

    Joined:
    Sep 11, 2016
    Posts:
    723
    I wholeheartly agree.
     
  18. snacktime

    snacktime

    Joined:
    Apr 15, 2013
    Posts:
    3,356
    You can abstract out the boilerplate with IJobForEach in a way that fits the context. Forcing Lambda plus builder takes that option away in favor of a lowest common denominator approach that smacks of something you might see in GameMaker. It makes for a fairly bullet proof api of course, approaches like this usually do. But it doesn't fit professionals who can generally do better then lowest common denominator given good tools.
     
  19. desertGhost_

    desertGhost_

    Joined:
    Apr 12, 2018
    Posts:
    259
    I don't necessarily think that IJobForEach should be deprecated, but I don't think that lambdas is targeted at the lowest common denominator and I certainly wouldn't compare it to GameMaker.

    Lambdas get more to the point and have more direct intent. Code with clearer, more direct intent is easier to read (even with those messy withs) and more maintainable. If the code gen creates better code than a human could most of the time and is more easily maintained, then there simply isn't any reason not to use it. Over time Unity could improve the code gen so that you will see extra performance benefits without having to rework any code.

    If the code gen approach isn't up to someone's standards, then IJobChunk would provide the most tools to do better.
     
    R0man, Orimay and NotaNaN like this.
  20. NotaNaN

    NotaNaN

    Joined:
    Dec 14, 2018
    Posts:
    325
    I'm with @desertGhost_ on this one.
    I personally find the Lambdas not to be a problem and actually prefer them due to less boilerplate. I especially love the new Has, Gets, and Sets that SystemBase provides for the new Lambdas, it's a really nice shorthand that gives you exactly what you want in any given scenario. Also, the warnings in the console are a really nice touch! They helped me get the new ForEaches working really quick. Originally, I thought I was going to have to trial and error for a little while and was pleasantly surprised to have them work the first time -- after I fixed my little mistakes.

    I understand the dislike against the removal of IJobForEach... I too liked the syntax, the options, and the feel of writing the code. But at the end of the day -- the new Lambda's are less boilerplate. Could they be improved? Totally. Right now, using the new Lambda's kinda feels arcane. I don't like how I don't know things! It's freaky. But I think we all came here to make games, and if the Lambda's make making games faster, then I'm all for it.

    Plus, who knows? Maybe Unity will let us have a little side package containing IJobForEach for those who want to use it? That'd be cool! :D
     
    R0man and Orimay like this.
  21. RoughSpaghetti3211

    RoughSpaghetti3211

    Joined:
    Aug 11, 2015
    Posts:
    1,697
    Could you elaborate on “the warnings in the console ”. I haven’t see this
     
  22. NotaNaN

    NotaNaN

    Joined:
    Dec 14, 2018
    Posts:
    325
    You know... The ones that appear in the Unity console if you do something wrong, such as forgetting to finish the ForEach with Run, Schedule, or ScheduleParallel? There's other messages too, but the only other one I have experienced was when I accidentally used ref with a managed IComponentData in the Lambda. It warned me to eject it, and I did.

    I thought it was neat. But I don't know how many warnings there are like this. Heck, there may have only been the two, and I was the lucky guy who did stuff wrong twice and Unity caught it.

    Thanks Unity console! :p

    Of course, I would have realized what I did was wrong after I ran the project. But it was useful not having to run it for it to tell me I messed up.
     
    Last edited: Mar 15, 2020
  23. Sarkahn

    Sarkahn

    Joined:
    Jan 9, 2013
    Posts:
    440
    Maybe I misunderstood you but there is no overhead for IJobChunk. It's pretty much as close as you can get to working directly on the data inside your chunks. IJobForEach was just kind of a weird middle ground between IJobChunk and the new Entities API.

    Personally I vastly prefer the new API. And IJobChunk is still there if you need to go low level. Not sure what the big deal is.
     
  24. RoughSpaghetti3211

    RoughSpaghetti3211

    Joined:
    Aug 11, 2015
    Posts:
    1,697
    I’m happy to use whatever API is supported.
     
    R0man, MNNoxMortem and NotaNaN like this.
  25. snacktime

    snacktime

    Joined:
    Apr 15, 2013
    Posts:
    3,356
    It's the exact same level of abstraction. Lambda/builder is currently just a wrapper around IJobForEach variants (and that those will go away doesn't change the abstraction level). The difference is the inlining and input handling.
     
    Orimay likes this.
  26. Sarkahn

    Sarkahn

    Joined:
    Jan 9, 2013
    Posts:
    440
    Ahh sorry, I had thought both IJFE and the Entities.ForEach both just got turned into IJobChunk during code gen.
     
  27. Antypodish

    Antypodish

    Joined:
    Apr 29, 2014
    Posts:
    10,753
    Sorry, I used wrong word, but I meant rather amount of typing, which was reduced significantly with introduction of IJobForeach.

    I just don't see a reason for its depreciation, if IJobChunk is here to stay.

    If someone wants use lambda approach let them be. But is just ugly way of doing things, so let us have IJobForeach too.
     
    Sarkahn likes this.
  28. optimise

    optimise

    Joined:
    Jan 22, 2014
    Posts:
    2,113
    I guess the main reason to remove it is to avoid multiple ways to do the same thing that will confuse a lot of newcomer and the cost to maintain multiple APIs that basically just do the same thing.
     
  29. davenirline

    davenirline

    Joined:
    Jul 7, 2010
    Posts:
    969
    I'm also voting for this. We're very used to creating an EntityQuery in OnCreate(). Everytime I look at a system, I just look at OnCreate() to see what components it chews on. I'm disappointed that it's not in SystemBase. Without explicitly setting a query, I keep getting mistakes of forgetting the filtering component in WithAll() or WithNone(). This makes some systems run on all entities instead of just a filtered partial number of them.
     
    phobos2077, jdtec and NotaNaN like this.
  30. Guedez

    Guedez

    Joined:
    Jun 1, 2012
    Posts:
    827
    I just want to hear form the devs a good reason to not keep both, then I will accept the deprecation
     
    phobos2077, NotaNaN and Antypodish like this.
  31. Joachim_Ante

    Joachim_Ante

    Unity Technologies

    Joined:
    Mar 16, 2005
    Posts:
    5,203
    There are a couple of reasons to begin deprecation of it:

    a) Too many options to choose from, it's important for us to make sure DOTS is easy to learn. Having too many ways of writing core loops is not helping that.
    We want to offer just two good ones. High level simplest & performant way to write code dealing with one entity at a time (Entities.ForEach) and low level API IJobChunk, giving you access to the data and the per chunk outer loop & explicit jobs.

    b) Supporting combinations of IJobForEach interface overloads was not possible. Entities.ForEach supports buffers, class components, shared component.


    Lets focus on the actual problems remaining in making Entities.ForEach better than IJobForEach in all cases.
    I am hearing

    1) When using lots of static methods I can't use GetComponent / SetComponent codegen nice'ness
    2) I had nice readable structured jobs in a seperate file and now i have to have everything inlined in one big function. (See post below)
    3) WithBlaBla.WithoutBlaBla.WithAnotherBlaBla.WithAgainAndAgain is lots of typing? Can we seperate them into WithQuery instead?
    4) code suggestions performance really bad (no matter VS/Rider, on hi-end hardware spec ryzen 9 3900x, 64Gb 3200Mhz RAM, M2 SSD, and it’s very annoying).
     
    R0man, phobos2077, fnuecke and 13 others like this.
  32. Joachim_Ante

    Joachim_Ante

    Unity Technologies

    Joined:
    Mar 16, 2005
    Posts:
    5,203
    One additional note. If you really like the structure that IJobForEach gives you, you can do the following. On top of Entities.ForEach. It's the exact same amount of boiler plate as Entities.ForEach and will give you the same performance. If you follow this approach, you can then also make easy choices where sometimes, having the extract struct & method is just too much boiler plate (Just like IJobForEach had too much boiler plate) and for simple code you can use simpler inlined Entities.ForEach

    Code (CSharp):
    1.  
    2. struct MyData
    3. {
    4.     float DeltaTime;
    5.  
    6.     public void Execute(ref Position position)
    7.     {
    8.         position += new float3(0, DeltaTime, 0);
    9.     }
    10. }
    11.  
    12. // Create data struct, it will be captured by the lambda method automatically
    13. var data = new MyData { DeltaTime = Time.Value };
    14. Entities.ForEach(ref Position pos)
    15. {
    16.     data.Execute(ref pos);  
    17. }.Schedule();
     
  33. NotaNaN

    NotaNaN

    Joined:
    Dec 14, 2018
    Posts:
    325
    Hey, Joachim!

    While you're talking about making Entities.ForEach better... Is there any plans on adding support for more components in the Lambda query? Currently (just like before with Entities.ForEach and with IJobForEach), only eight components are allowed to be iterated over. I have systems that get close to about twenty components and I was wondering if Entities.ForEach will ever support that many. Also, if it isn't going to support that many components, is there plans to make an API that does? Or will we have to resort to using IJobChunk (and just Chunk Iteration if the code cannot be jobbed)?
     
  34. Joachim_Ante

    Joachim_Ante

    Unity Technologies

    Joined:
    Mar 16, 2005
    Posts:
    5,203
    IJobChunk is a good choice when you have 20 parameters. Having a method with 20 parameters isn't meaningful anyway...
     
    phobos2077 and psuong like this.
  35. NotaNaN

    NotaNaN

    Joined:
    Dec 14, 2018
    Posts:
    325
    I suppose, but correct me if I'm wrong... Currently there isn't exactly any great way of iterating over a query that contains more than eight components if the code itself cannot be jobbed. IJobChunk works great for jobable code! So no complaints there. But manually Chunk-Iterating over twenty components with no codegen hurts my soul... Especially when I forget to write back to one of those components... Ugh.

    I understand not wishing to add anything though. ECS is going to become more and more jobable as we get more blittable, ECS-designed features. I can wait for those beautiful and liberating days if it makes your life easier. :p
     
  36. davenirline

    davenirline

    Joined:
    Jul 7, 2010
    Posts:
    969
    Manual chunk iteration still works (for blitable types). If it were up to me, though, processing 8 components or more seems like a code smell. Maybe it can be broken down to multiple systems instead.
     
    R0man and Orimay like this.
  37. eizenhorn

    eizenhorn

    Joined:
    Oct 17, 2016
    Posts:
    2,683
    Hi Joachim, thanks for response!
    1) +1. In real case you often use some extracted utility methods which can add/set components, and in this case, as you can see, codegen not so usable, because we pass ECB/EM/CDFE/BFE as before, btw I’m wrong or Set/Add not support Buffers?
    2) Thanks I figured out it yesterday and wrapped it same way.
    3) Explicit EQ usage for Entities.ForEach mentioned many times on forum, it’ll be very usable, for code readability, for good structure, IMO it’s just more convenient.
    4) Yesterday I rewrote ~50 IJFE/IJFEWE and laggy ForEach made me crazy :) even if I don’t need suggestion in some places, IDE just tried to help me and become laggy, and I disabled them after third job rewrite :)
     
    NotaNaN likes this.
  38. davenirline

    davenirline

    Joined:
    Jul 7, 2010
    Posts:
    969
    Hello Joachim,

    I'd like to add here support for generics as requested by some users (including me).

    https://forum.unity.com/threads/systembase-does-not-support-generic-types.847012/
    https://forum.unity.com/threads/support-for-generic-lambdas.847372/
     
  39. Srokaaa

    Srokaaa

    Joined:
    Sep 18, 2018
    Posts:
    169
    Are you using Rider? If so, I think this issue recently changed status from Blocked to Open so hopefully they'll start working on it soon:
    https://youtrack.jetbrains.com/issue/RIDER-36736

    Edit:
    Even better. Now it is in "Fixed in Branch" status
     
    Last edited: Mar 16, 2020
  40. mf_andreich

    mf_andreich

    Joined:
    Jul 7, 2017
    Posts:
    38
    For me its realy problem, because I made some base systems with generic components like

    Code (CSharp):
    1. public abstract class AttachSimpleAbilitySystem<TAbilityData, TAttachedData> : JobComponentSystem
    And after this I can just implement it with needed components and its just work. On first iteration I try ForEach aproach, but its not work. ForEach just cant work in open generics systems... I rewrite all on IJobForEach implementation and all work fine.
    Now I need rewrite a lot off base systems to chunk jobs... and after It can be deprecated and replaced with some api like Entities.ForEachChunk.
    Yes I understand reasons of deprecations. But its little bit strange... you deprecating something with cut opportunities.
     
    Sibz9000 likes this.
  41. andrew-lukasik

    andrew-lukasik

    Joined:
    Jan 31, 2013
    Posts:
    249
    Being fond of IJobForEach my first reaction to (JQuery-like) Entities.ForEach was negative too. But, after few hours practicing this new syntax I started to get hang of it and appreciate it.

    What's more this new Job.WithCode is super useful too; very easy to encapsulate computations in no time (after one understands limitations expressed by compiler logs tho). Also - besides all those burst+native jobs It enabled me to migrate code blocks from my Update() into Job.WithoutBurst+managed memory access+Run that I never even thought were a viable candidates for that before.
     
    Orimay likes this.
  42. LazyGameDevZA

    LazyGameDevZA

    Joined:
    Nov 10, 2016
    Posts:
    143
    This has now been fixed and should be available in the 2020.1 Rider beta.
     
    nicolasgramlich likes this.
  43. JesOb

    JesOb

    Joined:
    Sep 3, 2012
    Posts:
    1,105
    Can we write it shorter like this?

    Code (CSharp):
    1.  
    2. struct TweenPosJob
    3. {
    4.     float DeltaTime;
    5.  
    6.     public void Execute(ref Position position)
    7.     {
    8.         position += new float3(0, DeltaTime, 0);
    9.     }
    10. }
    11.  
    12. // Create data struct, it will be captured by the lambda method automatically
    13. var job = new TweenPosJob { DeltaTime = Time.Value };
    14. Entities.ForEach( job.Execute ).Schedule();
    15.  
    16. //may be even
    17. Entities.ForEach( new TweenPosJob{ DeltaTime = Time.Value }.Execute ).Schedule( );
    18.  
    19.  
     
  44. andrew-lukasik

    andrew-lukasik

    Joined:
    Jan 31, 2013
    Posts:
    249
    Structs can be helpful indeed but are not mandatory
    Code (CSharp):
    1. float dt = Time.DeltaTime;
    2. Entities.WithName( "my_translation_job" )
    3.     .WithAll<TranslateMe>()
    4.     .ForEach( (ref Translation translation) => translation.Value += new float3{ y=dt } )
    5.     .ScheduleParallel();
     
    Orimay and Nyanpas like this.
  45. JesOb

    JesOb

    Joined:
    Sep 3, 2012
    Posts:
    1,105
    Totally agree :)

    My sample is about Job Libray that can be reused in may systems and even placed on asset store for others.
    So we need good way to Schedule complete job structs on subset of entities :)
     
  46. JesOb

    JesOb

    Joined:
    Sep 3, 2012
    Posts:
    1,105
    So the question is:
    Can we schedule job not from Lambda Closure but from existing struct method may be static? @Joachim_Ante


    Code (CSharp):
    1. //like this
    2. Entities.ForEach( new TweenPosJob{ DeltaTime = Time.Value }.Execute ).Schedule( );
    3.  
    4. //or this
    5. Entities.WithAll<SomeTag>( ).ForEach( Tween.MoveForward ).Schedule( );
     
  47. NotaNaN

    NotaNaN

    Joined:
    Dec 14, 2018
    Posts:
    325
    For the record, it's meaningful to me! I have a proposition; what if we were allowed to have extra IN's (that is, components we were just reading from and not writing to)? Would that be reasonable, or would that be an equal amount of work as allowing for REF's? Also, is DynamicBuffer support the real problem? Currently, I don't think anyone (even me) is iterating over eight dynamic buffers, and I doubt anybody would do that in a situation where you couldn't use IJobChunk to good effect. Perhaps you could allow for more IComponentData's and not DynamicBuffers to Entities.ForEach? Would that be fine? :oops:

    Actually, the reason I require so much data (in the form of components) is due to me splitting things into many different systems. o_O

    Let's see how many components I get through... Tallied for your convenience.
    For example: I have a wall-jumping system that I made pretty robust. In order for it to function, it requires information on any and all nearby colliders in the left, right, and down directions. This is separated into three respective dynamic buffers made for this purpose (that are used in many other systems as well). (3 Components (technically DynamicBuffers))
    Jumping happens on key press, so I also need to pass in my InputData component. (4 Components)
    The actual jumping itself is quite robust, and sets three separate components to get my desired effects, which are a VariableJumpHeight Component, a GravityEnhance Component, and a JumpForceTimerData Component. (7 Components)
    Furthermore, since my game is 2D, I also wish to set my character's direction to face away from the wall on jump. This is handled in a Heading System which reads from a Heading Component, so I also need to pass that in. (8 Components)
    And sadly, right there we just hit eight components! Problem is... I need more!

    In order to query velocity changes, I have a VelocityBuffer component on my entity that is used to delay changes until a later, appropriate time. With just eight components, I don't have enough space to iterate over that. It gets worse from there though, because I also need the PhysicsVelocity if I want to prohibit the player from jumping if they are falling downward too quickly.
    I would continue on, as there are five other components I need that I suppose I could live without... But you get the point.
    :cool:
     
    Last edited: Mar 21, 2020
  48. brunocoimbra

    brunocoimbra

    Joined:
    Sep 2, 2015
    Posts:
    679
    Are you using all those components at the same time? I mean, wouldn't it be possible to break into smaller jobs and create dependencies between those? Having a giant job like that, dependant on so many different components like that, I can't even imagine the headache to maintain that later.
     
  49. NotaNaN

    NotaNaN

    Joined:
    Dec 14, 2018
    Posts:
    325
    Unfortunately, yes. :oops:

    It as actually quite broken up! (Which is the problem)
    The only thing the WallJumpingSystem does is make some changes on other components for other respective systems to handle. VariableJumpHeights, GravityEnhancing, and JumpForces are all handled and applied by their own respective systems at their own respective time. (They are also used by my GroundJumpingSystem and MidairJumpingSystem as well).
    The VelocityBuffer is obviously applied later near the end of the frame. The Heading is also applied later, too!
    You get the gist.
    The only way I could fit all of this into one ForEach is if I removed component-ization... In addition to ignoring the single-responsibility principle. Oh, and I forgot to mention that I need the actual WallJumpData to perform the wall jump (it controls all the variables, such as jump force and whatnot). :(
     
  50. davenirline

    davenirline

    Joined:
    Jul 7, 2010
    Posts:
    969
    In that case, then just bite the bullet and use IJobChunk or manual iteration. An Entities.ForEach() for that amount of components would still be complicated anyway.