What happened to OC? - CLOSED Carnage?!

RadWolfie

Member
  • Content count

    21
  • Joined

  • Last visited

  • Raffle Tickets

    0

Everything posted by RadWolfie

  1. EDIT: It is to remain as "Visual Basic" without "(.Net)" since there is no such thing to exclude .NET framework support in current version. Calling any Visual Basic developers to this topic. Others are welcome to provide feedback as well. Since there is VB6 and VB .NET, I'm not entirely sure if Microsoft planning on support Visual Basic without .NET framework. As there is a blog about Visual Basic 14/15 about it. So... Is it suitable to maintenance "VisualBasic" directory in the API's directory for .NET framework since Visual Studio 2015 does not provide an option to exclude .NET framework. Or it should be "VisualBasic.NET" for Visual Basic .NET application and "VisualBasic" for without .NET framework? I would like to have it ready in middle of January, 2017 for the future developers.
  2. I totally agree with multi-language support hassle. It took me almost 2 years to finally have full support for another language. At first I thought I understood the standard C API requirement, turns out it was C++ API which create a terrible result for another language. So, I already had worked for another language support since constant update to main project getting stabler. Even major fixes with unit test plugin made a major improvement and found numerous bugs on the way. Off topic: For those wishing why I'm making topics for another language support. Here's a link to testing branch I had been working on. Not bad for hobbyist coder huh?
  3. Already knew that, some people still uses it tho. Sorry I didn't mentioned it before. ... Turns out Visual Basic 14 is still using .Net framework. Here's the source of the blog: https://msdn.microsoft.com/en-us/magazine/dn890368.aspx And VB6 extensions support for Visual Studio 2012+: https://marketplace.visualstudio.com/items?itemName=MatthiasFriedrich.VisualBasicToolsforVisualStudio Turns out I had my mind mixed up with new VB 14 is newly updated version of VB6, I was wrong. I agreed. As for directory, if you have multi-language support, then you're likely to have all the coding in one bundle (in one directory). However it will create a mess inside just inside the "src" folder, so putting each coding language files in their respective language folder makes it cleaner and easier to update. So, I say keep "VisualBasic" folder for now. If someone asked for VB6 support, then "VisualBasicClassic" or the like will be created. Agreed?
  4. Okay, I finally have C# and Visual Basic (.NET) APIs to work and verified. Sadly there is no resolved button with this newer version. Here's the solution: Create an ini file Define the locations of where all the plugins' source code, build directory (basically inside the plugin's directory), and API's source code. Define the file extension names with standard defined pre-processor values such as... vb=#Const cs=#define cpp=#define etc... Create a converter application to... Read Defined version info structure (can be anything) Read API's central version info via h header file. Read each directory for lead to possible valid plugin. Scan each source code files for declared defined pre-processor values. Create some exception such as semicolon, white-space, tab space, etc for necessary compatibility between multi-code languages. Verify against compiled build file to match all requirement needed to convert into valid plugin via adding into plugin's module section header array. Copy converted plugin file into plugins folder. Profit! (Newer & older application will then read the converted plugin's section header to verify before attempt to load it. If it is not compatible, then it will state it is not compatible instead of instant crash.) If you have any questions relative to the steps above. I'm willing to answer them the best as I can. Edit: Clarified the last #3, Profit! (...), since I made a grammar loop...
  5. Hey guys, I need assistance with this super pain in the butt issue. These are what I have tried: #define / #Constant / enum / (+ one or two more unlisted) doesn't work with some / few program languages when needed to be used with multi-files during preprocessor compile time. C/C++ and D Lang works fine except for C# language (untested with VB except expected to be the same result). Having global defined in C# compiler is not a standard method to check if defined names exist or not. Using Dependency Walker method on imported functions work fine with C++ & D Lang except... C# doesn't have the Dllimport functions listed at all inside the module except for mscoree.dll file. Resource file will work for C++ (untested with D Lang) except for C# since it goes directly into .NET Resource folder. Custom VERSIONINFO structure will not work as expected for C#, untested for VB, C++ and D Lang will work just fine. C# compiler's custom assembly attribute works except it is not shown inside assembly's VERSIONINFO resource. I'm trying to have the standard method which is expect to work on all computer languages with fewer headaches to re-program search method for each program language expectation. Plus it must be read from file format, not runtime process for better security reason. Any advice how to resolve this issue besides using "#defined" method search in C#? I am willing to work with Dllimport functions if it is able to be shown in import directory section. Additional note: These are for Windows platform usage only and are using Microsoft Visual Studio's compilers. Edit: Currently in development & testing the API with C#. Will let ya'll know if it's a big successful once API is fully finished in C# and VB or F# as well. Discussion is still welcome. Edit2: It is NOT resolved at of this date, C#'s API is still in development... It take months to work on this, on my free time. Plus there's at least over 5,000 lines overall. Resolved, see post here:
  6. My car isn't high-tech feature everything in it. Plus Sony, for the phone, left out a few important features which cause couple conflicts as well. That is, until they released newer release to upgrade Android OS to have those features back. Haven't test it out since then, the result could be different. Although, may not for my car. As for hit "media" once, it doesn't work 100%. Sometimes it just forgets which then I had to manually set listen for Bluetooth. The car itself only has a few basic functions to control for audio playback, that's all.
  7. I second this, since I have to do this every time with Bluetooth instead of aux cable. I still use optical drive for any movie/game discs to be use on my PC quite often.
  8. Source: http://phasor.proboards.com/thread/421/bugfixed-multiclient-pc-any-version If the download link doesn't work, then might want to ask someone to download and give it to you in some way. I already confirmed the download link is working. The OP post does say the source code is included in the archive, if you didn't read it. Cheers
  9. I'll like some feedback from C# developers to determine which might be best to use. (Excluding partial C-99 standard for managed code.) Since struct cannot have a pointer on return value (even when it's nullable too). One alternate I discovered is doing this method: Which it should be able assist current and future developers to make an Add-on easier. Or in Class method: Both methods do compiled and able to process correctly when called the function. I do plan to add refresh & save function for easier to save the managed s_object back to unmanaged data. Even unmanaged to managed data as well. What do you think?
  10. Updated all function's codes. This should be final template example to demonstrate make it easier for developers use managed code. I'll give it a week for any feedback input before I mark it solve. Happy coding!
  11. I understood the term "hungarian notation". Yet, I don't really use their way 100%. Only for enumeration (e_xxxxx) and structure (s_xxxx), maybe class (c_xxxx) too, for time being. Why? It's easier to find than look in different files to find name of "something" for a struct or enumeration when performing a big project. getGenericData function's codes has been updated to be 100% fully functional to this date. Except, it still need rename to suit C#'s standard for naming managed code. Feedbacks are still welcome since it will be another 4 days until I can work on this again.
  12. Since you mention it, I'm actually following Halo's developer method for naming the structs. Since this is generic and if other C# developers do preferred PascalCase and camelCase methods, I'll update to meet C# developer's satisfaction for C# code on this topic. Currently my code is working correctly except it's about 80% identical to WIP struct. I'm hoping to get this WIP code 100% done before Sunday so I can mark it as solved. I really like this quote. Though, it feels like it should be this:
  13. s_objectPtr is just a wrapper. As I stated in post #3 to explain reason why IntPtr is inside of it. I'll provide some examples below. So is every single managed code languages existed with support of C standard. However, I had passed by several developers whose rather to code in C# for their conform level. Since Windows API (native ones) does work with managed code, I need to add support for managed code languages as well. public IntPtr getGenericData(uint uniqueId); public IntPtr getPlayerData(uint playerId); public IntPtr getIGraphic([MarshalAs(UnmanagedType.I1)] bool useExtendedVersion); public IntPtr getISound(); These above are just plain and simple functions return IntPtr with no class or struct it provides. Can you tell which class/struct even type of data it uses? No one can unless they go through a lot of reverse engineering process just to find what values it has. Instead of this way, below is more manageable and easier to code with wrapper(s) involvement. UPDATE: All codes are updated and verified. getGenericData function example: getPlayerData function example: getIGraphic function example: getISound function example: For User-defined conversion between structs, have a look at Microsoft's howto link here. From what I understand for class, base on several stackoverflow's site answers, managed code has the ability to choose where to put these values at any place it preferred to. Plus it is not possible to use Marshal.StructureToPtr function on a class type. So, for sure it will be using struct with wrappers to assist developer produce almost no-error development code for runtime processing.
  14. What I'm trying to do is make a functional managed code to work with a returned pointer for many different varieties of structure type. A pointer to a structure has so many values in it which you would see often in games and maybe heavy duty task usage. If I just put a IntPtr, then beginners of C# developers will constant ask me question, "What's the IntPtr is?". Plus a fail-safe to prevent coding the wrong structure type which can lead big confusion where it came from. This is why I use "s_objectPtr" in the code for return value, and another struct for managed data to handle the PtrToStructure function internally. Correct, if I use struct? or struct<Nullable>. These suppose to convert as reference/pointer instead of value type. Compiler will still complaint about this is not compatible Marshaling method. Even with custom marshal class as well.
  15. Are you saying... It's even possible to apply host-side velocity correction to client-side even for super jump cheat on? If so, why not reveal your research so others can implement easier in their builds?
  16. That's true for 32-bit operating system.(Tucker is right, whoops!) Some games, in 64-bit programs, now required at least 6GB of RAM available. For perfect example, 7 Days to Die. Instead of 8GB, I recommended 16GB+ of RAM for gamers, programmers, and some sort of tool engineering use. Windows OS (at least 7) plus other third-party system apps uses around 2GB of RAM.
  17. Big huge thumb up for this! I never thought this would be possible that soon. Plus big hype for custom robot build companion too! At least I had been looting robot parts from the start.
  18. Right and I do agree with you. Except there's a side-effect for newer build to include new interface. If a developer created a plugin to work with newer build of main app and the user want to run it on an older build of the main app which doesn't have this new interface. Then it either will hangs without a message box, unless you use ctrl+alt+del to get it output a message box, or output a message box for 1+ interface getter function is missing. One other thing, tchar isn't recommended as other language has default setup to include unicode defined constant and some don't. In fact, you can confuse the developers which char or wchar you are using. C#/.Net may be able to handle it internally, C++ doesn't. Therefore must be char or wchar for the interface or make 2 different functions such as: C++ class MyInterface { public: char[] getVersionA(); wchar_t[] getVersionW(); ... } I want to point this out; "class" is not a C standard. The substitute is "struct" since it is allow to have function pointers in it. Plus [ ] is not supported and must be substitute to * to meet C standard for function's return and parameter(s). Otherwise it will process quite different than you think it is doing in other language for perfect example D Lang. C struct ICustomInterface { void (*getVersionA)(char*); void (*getVersionW)(wchar_t*); }; Another reason for this is to prevent a dll be load as run-time module while being read for compatibility check and decide to either let or deny the plugin to be load from main app. (This process check the versioning data structure.)
  19. So far I'm performing a workaround by having C# developers use defined constants in main source code file for time being. This actually applied to all languages as well. For now I'm leaving this open until I have C# and VB fully functional with future interface provide. (It will take couple months to get final stage I think...) HINT: Current alpha test build can let you add file extension with different "defined constants" input in a configuration file so it can be add more support on the go without need to re-build the converter app. However if I change to check import* directory and include support .Net directory containing import* info for another dll file. Then I have to re-compile the converter app for different language if these languages do not contain the import* directory and/or .Net directory in the compiled dll file. I can remove the search for defined constants in main source code and allow developers to place it anywhere long as their code will work and able access to the interface which I state in previous post. And of course, converter app is not at final nor even left alpha stage yet. Once .Net directory search inside dll file are completed, it should support any .Net type such as C#, C++/CLR, VB, etc. Just, long as it follows the navigation in my second post. (IF this navigation is wrong for standard .Net usage for using import from another native dll, DO correct me.) I also need to perform obfuscate process for both C# and VB (not verified) to be sure the navigation has not changed or misled info. * When I say import, I'm talking about "defined constants" to open an interface class getter function from main app to plugin access. Q: Should I add pro & cons for going through this procedure? Edit: > Then, never ever change that detail of the interface, and use it to find out the version. Ugh, my brain is fried. That's something a very stable production would use. Except I'm not able to keep the older interface left unchanged, there's some parameters I had to add/edit through couple years. Oh well... Once it get to final release with only minor updates, it will apply for sure.
  20. > Converting from what to what? Hmm, thought I did post it. Guess not, a compiled dll file from any supported computer language to a custom dll file which use different file extension for better suited what it's for. The custom dll file will provide what main app needs to process if the versioning data match the requirement before it can be load. > These are all just text formats. I guess you mean you're supporting C++ and C#? Correct, for finding the defined constants to append the versioning structure data into converted plugin. (This may will change later on.) > Verification process? Central information converter? In my 2nd post and 2nd paragraph, this should explain reason for verification process. The converter just collects versioning data from main API source file and compare against compiled dll file with known source code used to compile it. If there's something incorrect or missing few things, then converter will output the error of what's needed to be include before able to use it in main app. > This explains things a little bit. Except that C# can't be compiled to a C-style dll, as far as I know. C# compiles to dlls in order to look friendly, but they are actually CLR bytecode. A C++ program can't import them without jumping through some pretty annoying hoops. Sorry if I mislead you for C-style dll from C# compiler. What I meant is C# support the C standard interface and variables such as C-89, C99, and so on. Here's the reference for "C programming language family". Not all languages listed can be compiled to dll format standard as Windows OS expect it to be. > Okay. I think you should really just provide an interface file that you expect developers to implement. You could release a .h file for C and C++ developers, and a C# interface class for C# developers. Then you don't need to scan source code at all. That's what I'm currently doing in C# interface translating from C "interface" I have tested with C++ and D. I know, it's not that easy to do. At least, it can tell me what I'm doing wrong for standard C's expectation other than fixed data. Unfortunately, I still have to scan the source code for versioning data requirement for time being. It may will change in future, hopefully. Nex, WaeV is pretty close to ideal of what I'm trying to do. And you're right; I even left out simple goal detail in the OP. Been busy correcting my grammar & adding more info. The goal for developers with their preferred language: Use defined constant for getting interface class from main app. (if a defined constant is not included in main source code or global, then compiler will output an error of "cannot find this interface class function getter".) Use a "form" to fill out to state what version, name, description, default configuration folder, etc inside the main source code. The goal for converter app: Get the defined constant from main source code to mark the versioning data structure. (may subject to change in future) Obtain the "form" from main source code and append into versioning data structure. (may subject to change in future, except still need the "form" in some type of text file storing it) Does this help? *fingercross* P.S. If you're going to suggest just provide the interface class and leave it to that. I can't, these interface classes has been revised few times which has lead to crash for no reason. It must have versioning to be included in order prevent older and newer to crash for absolutely no reason at all. Even Phasor has versioning requirement in lua script btw, same ideal just different and more depth versioning data.
  21. It has not been resolved 100% btw. What I'm trying to do is have a converter app look through one of main language extension such as .cs, .h, .c, .cpp, etc. Which then, find defined names to be match against verification process from a central information converter currently have. If a program can be compiled in module, dll format, with C standard expectation. Then, it will work with main program to be load in it as a plugin. In other word, I'm making an approval plugin conversion process for developers to make their own plugin to meet the requirement before they can use their plugin with main program. If they do not know a thing about meeting the requirement, then they will have hard time understanding why it will not load their plugin the first time and so on. Plus it needs to add a section to store plugin information and interfaces for another standard requirement too. After little more depth research, turns out .NET directory folder has internal DllImport stored. Where? Use CFF Explorer or relative program way to do so. Then look below for navigation to find it. .Net DirectoryMetaData Streams#~TablesModuleRef (Module file to link) ImplMap (Import Name to link) From there, ModuleRef & ImplMap info, I can see the module file name and import name which is being used by DllImport. (Do correct me if I'm wrong). If this is true, I may have time to implement this .NET method to use a dll scan process instead of file scan process. For now, CSharp developers still need to add local defines in a main file in order to detect correctly via converter app. However, custom values I needed to go with a compile file will not work as expected. This has to go through file scan process anyway. If you're wondering converter app is publicly released, it's not. Only alpha testers have access to this atm, it will be release later on with little to few updates in the process.