Export interface for external call

[TaranDahl]

Interoperability

Phobos has opened the external interfaces of some key components. If you are also developing your own engine extension and wish to use Phobos at the same time, please check out Interop.

[Copilot]

Pull request overview

Adds a small C ABI “Interop” surface to Phobos so other engine extensions can call into selected Phobos systems at runtime (DLL exports), along with documentation/changelog entries announcing the feature.

Changes:

• Introduces exported interop functions for TechnoExt::ConvertToType and AttachEffect attach/detach/transfer operations.
• Wires the new interop sources into the MSBuild project.
• Documents the new interoperability entry in README, Whats-New, and CREDITS.

Reviewed changes

Copilot reviewed 8 out of 8 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
src/Interop/TechnoExt.h	Declares exported ConvertToType_Phobos C ABI function.
src/Interop/TechnoExt.cpp	Implements the exported type-conversion wrapper.
src/Interop/AttachEffect.h	Declares exported C ABI functions for AttachEffect operations.
src/Interop/AttachEffect.cpp	Implements exported wrappers for attaching/detaching/transferring effects.
docs/Whats-New.md	Adds a changelog entry referencing the new interop feature.
README.md	Adds an “Interoperability” section pointing to src/Interop.
Phobos.vcxproj	Adds the new interop .cpp/.h files to the build.
CREDITS.md	Adds credit entry for the interop export feature.

[github-actions]

Nightly build for this pull request:

• compiled-dll-984b8ddf821e4983b5b283c060f406784e424123.zip
  These artifacts will expire in 90 days and will not be available for download after that time.

This comment is automatic and is meant to allow guests to get latest nightly builds for this pull request without registering. It is updated on every successful build.

[Metadorius]

I am not sure why all pointers are void*?

[ZivDero]

I am not sure why all pointers are void*?

My bet would be that to make it so that this does not depend on YRpp (in case someone is using their own implementation of YRpp, perhaps)

[TaranDahl]

I am not sure why all pointers are void*?

Copilot said that if I use TechnoClass*, it will break the P/Invoke compatibility. When calling in C#, I can't directly use IntPtr. I have to do type mapping, otherwise the call will fail.

[Metadorius]

Copilot said that if I use TechnoClass*, it will break the P/Invoke compatibility. When calling in C#, I can't directly use IntPtr. I have to do type mapping, otherwise the call will fail.

This sounds like AI hallucinations...

1. You can have unsafe methods in which you can do whatever like pointers etc
2. C# marshaller isn't as rigid as that usually

[TaranDahl]

Copilot said that if I use TechnoClass*, it will break the P/Invoke compatibility. When calling in C#, I can't directly use IntPtr. I have to do type mapping, otherwise the call will fail.

This sounds like AI hallucinations...

1. You can have unsafe methods in which you can do whatever like pointers etc
2. C# marshaller isn't as rigid as that usually

Changed

[phoboscn-bot]

To Chinese users:
This pull request has been mentioned on Phobos CN. There might be relevant details there:

致中文用户：
此拉取请求已在 Phobos CN 上被提及。那里可能有相关详细信息：

https://www.phoboscn.top/t/topic/229/1

[secsome]

Macros like PHOBOS_EXPORT and PHOBOS_DECL can make the code cleaner and such macros are widely used in most projects.
Just an example:

#define PHOBOS_DECL __stdcall
#define PHOBOS_EXPORT extern "C" __declspec(dllexport) 

[DeathFishAtEase]

If you are also developing your own engine extension and wish to use Phobos at the same time

Would it be more appropriate to move the Changelog entry of this PR to the Fixes / interactions with other extensions section?

[Copilot]

Pull request overview

Copilot reviewed 9 out of 9 changed files in this pull request and generated 3 comments.

[DeathFishAtEase]

A question: how is the Tested status of this PR determined, as there seems to be no one using another engine extension to try out the content of this PR or other testing information.

[TaranDahl]

A question: how is the Tested status of this PR determined, as there seems to be no one using another engine extension to try out the content of this PR or other testing information.

I tested the usability of the initial version myself using DP. However, the current version has not been tested yet.

[TaranDahl]

@secsome Could you help take a look at the newly added Callback things?

[TaranDahl]

@Metadorius API versioning done. Please check it out.

[Metadorius]

maybe we should always return something like HRESULT? PHOBOS_RESULT or something like this, with 0 for success and other ints for error codes

[TaranDahl]

maybe we should always return something like HRESULT? PHOBOS_RESULT or something like this, with 0 for success and other ints for error codes

Whose return are you referring to? The API function or the version getter?

[TaranDahl]

maybe we should always return something like HRESULT?

I doubt whether it is necessary to do so.
We are just a completely serial stupid video game with no access control or similar mechanisms. A single bool should suffice to answer most questions.
Also, we are completely open-sourced, developers can simply look into the source code and add logs.

[TaranDahl]

@ZivDero what do you think

[TaranDahl]

@Metadorius Please check the things about Copilot and Action.

[TaranDahl]

@ZivDero @secsome @Metadorius
Going to merge this tonight if no further instructions.

[ZivDero]

@ZivDero what do you think

I think an HRESULT-like thing wouldn't hurt. IMO the entire API is already overkill, but if it's happening, might as well future-proof it.

[TaranDahl]

@ZivDero what do you think

I think an HRESULT-like thing wouldn't hurt. IMO the entire API is already overkill, but if it's happening, might as well future-proof it.

Alright then. Should I return all return values via the buffer?

[ZivDero]

@ZivDero what do you think

I think an HRESULT-like thing wouldn't hurt. IMO the entire API is already overkill, but if it's happening, might as well future-proof it.

Alright then. Should I return all return values via the buffer?

Buffer? If you mean the new enum, then yeah.
Well, anything that's a bool or anything like that. Not any pointers, OFC.

[Metadorius]

Buffer? If you mean the new enum, then yeah. Well, anything that's a bool or anything like that. Not any pointers, OFC.

No, he meant that the real, non-status return value is passed using parameters by reference

[TaranDahl]

@ZivDero what do you think

I think an HRESULT-like thing wouldn't hurt. IMO the entire API is already overkill, but if it's happening, might as well future-proof it.

Alright then. Should I return all return values via the buffer?

Buffer? If you mean the new enum, then yeah. Well, anything that's a bool or anything like that. Not any pointers, OFC.

How to return other results without using a buffer?
C++ only supports a single return value.

[ZivDero]

Buffer? If you mean the new enum, then yeah. Well, anything that's a bool or anything like that. Not any pointers, OFC.

No, he meant that the real, non-status return value is passed using parameters by reference

Ah, in that sense... I guess then yeah.