search

active-logic / activelogic-cs

Behavior Trees and Case Logic for C#7
GNU Affero General Public License v3.0
106 stars 7 forks source link

.Net Framework Compatible Package #83

Open TylerDelmus opened 3 years ago

TylerDelmus commented 3 years ago

I have a project I'd love to use this library on and for reasons I'm limited to .Net Framework only. Would it be possible to get a .Net framework compatible package on Nuget?

lewiji commented 2 years ago

I've taken the naive approach here (not a .NET expert) and changed the Src/main.csproj target framework to net472, and subsequently fixed the few errors flagged up by the compiler. So far, I've implemented a couple of basic trees for my Godot project which targets net472 explicitly and they work perfectly. So the basics seem to work, unsure yet about the more advanced features, or if activelogic-cs is using specific netcoreapp2.0 API features. You can test it out here however:

https://github.com/lewiji/activelogic-cs

e.g. by cloning the repo, building the main.csproj project, copying the resulting binaries (e.g. Release/main.dll) into your target project, and linking them as a reference to the project (in Rider, right click project in solution tree, Add -> Add Reference).

eelstork commented 2 years ago

Sorry for the late reply; this is mostly .NET compatible with the Unity API calls fenced off. The test suite runs over .NET. Limitations/issues are probably me not understanding in what context this is being integrated as I personally tend to use it with Unity. Nuget package can do if desired. Replies are slow cause work is so busy sorry.

lewiji commented 2 years ago

I've been using the above fork with Godot engine without issue so far, for context

eelstork commented 2 years ago

@lewiji would a Nuget package help at all with the Godot integration? Other than that I see no reason to not test changes from your fork and merge some! We're using AL a lot at work but as a user I've had much less success with the more stateful features of the library; are they broken? Not to my knowledge. But like similarly more stateful BT approaches, I find them somewhat error prone and get more work done keeping state explicit when state needs to be involved (I'm hoping to clarify what I mean in a refreshed introduction)

eelstork commented 2 years ago

A Nuget package did already exist - https://www.nuget.org/packages/ActiveLogic/ @TylerDelmus see if this resolves your issue?

lewiji commented 2 years ago

@lewiji would a Nuget package help at all with the Godot integration? Other than that I see no reason to not test changes from your fork and merge some!

Personally I'm happy just linking to the library via a filesystem reference, but I'm a solo dev and my C# experience is pretty much limited to Godot scripting the last 2-3 years (haven't used C# outside of that over my 12 years as a swe). So I don't know what the best practice/correct/desired thing is for dedicated .NET programmers who use godot :)

(and fwiw in case this was your question: initially I tried using the nuget package, but it wasn't compatible and couldn't be used, which is why I investigated and forked)

Something worth noting, is Godot will soon(tm) be migrating from Mono, over to targeting dotnet 6 CLR, work is underway and I think almost complete, so I'm not sure how that affects things in terms of the targets of dependent packages. I'm working on getting a dotnet 6 fork of godot working on my machine with some other godot devs, so will test that out, it may well just work with the standard AL library target. This is for godot 4, which is currently in early alpha and probably won't be stable until late this year, possibly the dotnet 6 changes might run over longer, and godot 3 will still be supported for a long time. So there's a bit of a question mark there around framework targets that I'm not sure of.

We're using AL a lot at work but as a user I've had much less success with the more stateful features of the library; are they broken? Not to my knowledge. But like similarly more stateful BT approaches, I find them somewhat error prone and get more work done keeping state explicit when state needs to be involved (I'm hoping to clarify what I mean in a refreshed introduction)

Yeah, I think I follow you and I tend to just avoid doing that stuff inside BTs anyway; I have some internal state to individual trees that seems to work fine, but it's nothing complicated. But I don't really do anything like pulling state out of the BT into a game entity, or doing conditional logic from outside of the BT based on the BT state. It's something I haven't really found a need for, so haven't tested it out much. But more docs explaining those features may inspire some use where I've done things in a less flexible way because I wasn't aware of the feature set around this!