thehankinator

Did you build the nav mesh?

This is a common thing people ask about. To directly link an entity into your script you could do it by adding the following line of code to the top of your ball script. Script.cube = nil --Entity "Cube" With this code you can go into the editor and select your ball entity, then go to the script tab, there should now be a box labeled "Cube", drag the cube from the Scene tab into this box. Now within your script you could do something like local distance = self.entity:GetDistance(self.cube) There are many other ways to do this and without knowing more about what you are trying to accomplish, another method might be better.

Have you looked at this yet? http://www.leadwerks.com/werkspace/page/viewitem?fileid=641192226

What I meant by that was providing a cmake file to build the Leadwerks static library to allow development with different compilers on Windows would require the source (doubt that'll happen). Anyone could make a cmake file for building a Leadwerks application but on Windows it's gotta use the MSVC compiler.

Perfect, thank you!

To provide a cmake project Josh would have to provide the Leadwerks source code, I don't think he wants to do that.

I've got a texture, something like below. I when the player fires a gun, I'd like to rotate the image around. Anyone know a way to do that without creating an image frame by frame?

I'm sure other people have other reasons to use mingw over MSVC but for me, in my experience, mingw provides the path of least resistance to build open source libraries on Windows. For a given library there is a better chance that the library will provide a makefile(or some other mechanism to build) for gcc than a MSVC project file. cmake has really improved the situation but isn't always available. Like nick.ace, I use both, I think they are both great (nothing touches the MSVC IDE). I can see why you wouldn't bother with mingw and I don't disagree but there is something to be said for tool consistency between platforms.

I get why Josh doesn't plans to support it but it's ignorant to say supporting other compilers is useless.

mingw support would be nice (preferably mingw-w64 fork)

Have you looked at this? http://lua-users.org/wiki/LuaCsv

IMO It's not fair to say that drawing to a texture is a current feature of LE since the Buffer class isn't documented.

Have you tried the workshop on steam? http://steamcommunity.com/workshop/browse/?appid=251810&requiredtags[]=Script

I think if you uncheck Gaming Evolved App in the driver installer you won't get that junk.

Prints out garbage because the format bytes are not always alpha numeric when printed as a character plus I don't think the floats are encoded in a way that is human readable when packed. Gotta print each character as a byte. To inspect the packed data I did: str_mpac = "" for i=1, string.len(mpac) do str_mpac = str_mpac..string.format('%02X', string.byte(string.sub(mpac,i,i))) end System:Print(str_mpac) Which printed 9283A179CA400EF9DBA178CA3F8FBE77A17ACA4056147B83A179CA40A77CEEA178CA4083EF9EA17ACA40CB0A3D

I agree, I wouldn't do any heavy lifting in Lua. They have libraries for like every language, for C/C++ there are multiple implementations to choose from. http://msgpack.org

I rebuilt lua-enet and linked it to LuaJIT 2.0.2 and enet 1.3.13. The significant result with this build is you don't need to duplicate lua51.dll (Step 4 of Rick's post). I've not thoroughly tested it but if anyone wants it I'll upload it.

I haven't tried it with lua-enet but you can use lua-MessagePack to encode arbitrary data into a string. It isn't too space efficient but it should work if you don't have a large amount of things to synchronize. http://fperrad.github.io/lua-MessagePack Here is an example of how I encoded a couple Vec3s into a string to be sent via lua-enet (or whateva) mp = require 'Scripts/Functions/MessagePack' thing1 = Vec3() thing1.x = 1.123 thing1.y = 2.234 thing1.z = 3.345 thing2 = Vec3() thing2.x = 4.123 thing2.y = 5.234 thing2.z = 6.345 data = {{x=thing1.x, y=thing1.y, z=thing1.z}, {x=thing2.x, y=thing2.y, z=thing2.z}} mp.set_number'float' mp.set_array'with_hole' mp.set_string'string' mpac = mp.pack(data) System:Print("Len="..string.len(mpac)) unpacked_data = mp.unpack(mpac) System:Print("pos.x="..unpacked_data[1].x.."pos.y="..unpacked_data[1].y.."pos.z="..unpacked_data[1].z) System:Print("pos.x="..unpacked_data[2].x.."pos.y="..unpacked_data[2].y.."pos.z="..unpacked_data[2].z) Result Len=45 pos.x=1.1230000257492pos.y=2.2339999675751pos.z=3.3450000286102 pos.x=4.1230001449585pos.y=5.2340002059937pos.z=6.3449997901917 45 bytes compared to 24 if it was raw c++. Not ideal but it'd work. EDIT: I'm dumb, require works fine, no change required to MessagePack.lua

Good catch! Old habits die hard.

I'd use GetEntityNeighbors() function in Scripts/Functions/GetEntityNeighbors.lua. You could do something like: local radius = 10 local entities = GetEntityNeighbors(self.entity, radius, true) for e=1, #entities do if entities[e].script.health ~= nil then --deal damage end end

A script that is attached to an element will only stay alive until you call world:Clear() (this is done when you load a new level for instance). For something to persist through loading levels you would probably want to use a global variable to store that information. You can also load scripts in Main.lua, the items in those scripts would be global and would persist through a world:Clear(). This tutorial talks more about global variables. Bare in mind that the Journal script will likely need to be modified to use global variables to track progress through a world:Clear() http://www.leadwerks.com/werkspace/page/tutorials/_/variables-r14

Do you have the Journal.lua script on a pivot in your scene?

You need professional or someone to rebuild it for you with that change to the linker settings.

All it should take is changing the subsystem option(in the linker options) from "Console" to "Windows" in MSVC then rebuild. You would need to rebuild every time there is an update to LE(and don't forget!).

I can do it, I've been meaning to for myself anyway.