Rick

http://lua-users.org/wiki/MathLibraryTutorial

You have to load a new font object where the size is a parameter to the loading function. http://www.leadwerks.com/werkspace/page/documentation/_/command-reference/font/fontload-r43 You can load the same font with different sizes many times. I wish this was more of an option in the DrawString() function but oh well

This is the exact reason I offer my time (for very cheap) to help do 1 on 1 training. I'm pretty flexible (although Aug here is a bad month for me) in my days/times. I'm a person who learns faster when I have someone directly helping me than reading a bunch of stuff that may or may not be exactly related to the topic at hand, and so I'm offering others that same chance at a very indie friendly price.

Can't we do that in the C++ version now? Package::Load() has a password parameter so some time ago I remember testing password protecting zip files and it worked. Can't recall if that was just 3.0 but this seems like it should work right? Inside main.cpp //Load any zip files in main directory Leadwerks::Directory* dir = Leadwerks::FileSystem::LoadDir("."); if (dir) { for (int i=0; i<dir->files.size(); i++) { std::string file = dir->files[i]; if (Leadwerks::String::Lower(Leadwerks::FileSystem::ExtractExt(file))=="zip") { Leadwerks::Package::Load(file); } } delete dir; } I seem to recall just zipping all the asset folders as they exist in the project directory (the same dir as the exe).

There is a point in the tutorial where I break out those lines of code that were in Script:Start() into their own function name LoadWeapon(). That's the part you must have missed.

Can you show us your LoadWeapon() function, and what script do you have the LoadWeapon() function in. Want to make sure you have function Script:LoadWeapon() and not just function LoadWeapon(). Those 2 are at different scopes and could cause this error also.

I did this once in LE 2.x where I had a plane that I put a texture on it. Then I would take every vertex of that plane and cast a ray downward until it hit something. Then I would set that planes vertex to the Y collision. If you do that with all vertices then it'll hug the terrain/whatever. The more verts the longer this process will take but the better hugging you'll get. If your terrain is very hilly then you'd want more. I don't know if Lua gives us vertex manipulation access though.

It looks like you can use Monodev for C++ too from a quick google search, so I assume that's what he's doing.

I don't use Monodevelop so not sure what needs to be done. I don't think that's supported by LE so that would mean you have to setup all the paths required to get it working. I think codeblocks on Linux & VS on Windows are directly supported and they get automatically setup with the correct paths for Leadwerks to be compiled in C++. You'd be best to look at those projects to see what paths are all needed and then do that for your monodev project.

Could we get the camera passed to this hook just like DrawEach has? In Lua this is what happens and should happen in C++ too I think. http://www.leadwerks.com/werkspace/page/documentation/_/command-reference/entity/entitypostrenderhook-r780

Trust me you care. In your IScript you'll want to include leadwerks.h #pragma once #include "Leadwerks.h" using namespace Leadwerks; class IScript { protected: Entity* entity; public: IScript(Entity* e) { entity = e; } virtual ~IScript() {} virtual void Collision(Entity* entity, float* position, float* normal, float speed); virtual void Draw(); virtual void DrawEach(Camera* camera); virtual void PostRender(Camera* camera); virtual void UpdateMatrix(); virtual void UpdatePhysics(); virtual void UpdateWorld(); }; };

The usual way is a little misleading as it seems a lot of game engines are leaning this way these days. Unity (although it's C# it's the same idea and closer to C++ than Lua), Unreal is similar. The major difference is that their editors allow the user to assign which C++ code runs on which entity, where in Leadwerks we have to decide a way to do this ourselves and LE doesn't have anything built-in. With the power of setting key values in the editor and if one implements the factory pattern in C++, it would become fairly easy to do this with minimal glue code. Josh could have done this same thing to help us but he doesn't see C++ that way, but that's his preference only.

So there is no "official" way to do this but here is a method. 1) Create an "interface" class that has a virtual function for each entity script 2) Create classes that represent Lua scripts and derive them from the script interface 3) Load your map and then loop over all the entities and you'll need a way to identify at run-time which entity should get what script class. In my example I just look for a key value to see if it's equal to a value of the same name as the script class. This still means you have to attach a script in Lua to set this value. These are reasons why I ask for an editor way to add key values to avoid setting lua scripts if not needed but if we still want to set key values for an entity. 4) Create an instance of that script, set the entities user data to this script class instance (we use this later in the global hooks), add all the hooks, add to a list so we can store each instance. 5) Create global hooks and inside cast the user data to our script interface so we can call the class virtual functions to get the code to enter our class instances so we aren't working in a global space because that's bad. Here is some code that does what the description above says. // derive your "script" classes from this interface to make it an "entity script" class IScript { protected: Entity* entity; public: IScript(Entity* e) { entity = e; } virtual void Collision(Entity* entity, float* position, float* normal, float speed); virtual void Draw(); virtual void DrawEach(Camera* camera); virtual void PostRender(Camera* camera); virtual void UpdateMatrix(); virtual void UpdatePhysics(); virtual void UpdateWorld(); }; // example "script" that you would have to make class DoorScript : public IScript { public: virtual void Collision(Entity* entity, float* position, float* normal, float speed) { } virtual void Update() { } }; // define each global hook function here and the same idea applies to all. cast the user data on the entity // to IScript and if it's not NULL call that instance method void CollisionHook(Entity* entity0, Entity* entity1, float* position, float* normal, float speed) { IScript* script = (IScript*)entity0->GetUserData(); if(script != NULL) { script->Collision(entity1, position, normal, speed); } } void UpdateWorldHook(Entity* entity) { IScript* script = (IScript*)entity->GetUserData(); if(script != NULL) { script->UpdateWorld(); } } // keep a list somewhere in App.h/cpp list<Script*> entities; // called in App.cpp Start() Map::Load("maps\start.map"); // after map is loaded list<Entity*>::iterator iter; for(iter = world->entities.begin(); iter != world->entities.end(); ++iter) { Entity* e = (*iter); // note that if you implement the factory pattern here, this will become easier. you could have a list of registered "scripts" and here you just pass the script value to this factory to create an instance of that script. this way all you have to do is create the "script" class and then register it to the factory. I'll look into making a helper for this as well if(e->GetKeyValue("script") == "DoorScript") { IScript* script = new DoorScript(); e->SetUserData((void*)script); e->AddHook(Entity::Collision, (void*)CollisionHook); // add all hooks here entities.push_back(e); } }

C++ isn't the same idea as Lua when it comes to attaching scripts to entities. Leadwerks doesn't setup C++ like this, although you could simulate it with classes and setting up the callbacks for each entity. [edit] Beat http://www.leadwerks.com/werkspace/page/documentation/_/command-reference/entity/ At the bottom are entity hooks that represent the same Lua entity functions. I'll setup some code to mimic the Lua system and post it here.

The problem with this is that it has 24 votes and most other things like this don't get more than 50 some votes. It would seem the majority of the people who own LE don't interact with much on the forums so the sample size we always get from forums is so small. I wish more people would interact but for some reason they don't.

Woah. I've never even heard of Daz before but those are nice models. Thank you for that link!

An organization tutorial would probably be a good idea. Most people don't realize this until it's too late. Grouping things under pivots or some csg is a way to get that and I believe parent/child has to be considered when doing so and calling certain functions that take the global/local boolean parameter.

Is this a thing? Like, did Josh say he would consider this?

If you think something is worth it then copy and paste the text in the wiki. It would seem that wiki gets a lot of hits and usage so it would be a good place for it. I should be better with this as well honestly. I need to get more stuff in the wiki.

Interesting. Don't recall ever seeing that before. Thank you.

In my training today we were attempting to change the material on a surface of a model that was loaded in the scene at design time. The model was a child of a csg box which was what was being checked for picking. The problem is that we were able to get the child (the actual model) and call Entity functions on it, but not Model functions, which is how you get surfaces. What am I missing on how to get the surface of a model loaded at design time? For example, this works because SetColor() is an Entity function and GetChild() returns an Entity self.entity:GetChild(0):SetColor() This blows up with the function being nil because GetSurface() exists for Models not Entities self.entity:GetChild(0):GetSurface(2) Was looking through the docs and couldn't see any sort of conversion function. Any ideas?

Replied via Leadwerks chat.

I can yes. I know both C++ and Lua so I for sure can teach you how to use both. I'm gone this weekend but during the week in the evenings or next weekend works.

RakNet suggests adding in the entire source to your project. I go that route all the time without issue.

I wonder if we can combine CallFunction() with pushing things on the stack in Lua if that would pass the data to the function like normal parameters. Will have to test when I have time.