Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

.Net Framework Compatible Package #83

Open
TylerDelmus opened this issue Aug 23, 2021 · 6 comments
Open

.Net Framework Compatible Package #83

TylerDelmus opened this issue Aug 23, 2021 · 6 comments

Comments

@TylerDelmus
Copy link

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
Copy link

lewiji commented Nov 26, 2021

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
Copy link
Collaborator

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
Copy link

lewiji commented Mar 17, 2022

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

@eelstork
Copy link
Collaborator

@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
Copy link
Collaborator

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

@lewiji
Copy link

lewiji commented Mar 21, 2022

@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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants