{"action":"opened","issue":{"url":"https://api.github.com/repos/skypjack/entt/issues/61","repository_url":"https://api.github.com/repos/skypjack/entt","labels_url":"https://api.github.com/repos/skypjack/entt/issues/61/labels{/name}","comments_url":"https://api.github.com/repos/skypjack/entt/issues/61/comments","events_url":"https://api.github.com/repos/skypjack/entt/issues/61/events","html_url":"https://github.com/skypjack/entt/issues/61","id":308566000,"number":61,"title":"EnTT and Unreal Engine 4","user":{"login":"mhaemmerle","id":116052,"avatar_url":"https://avatars2.githubusercontent.com/u/116052?v=4","gravatar_id":"","url":"https://api.github.com/users/mhaemmerle","html_url":"https://github.com/mhaemmerle","followers_url":"https://api.github.com/users/mhaemmerle/followers","following_url":"https://api.github.com/users/mhaemmerle/following{/other_user}","gists_url":"https://api.github.com/users/mhaemmerle/gists{/gist_id}","starred_url":"https://api.github.com/users/mhaemmerle/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mhaemmerle/subscriptions","organizations_url":"https://api.github.com/users/mhaemmerle/orgs","repos_url":"https://api.github.com/users/mhaemmerle/repos","events_url":"https://api.github.com/users/mhaemmerle/events{/privacy}","received_events_url":"https://api.github.com/users/mhaemmerle/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2018-03-26T13:12:09Z","updated_at":"2018-03-26T13:12:09Z","closed_at":null,"author_association":"NONE","body":"Hey,\r\n\r\nI've ported the EntitasCSharp/Unity3D [MatchOne ](https://github.com/sschmid/match-one) example to EnTT/Unreal Engine 4, which can be found here under [MatchOneEntt](https://github.com/mhaemmerle/MatchOneEntt). It's a really small example and I would love to get feedback whether the places using EnTT could be improved in an idiomatic way.\r\n\r\nIn general it is quite pleasant to work with EnTT, though I do miss some features coming from Entitas-CSharp. Things like reactive systems that get triggered when a component gets added/removed from an entity for example. Also that mutltiple reactive systems can react to the same \"event\". Or to be more precise, to the same group of collected entities.\r\n\r\nSee both [FallSystem](https://github.com/sschmid/Match-One/blob/master/Assets/Sources/Systems/Game/Systems/GameBoard/Systems/FallSystem.cs#L16) and [FillSystem ](https://github.com/sschmid/Match-One/blob/master/Assets/Sources/Systems/Game/Systems/GameBoard/Systems/FillSystem.cs#L16) reacting both to the same event and thus reducing the need for boilerplate code and components.\r\nI get why EnTT has been architected this way, but maybe there is some kind of (opt-in) middle ground to alleviate the need for boiler plate in case one needs this?\r\n\r\nAs a new user of EnTT I accidentally used assign instead of attach when working with tags and was wondering if a clearly separate API would help reduce these kind of (user) errors. Something like `addTag`, `removeTag`, `hasTag`, `replaceTag` ...\r\n\r\nWhat's especially confusing for me here is, that one mostly uses the regular API for Tags, but can't do that for replacing a tag(-component):\r\n```\r\nauto ScoreEntity = Registry.attachee<ScoreComponent>();\r\nauto Score = Registry.get<ScoreComponent>();\r\nRegistry.attach<ScoreComponent>(ScoreEntity, Score.Value + 1);\r\n```\r\nMaybe it's ok to update components without ever telling EnTT about it?\r\n\r\nWhen looking through `registry.hpp` there's lots of places describing undefined behaviour, e.g. when adding a component to an entity twice. The latter is clearly a user error (and sometimes hard to track), but one that I expect to happen from time to time. Wouldn't it make more sense to throw/assert by default there and not just in debug mode? So that users of EnTT have strict behaviour as a default and can opt-out if the need arises. Though to be honest I can't think of a reason why one would want a chance for undefined behaviour in the first place?\r\n\r\nThe last two things are related to Unreal Engine 4 in combination with EnTT:\r\nUE4 defines a macro named `ensure` and uses it in various places deep in the engine code, making it practically impossible to not have it included in some place of the user code (resulting in compiler errors). Do you see any chance of renaming ensure to something else? :)\r\nAlso when exporting the project, the UE4 build tool fails, because of the `noexcept` specifier and it's policy of disabled exception handling. That behaviour can hackishly be disabled for exported builds - but I think it's (UE4) in the same category as the undefined behaviour by default described above. Would it be possible to change EnTT so that the excpetion behaviour could be selected via a macro for example?\r\n\r\nThanks for EnTT and looking forward to your feedback :)"}}
{"actor":{"display_login":"mhaemmerle"}}