H-Ext (Halo Extension), Support for Trial, PC, and CE! Both client and dedi!

Quote:

---

Originally Posted by coolest2guy

GitHub has no limited to contributors per application code whilst BitBucket do have limitation of 5 users (aka contributors) for each application's source code. Therefore give a GitHub +1 reason to have. However GitHub's private service demand to be paid per monthly. But we do not need any of private service since our H-Ext is close source and easy to maintaince ourselves. GitHub do have similarilty to Atlassian's Confluence, even Google Code has this too. Also GitHub do have direct compatability and feature (similar with JIRA) with many third-party supports.

Our decision summarize into this expectation. First, the Add-on API's source code is need to be public. Secondly, in case of having more than 5 contributors (if any) to continously update the halo structure and other purposes would be better than 5 or less contributors. Third, we do not need any private service even if it's optional feature for free. Finally, H-Ext is basically provide the interface for the plugins to use whilst staying as barebone system*. So the conclusion would be GitHub.

We have Bug Genie software installed which is pretty much identical to JIRA. Although, the software is quite slower than our Halo's site. The plan is to migrate everything into our site v2 without the necessary to create different accounts for each software we have, more secure security, use only necessary resources to load a page, etc.

Remember, not every provider has your every needs can be hard to find and each do have limitation for free.



*this mean the plugins will be required to be loaded to serve your propose expectation such as role-play commands, extend gametypes, remote access, and so on.

---

Oh for what you intend to use it for GitHub will do a marvelous job, it seems the key feature you want is easy access to outsiders who can contribute, which would be GitHub as it houses a lot more users and is more open.

I just felt you were saying that Bitbucket wasnt on par, so thought I'd defend it :)

And you have the right to defend it. ;)

(off topic)
We are aware of Atlassian offered Minecraft dev team to use their product for specifically JIRA's ticket system. This does help the team to summarize how many users are reporting actual issue instead of inaccurate issue(s).

Out of curiosity, are you still developing this?
I am wanting to develop with C# but that is made very difficult because of the lack of managed code, but you claim to support C# (or are going to in the future). I basically have to rewrite the whole add-on API in C# to use any of it. I assume this would be the case with any other .NET language as well.

Yes it is still under development, right now it's not compatiable with C#'s import/export interfaces and still looking for a fix. I will need to create the .cs files for it able to use C# instead of other developers required to make their own add-on API transition (if this is the right word for it...) from C header to C#. The problem is... it will require to be unmanaged C# instead of managed C#. Eventually some time later, the interfaces of requirement will be readjusted to accept the unmanaged exports from C#'s DLL.

Wondering what's going on with the current development? Well the following listed is already implement for 0.5.2.2:

• Added Timer system
• Major changes to the command function (readjusted for general timer system supportive).
• Will be updated to Add-on API 3.2
• Fixed the IObject's Create function
• Fixed the red/blue team from obtaining the player list prefix
• And some other things I can't remember...

Edit: My apology, I meant what's ALREADY included in the future release of 0.5.2.2. What we're not sure about... what should be included in 0.5.2.2's features. If C# fully support is a must, then we may have the time to research what is possible and not possible with "Unmanaged Exports (DllExport for .Net)" which do required NuGet installed for Visual Studio 2012 or higher.

Halo is entirely 32bit, so you would be better off creating a C++/clr wrapper library instead creating even more overhead with Interop and increasing code complexity with duplicating structures in pure C#.

I am not sure what you mean by "increasing code complexity with duplicating structures", Kornman00. Could you possible explain slightly more deep about this?

I am still having issues with DllExport (unofficial third-party plugin for C#, created by Robert Giesecke) to export the variable (not exporting a function) for verify a variable's structure before proceed to load an (read-only) add-on into functional add-on to use with the compatible H-Ext. I thought about the DllImport and how exactly it suppose to work with. So I tried this method:

Code:

---

[DllImport("Test.dll")]
public bool testInt;

---

It returns exactly the same message from DllExport's error: "Attribute 'DllImport' is not valid on this declaration type. It is only valid on 'method' declarations." I have googled up any solution for this and only found suggestive to use the functions which I cannot use at all if I'm going to use a read-only exported variable to make verification before load the compatible add-on. If there is no chance at all to have import/export variable to be supportive in C#, then it's likely C# add-on type will be out of the picture.

One part of the reason I would like to have C# supportive is MySQL Database. So it can be build in C# to use without additional installion requirement while C++ version does. However, C++ can be used as an optional build instead.

If no one is able to suggest a fix, including the working sample code, for the C#'s import/export a variable, then I will substitute more general compatible C native to experimental client-server network communication into H-Ext 0.5.2.2. However the experimental client-server network communication will take slightly longer than making a C# supportive with H-Ext's interfaces including a variable structure requirement.

His DllExport is just like DllImport, in that it only supports methods. You can't use it on anything other than a method, which is why it fails to compile. So what you're trying to do isn't possible. You would have to use an exported method for get/set.

And by increased code complexity, I'm talking about writing a C# wrapper for your native C++ extension. Eg, any structures used in the C++ APIs would have to be redefined in C# and appropriately annotated with interop attributes. And C++/cli tends to have better performance than doing P/Invoke via DllImport and marshaling, unless you use SuppressUnmanagedCodeSecurityAttribute, but that too shouldn't be used willy nilly.

"You would have to use an exported method for get/set." By this you mean:

Code:

---

public bool testBool { get; set; }

---

either above or below,

Code:

---

private int testBoolA;
public int testBoolB
{
  get
    {
      return testBoolA;
  }
    set
    {
      testBoolA = value;
  }
}

---

or you actually meant this below? (Can't really use this method as I explained in previous post, just informing.)

Code:

---

private int testBool;
public int getTestBool()
{
  return testBool;
}
public int setTestBool(int setValue){
  testBool = setValue;
}

---

H-Ext is mostly written in C native along with some C++ template needs without needing to write individual classes per se. And yes, it required SuppressUnmanagedCodeSecurityAttribute since C# doesn't like the structures I provided.

The first thing you posted is a property, which is an amalgamation of two specialized methods for get/setting. Behind the scenes a property really translates into two methods: "get_testBoolB" and "set_testBoolB".

The DllImport concept can only be applied to literal methods, not properties. So yes, you would have to use the individual methods like in the last code block of your post.

That's what I was concerned about... I have thought of another solution for this problem, the two options I could think of are..

• Create a eaoVersion file to be included in a project (aka embedded into the add-on dll file, also will need to rename the dll to eao as file extension).
• Our executable file to append the eaoVersion into the add-on dll file, then convert to eao, file extension.

If anyone have any suggestions other than listed above, please do reply here. March 7th, 2014 will be the deadline decision of which method will be used as replacement. We will keep the deprecated of dllexport version of the EXTOnPluginInfo function until 0.6.0.0 is in development, then we will recommend to replace the dllexport version to the options we have determined to use. This also include the community's suggestions which may be seems more suitable than our options idea.

After March 7th, 2014, we will start working on this compatible issue with C Sharp (C#) and Visual Basic (VB) to be supportive. Have other programming language(s) suggestion which does support complied as module (dll) and support C base interfaces? Please do let us know. We may try the basic interfaces with the programming languages other than C++, C#, and VB to see if it works correctly. If needed, we will do our best to make the necessary script files to support it. Such as C# required .cs files, C++ requires .h and/or .hpp header files, and so on.

The experamental network communication is delayed until this issue is resolve.