Rick

For me personally it's about wanting more dynamic functionality that C++ doesn't provide. If C++ had reflection then there would probably be no need for void* when looking to have the ultimate flexibility. I have a million uses with .NET reflection. I can do it all with C++ but it's slightly less flexible. I love being able to create a class and call it's function all from string variables!

If pointer size isn't the same on either system isn't enough to scare you away, here is another fear that could happen. Note the obj gets deleted and even with a NULL check it still goes into and tries to run the Test() function. So if passing things between Lua and C++ this could happen to someone. #include <string> #include <iostream> using namespace std; class Object { private: string name; public: Object(string n) { name = n; } void Test() { cout << name; } }; int main() { Object* obj = new Object("test"); int ptr = (int)obj; delete obj; Object* o = (Object*)ptr; if(o != NULL) o->Test(); // it will still try to run this and fail int w; cin >> w; return 0; }

From what I've read (random articles online) the size of a pointer isn't guaranteed on different systems. I've also read something about some front bits on certain systems for pointers are treated differently than for an int. Anyway, the following works for me, but I still think it's risky. #include <string> #include <iostream> using namespace std; class Object { private: string name; public: Object(string n) { name = n; } void Test() { cout << name; } }; int main() { Object* obj = new Object("test"); int ptr = (int)obj; Object* o = (Object*)ptr; o->Test(); // this does indeed print out "test" which means it's the same object that I created in the first line // just make it so the window doesn't close right away int w; cin >> w; return 0; } Your problem was most likely: int pointer = *(int*)o; You don't want to cast it to an (int*) but just an int. Don't blame me if this doesn't work on every system you are trying to target though

From my readings it's because you're not supposed to be doing what you are doing and nothing is guaranteed with that on multiple systems.

If I read into what you are thinking, it seems like you want to take the pointer as some kind of ID for the object since it should be unique (since it's a memory address) and convert it to int to be passed back and forth between C++ & Lua?

I'm no expert but I would think that would be dangerous. I would think you'd be safer to just make a unique ID for objects and access it that way.

If you store it as an entity key, you should be able to use GetEntityKey from C++ after you load the map and find the entity.

Ah. http://www.leadwerks.com/wiki/index.php?title=CameraClearColor The C++ doesn't seem to do anything with clear mode, but I see the BMax version does.

TCamera camera = GetLayerCamera(GetFrameworkLayer(0)); CameraClearColor(camera, Vec4(1.0, 0, 0, 1)); I still get a black screen after doing this. I would think I would get a red screen. What am I missing?

It's been some time since I used C++ but I'm getting back into it and did I miss something with an LE namespace addition? Also I thought I used to be able to create TVec# obejcts by passing in parameters to their ctors. I can't seem to do that anymore as it looks like they don't allow that now? I'm using Rolands C++ project creator but I assume and it looks like it's just pointing back to my LE installation folder. Were these sort of new because I don't recall the namespace and the TVec change before. Nevermind about the TVec thing I see Vec4 is what I need to use. Been awhile

Correct me if I'm wrong but in the flowgraph you are making the connections between inputs and outputs of specific nodes. So I would assume that when making that connection for that instance of that node you know what outputs and when they were connected. Knowing that would mean per each node instance you could know the order they were connected? Well, I think you have to be prepared to handle anything your system can. Over at UDK they aren't telling people "we didn't mean for you to do that with our flowgraphs". Because I am going to push this thing to the limits and so will others

So in a flowgraph situation it would be the order of how you setup the connectors? In that situation you may want to place a number on the connector which shows what order they are in or else coming back to a flowgraph after 2 months you wouldn't know as you'd just have 3 lines coming out from 1 output and going to 3 different inputs without knowing anything about the order they were originally connected. The confusing thing about having this ability is visually it will look as if they are all running at the same time.

Yeah, this would be exactly what you would do. This is the general workings of most flowgraphs anyway. You have specific nodes that do specific tasks against some data and can return data and continue flow. Eventually you'll get into basic math nodes that will say add 2 values together and the returned value will be used in another node, etc. The interesting part I think about all of this is that it looks like you can have multiple inputs to 1 output at which point the flowgraph could get confusing to read because those nodes can then have outputs and so the question might be what order are the outputs being called because that could be important to know if those outputs need to use data between them.

Generally those would be parameters to the MoveTo node and not something that sits on the connector. What most flowgraphs do is have parameters and return values at the bottom of the node that the node can take. You can hardcode them via a grid that shows the same values or you can assign them from variables like you have, but connecting them to the connectors doesn't look all that great or clean. Actually C# can do the same thing. Just saying.

I've looked at Alice before. Our thoughts on the topic just differ. Nothing wrong with that.

Wow, that's sweet!

I think yes and no. Not sure if you were around when Pancakes was here but he was not a coder at all and he created a pretty complex battle system using a flowgraph from Blender I believe it was. UDK's Kismet is an example of this as well. In what I'm playing with I'm taking it a step farther and picturing a world where you are programming almost line for line in flowgraphs the same as in C++. How you make your flowgraphs shouldn't be much different in how you code. Make small pieces of flowgraphs that you fit together. I can make an unmanageable flowgraph just like I can make an unmanageable function. I believe flowgraphs can be just as easy if not easier (since most people are visual learners) than coding in a typed language. I know many various languages and I switch between about 3-4 on a daily basis between work and hobby. The idea of thinking logically doesn't change between them but the syntax does. Should the syntax really matter or should the logical thinking matter? Clearly logical thinking is the entire point of making a computer do something. So I asked myself how would we remove the syntax aspect then since it's not required. Syntax isn't the only reason of course but it's a reason. I also believe that reading code would be faster because of the visual aspect. Given certain colors and shapes being used to represent things, at a fast glance you could tell what is sort of going on. These are my hopes anyway.

Well actually the main thing I was thinking was that you still have some C mannerism is your design and this would make it more C++ like, but now that you mention it that would be something that you COULD do if you wanted to. I guess the only thing that comes to mind currently is that you could have your "player" script be attached to another entity if you wanted your player to be able to control a different entity off and on at run-time. If you did it this way you are giving more options while keeping your ways functionality. Just because we can't think of a reason to use this doesn't mean there isn't, or someone will think of it later. If you wanted to keep your design then you can overload your AttachScript to take an Actor class and that would be another way to get that functionality while still holding your design. Actor* actor; Model* teapot = LoadModel("teapot.mdl"); Model* teapot1 = LoadModel("teapot.mdl"); actor = teapot->AttachScript("ColorOscillate.lua"); teapot1->AttachScript(actor); Generally methods don't create objects unless you are using the factory design so that's what I was mainly talking about.

That seems backwards. I would think it would be: Actor* actors[2]; Model* teapot = new Model("teapot.mdl"); actors[0] = new Actor("ColorOscillate.lua"); actors[1] = new Actor("PointAt.lua"); teapot->AttachActor(actors[0]); teapot->AttachActor(actors[1]); //or teapot->AttachActors(actors); I still think your naming convention is messed up with "Actor". They are scripts and you even have the method called AttachScript yet they return actors? Just seems strange.

Yeah creating separate meshes isn't a solution I would want either. I think Josh needs to make this possible most of these solution in the editor is pretty hacky and is most likely prone to issues.

Im pretty sure everyone who has tried le networking has given up due to frustration. If and when that happens I'd recommend raknet. I've used it many times and it works nicely!

That's fine and dandy but now you are creating copies instead of using instances which isn't ideal. Having the phy file just causes issues and I believe is one of many reasons Josh is looking at other physics engines. The other side effect there would be timing. I believe creating bodies on complex models has a noticeable delay to it and LE isn't threaded so now you are talking about adding threading to the mix because otherwise every time you change the scale, even by a small amount that would have to happen.

Where would entity->SetObject("target",targetentity,i); command be executed? That's the glue code that actually links the variable target of the script to an actual ID. The script itself wouldn't have this in it as all it does is expose the target variable. In the editor is where you are making that link and so even in your scene example file that doesn't actually set the variable UNLESS you are thinking of embedding the actual lua scripts inside the scene file? That would seem weird to me.

So you plan on having a separate lua file that the editor creates and maintains and has all that glue code and have it automatically loaded with the scene?

Just wondering, where do you plan on putting that glue code that the editor will create?