JRowe
Active Members-
Posts
1,732 -
Joined
-
Last visited
About JRowe
- Birthday 03/17/1925
Profile Information
-
Member Title
Chasing the white rabbits
-
Location
Through the looking glass, darkly.
-
WWW
http://www.AutoIt.me
-
Interests
AutoIt, Artificial Intelligence, xkcd, conservativism, history, cyberpunk, web design, beer, music, and flying(my arms aren't quite strong enough, yet.)
JRowe's Achievements
Universalist (7/7)
10
Reputation
-
LKP reacted to a post in a topic:
Au3Irrlicht 2.0
-
MaximusCZ reacted to a post in a topic:
AU3 DLL Extension
-
nikooo1608 reacted to a post in a topic:
Defining String variable using multiple lines in the editor.
-
Matze1985 reacted to a post in a topic:
Artificial Neural Network UDF
-
mLipok reacted to a post in a topic:
Basic speech recognition.
-
IgImAx reacted to a post in a topic:
Artificial Neural Network UDF
-
Xandy reacted to a post in a topic:
Basic speech recognition.
-
GDI+ 3D Engine (Models, Shading, Rotation, Scaling, etc.)
JRowe replied to minxomat's topic in AutoIt Example Scripts
While well off topic, you might want to look for software capable of both importing and exporting 3da and convert between formats. Convert to .obj and then back to .3da when you need to. -
Geir1983 reacted to a post in a topic:
Poker Hand evaluator plugin
-
Wonvy reacted to a post in a topic:
SciLexer UDF
-
jvanegmond reacted to a post in a topic:
Link Grammar for AutoIt
-
You can run arbitrarily large scripts. If your script runs, then it can be run online. However... having a monolithic central process can hog unnecessary amounts of CPU, but if it's a one-off, used only by you on a private webserver, then it'd be more efficient for you to just use it as is. If you want to have many people use it, then a little work to break it down into smaller scripts would serve you well. I'll be transferring the old files to a newer, more permanent site, so I'll replace the download link (even though everything is still accessible from here.) AutoIt.me is defunct, for now.
-
Probably something to do with a visual studio runtime. Even if its not a runtime issue, it's trivial to get it working from scratch. Besides, creating a normal dll and using dllCall makes more sense now than using plugins.
-
The original post contains a link to the source article which inspired the whole thing. http://www.codingthewheel.com/archives/poker-hand-evaluator-roundup#2p2 Reading that article should be a prerequisite to using this, anyway. You can get the pre-compiled binaries and the source from the links.
-
Lots of fun, so far. I've been learning Lua, it's really enlightening.
-
Just send me whatever you want changed, and I'll change them - I'm usually in every day or two.
-
You can access POSTed data directly, using the global $_POST_raw . To see if anything is actually getting POSTed, just do an echo on $_POST_raw, and then either write your own handler for POSTed data, or figure out what's breaking down between the _Post and the processing.
-
It's possible to import animated gifs as textures if you're willing to hack around with the Irrlicht source - there's a plugin somewhere on their forums allowing that possibility. Anyway, texture support is about complete as it gets.
-
MS3D costs a bit, so it's not the ideal solution (the weighting setup is also kinda off) but it is probably the easiest way to get an animated model working. Bones are directly accessible, so you aren't limited to a preset bundle of animations as with md2 or md3 models. If you don't want to pay, then posts like this are very useful: http://www.hongkiat.com/blog/25-free-3d-modelling-applications-you-should-not-miss/ There are a bunch there that look very useful. Look for .x exports if you want to be able to animate a model. I've tried to find an easy way of doing md2 or md3, and always end up frustrated. .x and skeletal animation is a breeze, though. Good stuff, guys, keep up the good work!
-
AutoIt used to have speed problems when using arrays in arrays. It no longer does, as they have fixed whatever it was that was causing the problem. There is now nothing wrong with using arrays in arrays, so long as you know what you're doing. Here's what happens: A nested array in a holder array cannot be accessed directly through the holder array. You have to assign the value of the nested array ($a_HolderArray[0], in this instance) to an accessor array. Local $a_HolderArray[1] Local $a_NestedArray[4] = [1,2,3,4] Local $a_HolderArray[0] = $a_NestedArray ;Attempt to clean up after ourselves $a_NestedArray = "" ;You can't get to any of the data inside the Holder array. ;$i_ValueFromInsideNestedArray = ??? $a_AccessorArray = $a_HolderArray[0] $i_ValueFromInsideNestedArray = $a_AccessorArray[3] ConsoleWrite($i_ValueFromInsideNestedArray & @CRLF) ;Outputs the value 4 $a_AccessorArray = "" This is very helpful do do complex iterations or table navigation. Just remember two things: 1.) Clean up after yourself. Use local variables inside functions whenever creating arrays to be inserted, so that you don't create a leak. 2.) You can't access arrays directly inside other arrays. You have to declare a new accessor array as the nested array.
-
Lua is a programming language much like AutoIt. It has similar, simple, procedural syntax, and is built for small size and speed. It is extremely customizable, allows tight integration with c code, and vice versa, which is what makes it easy to use with AutoIt - all au3 code needs is a few dllCalls to set up the Lua "state", and functions to get/set data within the Lua context. Features: http://www.lua.org/about.html Lua is very fast, and allows us to extend AutoIt easily, similar to the way plugins work. This also allows us to immediately and easily utilize every package for Lua that currently runs on Windows - game engines, GUI libraries, networking, number crunching, and more. I think the biggest benefit comes from the ability to create a framework application in AutoIt, and then offload CPU intensive functions, or functions intended to be customized (plugins) to Lua. LuaForWindows comes with a ton of extra Lua libraries meant to enhance usability on Windows. You'll find that while AutoIt has easily as much utility, LFW has a few notable packages that will make many of us very happy: LuaCURL (internet), LuaExpat(xml), LuaSQL(database), WxLua(GUI), LuaGL(low level 3D), Lanes(sane multithreading), LOOP(object oriented implementation.) Here's an example of how to get a simple Lua function working in an AutoIt script - you pass parameters, and return results in the way you'd expect. Lua uses a stack concept to facilitate data passing back and forth between the host (AutoIt) and the script (Lua.) The messy bits should be bundled into helper functions that make it easier to integrate any old functions, but this should be plenty to get us started. 3 cheers for Smoke_N! ;Author: Smoke_N Opt("MustDeclareVars", 1) #region Main Globals Global $__g_sluadll = "lua51.dll" Global $__g_hluadll = 0 Global $__g_pluanewstate = 0 Global Const $LUA_VERSION = "Lua 5.1" Global Const $LUA_RELEASE = "Lua 5.1.1" Global Const $LUA_VERSION_NUM = 501 Global Const $LUA_COPYRIGHT = "Copyright (C) 1994-2006 Lua.org, PUC-Rio" Global Const $LUA_AUTHORS = "R. Ierusalimschy, L. H. de Figueiredo & W. Celes" Global Const $LUA_SIGNATURE = "Lua" Global Const $LUA_MULTRET = (-1) Global Const $LUA_REGISTRYINDEX = (-10000) Global Const $LUA_ENVIRONINDEX = (-10001) Global Const $LUA_GLOBALSINDEX = (-10002) Global Const $LUA_YIELD_ = 1 Global Const $LUA_ERRRUN = 2 Global Const $LUA_ERRSYNTAX = 3 Global Const $LUA_ERRMEM = 4 Global Const $LUA_ERRERR = 5 #endregion Main Globals #region Test Code If Not _Lua_Initiate() Then Exit 1 _Lua_Open() _Lua_OpenLibs() _Lua_DoFile("add.lua") _Lua_GetGlobal("add") _Lua_PushNumber(41) _Lua_PushNumber(22) ConsoleWrite("Making the call..." & @CRLF) _Lua_Call(2, 1) ConsoleWrite("Call made" & @CRLF) Global $n_sum = _Lua_ToNumber(-1) ConsoleWrite("done." & @CRLF) _Lua_Pop(1) ConsoleWrite("done.." & @CRLF) _Lua_Close() _Lua_DeInitiate() ConsoleWrite($n_sum & @CRLF) #endregion Test Code #region Functions Func _Lua_Open() $__g_pluanewstate = 0 If Not _Lua_Initiate() Then Return SetError(-1, 0, 0) Local $a_ret = DllCall($__g_hluadll, "ptr:cdecl", "luaL_newstate", "ptr", 0, "ptr", 0) If @error Or $a_ret[0] = 0 Then Return SetError(1, 0, 0) $__g_pluanewstate = $a_ret[0] Return $a_ret[0] EndFunc Func _Lua_Close($p_state = 0) If Not _Lua_Initiate() Then Return SetError(-1, 0, 0) If $p_state = 0 Then $p_state = $__g_pluanewstate DllCall($__g_hluadll, "none:cdecl", "luaL_close", "ptr", $p_state) If @error Then Return SetError(1, 0, 0) Return 1 EndFunc Func _Lua_OpenLibs($p_state = 0) If Not _Lua_Initiate() Then Return SetError(-1, 0, 0) If $p_state = 0 Then $p_state = $__g_pluanewstate DllCall($__g_hluadll, "none:cdecl", "luaL_openlibs", "ptr", $p_state) If @error Then Return SetError(1, 0, 0) Return 1 EndFunc Func _Lua_LoadFile($s_filename, $p_state = 0) If Not _Lua_Initiate() Then Return SetError(-1, 0, 0) If $p_state = 0 Then $p_state = $__g_pluanewstate Local $a_ret = DllCall($__g_hluadll, "int:cdecl", "luaL_loadfile", "ptr", $p_state, "str", $s_filename) If @error Or $a_ret[0] <> 0 Then Return SetError(1, 0, 0) Return 1 EndFunc Func _Lua_DoFile($s_filename, $p_state = 0) If Not _Lua_Initiate() Then Return SetError(-1, 0, 0) If $p_state = 0 Then $p_state = $__g_pluanewstate Local $i_load = _Lua_LoadFile($s_filename) Local $i_pcall = _Lua_PCall(0, $LUA_MULTRET, 0) If BitOR($i_load, $i_pcall) = 0 Then Return SetError(1, 0, 0) ;Local $a_ret = DllCall($__g_hluadll, "int:cdecl", "luaL_dofile", "ptr", $p_state, "str", $s_filename) Return 1 EndFunc Func _Lua_GetGlobal($s_name, $p_state = 0) If Not _Lua_Initiate() Then Return SetError(-1, 0, 0) If $p_state = 0 Then $p_state = $__g_pluanewstate ;DllCall($__g_hluadll, "none:cdecl", "lua_getglobal", "ptr", $p_state, "str", $s_name) _Lua_GetField($s_name, $LUA_GLOBALSINDEX, $p_state) If @error Then Return SetError(1, 0, 0) Return 1 EndFunc Func _Lua_GetField($s_char, $i_index = $LUA_GLOBALSINDEX, $p_state = 0) If Not _Lua_Initiate() Then Return SetError(-1, 0, 0) If $p_state = 0 Then $p_state = $__g_pluanewstate DllCall($__g_hluadll, "none:cdecl", "lua_getfield", "ptr", $p_state, "int", Int($i_index), "str", $s_char) If @error Then Return SetError(1, 0, 0) Return 1 EndFunc Func _Lua_PCall($i_args, $i_results, $i_errfunc = 0, $p_state = 0) If Not _Lua_Initiate() Then Return SetError(-1, 0, 0) If $p_state = 0 Then $p_state = $__g_pluanewstate Local $a_ret = DllCall($__g_hluadll, "int:cdecl", "lua_pcall", _ "ptr", $p_state, "int", Int($i_args), "int", Int($i_results), "int", Int($i_errfunc)) If @error Then Return SetError(1, 0, 0) Return 1 EndFunc Func _Lua_PushInteger($i_num, $p_state = 0) If Not _Lua_Initiate() Then Return SetError(-1, 0, 0) If $p_state = 0 Then $p_state = $__g_pluanewstate DllCall($__g_hluadll, "none:cdecl", "lua_pushinteger", "ptr", $p_state, "int", Int($i_num)) If @error Then Return SetError(1, 0, 0) Return 1 EndFunc Func _Lua_PushNumber($n_num, $p_state = 0) If Not _Lua_Initiate() Then Return SetError(-1, 0, 0) If $p_state = 0 Then $p_state = $__g_pluanewstate DllCall($__g_hluadll, "none:cdecl", "lua_pushnumber", "ptr", $p_state, "double", Number($n_num)) If @error Then Return SetError(1, 0, 0) Return 1 EndFunc Func _Lua_PushString($s_str, $p_state = 0) If Not _Lua_Initiate() Then Return SetError(-1, 0, 0) If $p_state = 0 Then $p_state = $__g_pluanewstate DllCall($__g_hluadll, "none:cdecl", "lua_pushstring", "ptr", $p_state, "str", $s_str) If @error Then Return SetError(1, 0, 0) Return 1 EndFunc Func _Lua_Call($i_args, $i_results, $p_state = 0) If Not _Lua_Initiate() Then Return SetError(-1, 0, 0) If $p_state = 0 Then $p_state = $__g_pluanewstate DllCall($__g_hluadll, "none:cdecl", "lua_call", "ptr", $p_state, "int", Int($i_args), "int", Int($i_results)) If @error Then Return SetError(1, 0, 0) Return 1 EndFunc Func _Lua_ToNumber($i_index, $p_state = 0) If Not _Lua_Initiate() Then Return SetError(-1, 0, 0) If $p_state = 0 Then $p_state = $__g_pluanewstate Local $a_ret = DllCall($__g_hluadll, "double:cdecl", "lua_tonumber", "ptr", $p_state, "int", Int($i_index)) If @error Then Return SetError(1, 0, 0) Return $a_ret[0] EndFunc Func _Lua_Pop($i_pop, $p_state = 0) If Not _Lua_Initiate() Then Return SetError(-1, 0, 0) If $p_state = 0 Then $p_state = $__g_pluanewstate DllCall($__g_hluadll, "none:cdecl", "lua_pop", "ptr", $p_state, "int", Int($i_pop)) If @error Then Return SetError(1, 0, 0) Return 1 EndFunc Func _Lua_Initiate() If $__g_hluadll <> 0 Then Return 1 $__g_hluadll = DllOpen($__g_sluadll) If $__g_hluadll = -1 Then $__g_hluadll = 0 Return SetError(-1, 0, 0) EndIf Return 1 EndFunc Func _Lua_DeInitiate() If $__g_hluadll = 0 Then Return 1 DllClose($__g_hluadll) $__g_hluadll = 0 Return 1 EndFunc #endregion Functions Here's a sample Lua script. Put this in a file called "add.lua" function add (x, y) print("hello world") --print() is just like consoleWrite. After print, we need to call io.flush() to immediately output the results of the previous print io.flush() return (x + y) end LuaAu.zip This contains all the files needed to embed a Lua script. Including other libraries and resources requires a bit of Lua knowledge. I recommend using what's known as the blue PiL, or Programming in Lua. It's available to read online at: http://www.lua.org/pil/ If it doesn't work immediately, you may need the vcredist here: http://luaforwindows.googlecode.com/files/vcredist_x86.exe
-
Smoke_N took the time to fix it, and set it up fairly robustly. I had a non interactive function working, but he took it to the next level. I'll put these funcs together into something easily used, and then start a project thread. Embedded Lua should make for a very powerful tool in our arsenal. Thanks for taking a look, and 3 cheers for Smoke_N!
-
I'm working on embedding Lua, and I've been able to trigger lua functions from AutoIt, but I've hit a wall in passing parameters and results. The Lua script is easy: add.lua function add (x, y) return (x + y) end The AutoIt script uses "lua51.dll", which I've attached. $h_LuaDLL = DllOpen("lua51.dll") ;Create a new state for the Lua interpreter. Global $h_Lua_NewState = DllCall($h_LuaDLL, "ptr:cdecl", "luaL_newstate") ;Load all of the Lua libs DllCall($h_LuaDLL, "none:cdecl", "luaL_openlibs", "ptr", $h_Lua_NewState[0]) ;Load the example script "add.lua" into the Lua state $h_luaFoo = DllCall($h_LuaDLL, "int:cdecl", "luaL_loadfile", "ptr", $h_Lua_NewState[0], "str", "add.lua") ConsoleWrite("Result is: " & $h_luaFoo[0] & @CRLF) $i_lua_pCall = DllCall($h_LuaDLL, "int:cdecl", "lua_pcall", "ptr", $h_Lua_NewState[0], "int", 0, "int", -1, "int", 0) ConsoleWrite("Result of loadfile pcall is: " & $i_lua_pCall[0] & @CRLF) ;Execute a Lua function, passing parameters 5,10 ;Load the "add" function DllCall($h_LuaDLL, "none:cdecl", "lua_getglobal", "ptr", $h_Lua_NewState[0], "str", "add") ;Push the first parameter onto the stack DllCall($h_LuaDLL, "none:cdecl", "lua_pushnumber", "ptr", $h_Lua_NewState[0], "double", 41) ;Push the second parameter onto the stack DllCall($h_LuaDLL, "none:cdecl", "lua_pushnumber", "ptr", $h_Lua_NewState[0], "double", 22) ;Call (pcall) the function with 2 arguments and 1 result $i_lua_pCall = DllCall($h_LuaDLL, "int:cdecl", "lua_call", "ptr", $h_Lua_NewState[0], "int", 2, "int", 1) ConsoleWrite("Error Result is: " & $i_lua_pCall[0] & @CRLF) ;Get the results $sum = DllCall($h_LuaDLL, "double:cdecl", "lua_tonumber", "ptr", $h_Lua_NewState[0], "int", -1) $z = $sum[0] DllCall($h_LuaDLL, "none:cdecl", "lua_pop", "ptr", $h_Lua_NewState[0], "int", 1) ConsoleWrite("z is:" & $z & @CRLF) ;close the Lua state to clean up after ourselves. DllCall($h_LuaDLL, "none:cdecl", "lua_close", "ptr", $h_Lua_NewState[0]) I'm basing my attempt off this tutorial: http://www.debian-administration.org/articles/264 , the add.c example towards the end. Even though it's geared towards linux, it's very basic and should translate almost exactly. So, I'm after the result of $z = 63, or adding of the two parameters I push using "lua_pushnumber", as the function is supposed to do. Lua_Number is a double type. lua_tonumber returns a double. Right now, I'm getting Thanks!
-
Strangely enough, the idle framerate issue is *also* related to gravity. When you aren't moving, you're colliding with the terrain more often, and this causes more collision events, eating up more cpu. It can be solved by testing for idleness, and then setting and freezing the character node just a tiny bit above the terrain, and/or by disabling gravity. Or something like that - there will be all sorts of optimizations possible. As for multithreading, don't worry about it - clever use of conditionals and a sane sense of gamestates will overcome most problems.
-
The jumpspeed parameter interacts with gravity, so a higher speed = longer/higher jump. Irrlicht means "ghostlight" in German, and this app = awesome. Lots of potential here - AutoIt has virtually no limitations (except perhaps easily calling it from external code, but certainly not the other way around.) Great work!