@DMGregory Ah, so no real rest for you...!

(Also, I ended up wiping and reinstalling Windows.)

Installing on top of the old one always worked out great for me, despite people insisting it's bad and you need to reformat the drive or something.

Well, not entirely always. Some viruses survive that process.

I have used the integrated "recovery" option, wiping all my stuff and reinstalling from the "internal" storate. Not sure if it formats then reinstalls, or just reinstalls and deletes all the craps that were not part of the install. Anyway, I had a "clean" setup after.

Well, as long as nothing relevant was lost that's fine too.

@Vaillancourt Yeah... it's been pretty intense. I haven't really had a day off in over a month. 😩

@DMGregory Might want to plan ahead and reserve one or to days off. Not having enough rest can cause major long term issues...

@nwp I don't think I lost anything relevant; we'll see in the months to come :P

The worst thing I lost was time I think...

I know you're trying to help, but that remark kind of implies that the reason I haven't had a break is a lack of planning, which I can assure you is not the case. 😉 I'm working ahead according to a plan for upcoming deliverables, it's just that there are so many of those that the plan occupies all my available working hours.

Oh, sorry if it looked that way, I don't imply the lack of planning. Just trying to warn about being overworked... I've seen things...

Just pour some Capri Sun on your Covid test

I know, I've been there. That's why I'm making a distinction between working hours and non-working hours. I haven't been able to take a full day off, but I'm making sure I'm only working a normal-ish number of hours each day, and taking time in the evenings to rest.

Ah, great!!

@nwp about the "click" stuff we talked about, I think what I need is some kind of plugin architecture that would let the thing do what it needs and be kind of self contained...

Hmm. Normally the tricky thing with plugins is allowing them access to things, but not too much. Since you can just use a lambda/std::function/function pointer that should be trivial. I don't see where the plugin part comes in.

Unless you mean it's to obfuscate the fact that you put code into components, then I guess "plugin architecture" solves the problem 🤡

I mean that eventually, I'll likely need to have the input interact in other ways. And by "plugin", yeah, maybe not "plugin" in terms of writing the code into a dll and loading the dll, but philosophically separating what the code does from the rest of the app. For now, yes, I can do this via a lambda.

I think the proper way is to encode the function as actual data. This assumes that you can somehow enumerate how an entity can react in some meaningful way. For example in an RTS you could say it's one of "select unit", "attack command" or "move command".

Yes, but where do you put the actual code?

The User can send an attack command from the mouse or from the keyboard, while the AI player issues those commands from it's AI process.

In this case you would have a "unit actions" system that iterates through all units and does the attacking or moving. Being selected doesn't require anything to be done in that system, only the display system and maybe other inputs care about that.

Yes, so at some point, the interfacing between the "input" and the "ECS" has to be kind of centralized.

It does? I assume the player can click, there is a function get_unit_under_mouse_cursor(), then another command/click using get_currently_selected_unit().

This would all be implemented without systems and directly set component states which later systems react to.

I think this is all using the ECS properly, no trickery or uncleanliness.

Hmm, okay, well if you assume that a System is strictly something that acts upon actual components, then yes, no system needs to be involved there. There is still needs something that will link the UI/Input events to Entities/Components so that eventually System can act up components.

That link would just be the UI/Input code directly modifying Entities/Components.

Yes.

That "link" is not so trivial, it needs to know about the scene graph, how the scene graph objects are linked to their parent component, and their parent entity.

That shouldn't be the case. Why does it need that? To implement get_unit_under_mouse_cursor?

Yes.

I'd put that implementation in some utility file outside of the input code and consider the input code not needing to know about scene graphs.

I feel like it's a bit non-technical since it really doesn't matter where that function is and the input code is likely the only one to want to know the entity under cursor, but grouping scene graph code together while keeping input code elsewhere still makes sense to me.

Well I can split the "mouseClick" concept from the "mouseClick coordinates", but at some point, this "click" will need to be converted to a "ray" so that I can ask the RenderingEngine "what model is under that ray"

I'd put that in the render engine. The input code really only has X/Y coordinates. To make a ray you need the camera position and orientation which the input code doesn't know about. So I'd say add a convenience function to the render engine.

Yes, it's already there. So the "link" that you mention needs to 1) get those 2d screen coordinates, get the object(s) under the mouse by asking the rendering engine, then 2) mark this/those object(s) as selected through their components.

That could be 2 functions, the second one allowing other "things" to mark Entities as selected.

(and the first one simply converting "ui" stuff to "info about Entities")

It could almost be a 1-liner. render_engine.get_model(x, y).get<Selection_state>() = Selection_state::selected;

Of course nullpointer checks ruin it.

And you still need currently_selected_model.get<Selection_state>() = Selection_state::unselected;, preferably before the previous line.

Maybe you didn't mean to make it sound like a lot of code, but it reads to me as if you did.

Oh, it's "simple" code using our infrastructure :P We use a 3rdparty rendering engine, and so the "ray" returns a bunch of nodes, I need to pick the "closest" node, then inspect the "custom pointer" to see if it has something and if it is something that belong to us; if it's not, then I have to check the 3d node ancestors until I find such a node. Then I'll know it's a ComponentGfx, I'll get the owning Entity, then I'll get the "top level" entity and add a ComponentSelected to it.

It's simple. But the code is at least a few lines.

That sounds like it should be extracted to a utility helper.

It should also make testing easier.

Bah, the function will be the utility helper.

Testing?

Waste of development time 🤡

I add cout to make sure "it works" as I intend.

I never did anything with raycasting. It seems so simple in concept yet fancy.

Picking objects (I mean, telling me what's under the mouse pointer) is the fanciest I did. And I offloaded the work to the rendering engine :P

Even creating a ray might not be that trivial, depending on the "lens" of the camera. It would be infuriating if you get it slightly wrong.

Though I guess perspectives for game cameras are intentionally made to make such computations relatively easy.

Something about straight lines staying straight no matter how you look at it.

I would say that the matrices that are used to do the projection and such can be used to position the ray correctly.

With our infrastructure, the hardest part was to find the right coordinates to use and the right "ray picking" function offered by the engine to use.

Well, I was told nobody ever does matrix inversion, too slow and usually avoidable. It sounds like you need it in this case.

/shrug, I don't know how it's done under the hood.

Now the next step is to figure out how I can select more than one object through click+drag.. :P But I don't need it now.

Ah yes, "rectcasting".

"Cuboidcasting" I guess

I forgot you can have multiple things selected.

Yeah, I need only one now, but if I'm going to add more editing features in there, I'll eventually need that. Or implement a shift+click..

Shift-click is easier, that doesn't require cuboidcasting.

I'll check that when I get there...

I think usually they calculate a center point and then check for each thing (maybe with an octree) if the center point is in the cuboid.

I should become an architect too.

Only talking about the high-level stuff and not getting smacked down by reality drowning you in details is nice.

Ah, well if you get into a small team, you need to be the architect and have to deal with your own bad designs :P

I'll just blame people's poor execution of my grand design 😎

:P

(The 3rdparty rendering engine offers a "polytopeIntersctor", so I suppose I'll be able to use this to find click-drag objects.)