SolarStrike Software

Posted: **Fri Nov 21, 2014 10:24 am**

Okay after some break and 2-3 weeks before trying to compile MM2 with MinGW/or TDM.(what not worked was ncurses which windows support is marked as experimental) I decided to rewrite it so that it works with native Microsoft windows c++ only audio support and ncurse replacement will take some time..

The only thing which is left out beside those other is

Some argument not fit with the windows function version. I could change the arguments but it seems original await int as result but std::isspace returns bool (http://msdn.microsoft.com/de-de/library/x9wa4512.aspx).

With that many (,) I can't see through the jungle

Posted: **Fri Nov 21, 2014 11:06 am**

It's complaining that the argument list doesn't match the function, but ptr_fun() only has one argument by standard definition.

VisualStudio is another broken Microsoft compiler that fails to follow standards. As such, I couldn't tell you what you need to do to fix it without just completely changing those two lines. All that function needs to do is to strip whitespace characters (space, tab, newline, non-printable characters) from the beginning or end of a string.

Posted: **Fri Nov 21, 2014 11:48 am**

Administrator wrote:It's complaining that the argument list doesn't match the function, but ptr_fun() only has one argument by standard definition.

VisualStudio is another broken Microsoft compiler that fails to follow standards. As such, I couldn't tell you what you need to do to fix it without just completely changing those two lines. All that function needs to do is to strip whitespace characters (space, tab, newline, non-printable characters) from the beginning or end of a string.

This is nothing ....... the first thing you will notice when you drop your code into VS is that every system-call awaits a different type and none of them is a char. I was able to turn on a legacy mode partially I can understand why but MS didn't just use wchar_t they use 4-5 different types the whole save transformation thing between them(and possible char) will turn you nuts.....the day you need it.(one day when Lua support only UTF-16+

)

One last small question you use ncurse for making the console windows or do I see it wrong? I need that because how I approche the windows thing because Windows::Form doesn't like me

QT is the next way to try.

Posted: **Fri Nov 21, 2014 12:04 pm**

You can actually just compile it completely without Ncurses. You'll have to strip a lot of code out from various files, but it shouldn't be too difficult. Just remove the Ncurses stuff from main, luaengine, and luatypes.

The Ncurses code is not requires to create a console window, but it instead just gives a lot more options and control over the console in Ncurses mode.

Posted: **Sat Nov 22, 2014 4:29 am**

Administrator wrote:You can actually just compile it completely without Ncurses. You'll have to strip a lot of code out from various files, but it shouldn't be too difficult. Just remove the Ncurses stuff from main, luaengine, and luatypes.

The Ncurses code is not requires to create a console window, but it instead just gives a lot more options and control over the console in Ncurses mode.

WOW I got for the first time the code complied. MM open an CMD console which wants to close immediately again. I don't know why perhaps it need admin right or the dirent.h/.c I use doesn't work like expected.

EDIT: I need still testing but the console seems to work now.

Posted: **Sat Nov 22, 2014 10:13 am**

That is pretty odd. Compile it with debug symbols and maybe you can get more info. I can only assume it is segfaulting somewhere, or maybe some serious error is encountered and it shuts down right away. Do you have any log entries?

Posted: **Sat Nov 22, 2014 11:31 am**

The first problem was I needed to change the project setting to make it a console application. The only thing which still doesn't work is using the debug mode from VS. I assume that using the memory altering code while this is watched by memory altering code through course some sort of short circuit in the memory logic

Posted: **Sun Nov 23, 2014 6:07 am**

Since I'm under way through Admins code I thought why not :
It is still only a prototype but I wrote a map extension for MM2 like this:

Code: Select all

map.set("VarName", myValue)
local value = map.get("VarName");

I had the idea previously because I needed it for Lua Lanes so it also thread save the only thing which I'm not sure about are tables because there is only a lua_pushlightuserdata() for stuff like that pushing coroutines I don't support at the moment.

Posted: **Sun Nov 23, 2014 12:31 pm**

Very cool. I'm working on some networking code now that makes quite a bit of use of threading, and that will hopefully be ready soon. You might be interested in checking that out.

Did you find my code to be easy to work through and expand upon? One of the main goals with MM2 was to allow things to be added in easily.

Posted: **Sun Nov 23, 2014 1:09 pm**

Administrator wrote:Very cool. I'm working on some networking code now that makes quite a bit of use of threading, and that will hopefully be ready soon. You might be interested in checking that out.

Did you find my code to be easy to work through and expand upon? One of the main goals with MM2 was to allow things to be added in easily.

It was very easy just copy the pattern and but into the register. Yeah I will check it out .....
I should say one last word about what I'm sure will cause problems, things like

Code: Select all

mytable = {"wwer",324,43}
map.set("mytable",mytable}

Will cause sometimes problems because it is only a pointer which is stored that is problem because the gc will delete the table when no reference on the LUA side pointing on it any more. All other things will survive until MM is closed or a map.clear() call is made.

Posted: **Mon Nov 24, 2014 11:44 am**

Okay I got the 64-bit version also running after some bug solving
3 small bug I came across in "int MemoryChunk_lua::getData(lua_State *L)",
you push float and double as integer and in "int Bit32_lua::lShift(lua_State *L)" seems unfinished.

Anyway lua 5.3 has bit operator in it's language design and also int64 by default.

Is there anything to consider through I'm 64-bit for the memory reading?

Posted: **Mon Nov 24, 2014 1:36 pm**

BlubBlab wrote:Okay I got the 64-bit version also running after some bug solving
3 small bug I came across in "int MemoryChunk_lua::getData(lua_State *L)",
you push float and double as integer

Yup. I originally had those correct, but then I went through and started changing up some of the pushintegers to pushunsigned, and then had to revert some of them, and I think this somehow got caught up in that. I've just corrected it and I'll be in my next commit, but I'm getting some really odd errors with the experimental code I'm working on.

in "int Bit32_lua::lShift(lua_State *L)" seems unfinished.

I think you've got some really old code. The Git repository has much newer stuff. That whole class was stripped out a long time ago in favor of the module included in Lua 5.2.

Anyway lua 5.3 has bit operator in it's language design and also int64 by default.
Is there anything to consider through I'm 64-bit for the memory reading?

I'll probably upgrade it to 5.3 soon, but I think I should finish what I'm working on before adding any more variables to the mix. You might need to be careful with the memory read functions as they might still use 32-bit pointers in some locations. I haven't gotten to the point of compiling it as 64-bit, so I have done absolutely no testing to see if it would work properly.

Posted: **Mon Nov 24, 2014 3:19 pm**

Lua 5.2 64 bit and lua 5.3 have like I said 64-bit support means the define a own type of integer: lua_integer and when you compile with 64 - bit system calls which had returned unsigned long return now size_t (unsigned long long). I think a marco which check for what we want to compile would be helpful. This is what you need to know if you want to compile for 64-bit.

I kinda said it too but with Lua 5.3 the 32bit-bit functions are gone they are now all part of the language some other math features are gone too because you can than write x^y or x^2 and. atan and atan2 are one function than.

To be true I'm not 100% sure this is a step forwards but I think a release candidate will be out soon.

Okay now I go merging those old and new scripts.

Posted: **Mon Nov 24, 2014 3:57 pm**

BlubBlab wrote:Lua 5.2 64 bit and lua 5.3 have like I said 64-bit support means the define a own type of integer: lua_integer and when you compile with 64 - bit system calls which had returned unsigned long return now size_t (unsigned long long). I think a marco which check for what we want to compile would be helpful. This is what you need to know if you want to compile for 64-bit.

That may be, but Process_lua::read(), Process_lua::readMemory(), and others all currently are using the int data type for addresses. At the very least, those would need to be changed to ensure that they can hold 64-bit integers on all compilers. I'm not entirely sure how well (if at all) ReadProcessMemory() works to thunk a 64-bit process, so that could require some major changes.

Posted: **Tue Nov 25, 2014 4:26 am**

Yeah that was what I meant with something to consider the addresses must support all u64-bit. I will look into it. The different between your newest code on google code and what I have is only the 32-bit.lua seems it only dropped into the zip file.

I thought about what module I could create else than a thread safe map. First I thought what else I could do with thread in the end the answer was nothing because everything else will only cause trouble.

I'm thinking about creating a module which will give you through openCV the possibility to finding lines, cycles, corners, 3d cubes/lines dynamically in your client.( I won't start before next week with it). I must add you can do stuff like that only when you char stay still it take a lot of memory and cpu power. I think it could be interesting when you seek a NPC menu and want/need to click manuel.

EDIT: I kinda found a problem I found a 64-bit macro in stdint.h uint64_t and int64_t, the problem I have the addresses are in a 64-bit format which you needed behind 4 gigabyte but the compilers made (like I know through DP) the pointer 32-bit because you can addresses when they are 4 byte aligned up to 16 gigabyte. I'm not 100% but there are some cases in readPtr when you gave the pointer the original address and also the output seems to be only a unsigned int(reading an unsigned int* 4 is okay but the output must be also uint64_t). I think I need to remodel that function.

EDIT2: seems I have found a solution by simple changing the type.

Posted: **Tue Dec 02, 2014 2:13 pm**

I will tomorrow test the memory functions. I added for 64-bit long and ulong in all write/ read operation and also readPtr64,writePtr64 function this should be working.

Posted: **Thu Dec 04, 2014 5:03 pm**

Okay the memory function seems to working but I realized that I have/had a bug the default values seems to be not loading, in one place

Code: Select all

void openLog()
{
	Settings *psettings = Macro::instance()->getSettings();
	/*static const char* logDkey = CONFVAR_LOG_DIRECTORY;
	static const char* logDir = psettings->getString(logDkey,CONFDEFAULT_LOG_DIRECTORY).c_str();*/
	static const char* logDir = "logs";
	static const char* logRkey = CONFVAR_LOG_REMOVAL_DAYS;
	static size_t logRemovalDays = (size_t)psettings->getInt(logRkey);
	//std::cout << "LogDir: " << logDir << std::endl;
	// Ensure log directory exists

First the var logDir and logRemovalDays weren't even findable in my debugger, after some tries&code review I read that when you import a extern var you must make it static which I did thinks like CONFVAR_LOG_DIRECTORY I can have in the scope(values are okay) through it but when I give it to another function (getString) on the other side even when I declare the argument as static I got a not readable memory.

logRemovalDays works through a fallback and I got default values I tried to make it workable too but I ended up writing it simply down.

Posted: **Thu Dec 04, 2014 6:12 pm**

That seems pretty odd to me. I don't see why they would need to be static, but I suppose it wouldn't hurt.

Code: Select all

	const char *logDir = psettings->getString(CONFVAR_LOG_DIRECTORY).c_str();
	unsigned int logRemovalDays = (unsigned int)psettings->getInt(CONFVAR_LOG_REMOVAL_DAYS);

	printf("LogDir: \'%s\'\n", logDir);
	printf("logRemovalDays: %d\n", logRemovalDays);

This all works just fine for me. Maybe this is another thing broken in the Microsoft compiler you're using? Can you provide me with your source so I can check that out?

Posted: **Thu Dec 04, 2014 8:19 pm**

I think too it is the compiler

I found using 'static' here : http://msdn.microsoft.com/en-us/library/0603949d.aspx

It doesn't say why you should use static but building your way around this is kinda too much effort for to little outcome.
Here my 64-bit version with source:
https://www.sendspace.com/file/y048xx

Posted: **Fri Dec 12, 2014 1:20 am**

I updated the files above now motion tracking is also possible

I will see if I can make a backport to 32-bit tomorrow. Maybe there are some guys who want to play with it....comes to think about it 32-bit/64-bit should only matters when your are reading memory.....

Anyway I will do it too.

SolarStrike Software

Playing with the MM2 code

Playing with the MM2 code

Re: Playing with the MM2 code

Re: Playing with the MM2 code

Re: Playing with the MM2 code

Re: Playing with the MM2 code

Re: Playing with the MM2 code

Re: Playing with the MM2 code

Re: Playing with the MM2 code

Re: Playing with the MM2 code

Re: Playing with the MM2 code

Re: Playing with the MM2 code

Re: Playing with the MM2 code

Re: Playing with the MM2 code

Re: Playing with the MM2 code

Re: Playing with the MM2 code

Re: Playing with the MM2 code

Re: Playing with the MM2 code

Re: Playing with the MM2 code

Re: Playing with the MM2 code

Re: Playing with the MM2 code