Why are you wanting to use compiled languages in the first place?
Excellent question Oxide!
By using the complied languages, the following list offer big advantages over non-complied languages.
- Encoded into machine language, compiled language, offer stronger privacy and is unreadable to users. Reverse engineer users will take longer time to translate it back into specific language it was compiled from, in most cases they just give up.
- Shorter load time and ready to use. (Also depends on what kind of purpose you're using it for.)
- Offers variety of code optimization of your preference.
- Uses less memory. (Depends on your preference, like /MT if want to bundle everything in one dll file which do increase more memory.)
- No restriction of how you use it. (Example, PHP doesn't have support for DirectX interfaces and strictly limited excluding some additional require installation to use, like Perl.)
- At least ability to tell you the errors before it complied instead of crash often, usually due to incorrect standard rule and/or misspelled variables/functions.
- Compatible C native interfaces which expected to work with almost any C base language instead of limiting to one language only.
- Ability to create a extended interface for specific language required separate management in case if C native interfaces is not supported. (Such as Lua, PHP, JavaScript, etc.)
Last edited by RadWolfie; February 28th, 2014 at 01:09 PM. Reason: replaced method to rule
Do you realise that half of the mods on this forum (or Halo), such as HAC2, OpenSauce, Phasor, Gandanur, SAPP, etc. is all about reverse engineering Halo's machine code and adding new features or fixing bugs? How can you even make such extensions without basic knowledge of reverse engineering?Encoded into machine language, compiled language, offer stronger privacy and is unreadable to users. Reverse engineer users will take longer time to translate it back into specific language it was compiled from, in most cases they just give up.
Edit: Also, perhaps we should have told this to you some months/years ago, but C# has nothing to do with C/C++, and it's using managed code which is compiled into machine code at runtime.
Last edited by sehe; February 28th, 2014 at 03:23 PM.
More likely will be leaning to second option which is
Reason?
- Our executable file to append the eaoVersion into the add-on dll file, then convert to eao, file extension.
What is likely required to for it work?
- Less headache with individual complier compatibility and remove limited support of possible of each complier is able to do.
- At least ability to focus on one central executable file without need to check individually issues.
If any of you have complaint about this, please do calmly post your complaint. I will account the complaint ratio of this idea.
- Add-on Converter executable file must be inside the root directory which contains the Add-on API folder. (The library and every header files must be in this directory).
- Must be macro defined within one header or a main file (if not using a header file).
- Check the structure from Add-on API's eaoVersion against the macro defined within an add-on's header or main file. (The add-on does not require to include the eaoVersion during compile process.)
- Convert valid add-on dll into add-on eao file extension with eaoVersion header info. (Most likely in same folder where the add-on dll file was compiled in.)
- If there is a compatible support for a language which isn't listed, then please do post name of the language, attach the header and/or main file for it. We will append this check into the Add-on Converter's search list.
EDIT:
The conclusion of the discussion will be a custom executable add-on file we will supply to support the converting module (dll) into compatible add-on. The development for it will begin tomorrow.
Last edited by RadWolfie; March 7th, 2014 at 11:26 PM.
During the spring break, there was a conflict with other surprised planning. So, it had been delayed for another week (after spring break). After doing some researching and find out the method to have the potential way to have both converted add-on plugin and verification of the add-on as well. There is a way... Except it will required much more time to make some of functions & verifications as required base on the research in order have it to work properly. The eta for next release will be TBA since the load method development will take minimal 1-2 months and another month worth of testing.
Cheers,
DZS|All-In-One
EDIT:
We are only halfway completed the load system which may will need slight modification once we have start working on converting the compiled plugin into compatible add-on for H-Ext to load it. And of course... had some setbacks to re-fix the issues for different type of dlls that is supported by Windows' OS. Will create a new post once we have completed the load system plus finish the converter for it too. Hoping to have testing process be ready at beginning of June or the end of June.
Last edited by RadWolfie; May 9th, 2014 at 08:54 PM.
Updated to 0.5.2.3
I'll post the changelog there and here. Unless any of you have a complaint about this. Feel free to inform me via pm please.
As for additional news, we have moved the Halo branch onto another server which is able to serve average 3 seconds per page. No more average 10 seconds or more per page! Although, the bug tracker's issue page did take about 20 - 30 seconds to load... Now it only takes 5 seconds!
- Added: isfloatA/W, isdoubleA/W functions added to util namespace. NOTICE: This require an updated Add-on API.lib file for H-Ext 0.5.2.3 and newer.
- Added: EXTOnPlayerUpdate hook
- Added: EXTOnMapReset hook, only supported for Halo PC & CE version. Halo Trial does not have this. NOTICE: This does not hook to a "successfully reset" section, it only tells sv_map_reset has been executed.
- Changed: EXTOnPlayerAttemptDropObject hook, was EXTOnPlayerDropObject
- Fixed: Rcon message for client console does not appear. (Added another detection if player is local or remote.)
- Changed: Timer ticks changed 60 ticks to 30 ticks per second (using map ticks instead of game ticks) and excluded the requirement of needed to include map ticks.
- Previous checking for halo, and Open Sauce, commands were not 100% accurately due to limitation on commands matched. Now it fully include every commands.
- NOTICE: You will need to manually re-fix your commands.ini file! Please remove ANY of the non-characters such as +, -, <, =, etc under "[Halo]" section!
- Fixed: Halo's alias commands aren't 100% successful due to executing the alias instead of full command name.
- Fixed: Any non-characters excluding underline, dot, and numeric cause issue for iniFile class to insert fake section wrongful.
- Changed: Since noticeable for some hosting company could not restart due to quietly crash internally. By default it will not quietly crash. However, you can use a command to force quietly crash enable.
- Fixed: Login command through rcon cause crash.
- Fixed: First login success then cause second and on not to work due to overwriting other variables. NOTICE: This is a serious affect of how H-Ext handle the players!
- Fixed: Login through chat displayed the sensitive login info.
- Fixed: dynamicStack class of copying has one minor misused variable. NOTICE: This has a serious affect of how H-Ext and addons operate the ICIniFile class!
I was under the impression that Halo PC, CE, and Trial's master server browsers all went offline when Gamespy cut off support for them. I'm totally out of the loop on where Halo is in all that though. Have you guys (or somebody) come up with a fix for that?
The fix is to patch your Halo to 1.10, it is a official patch by the way. What it has is some bugfixes and change the master server from GameSpy to Bungie's base on Btcc22's master server code provided. Here's the link since it is hiding from dark corner of the Internet.
There are currently 1 users browsing this thread. (0 members and 1 guests)
Bookmarks