MasteR

I noticed today that when physics debugging is activated, in my program as well as in the Leadwerks Editor, the wireframes are being rendered in the colour black instead of red. Active bodies are not shown as green either. Any thoughts? *EDIT* seems to only be when using the tunnels.sbx, all other scenes render physics as normal, in the editor and my program

Does anyone have any experience using the WritePrivateProfile and GetPrivateProfile functions in windows.h? I decided to write an .INI parser and through my research learned of the above functions, I can't get them to work however. I'm not adverse to simply writing the read and write functions from scratch, I thought that's what I'd be doing, but these functions simplify things nicely. WritePrivateProfileString((LPCWSTR)"Section", (LPCWSTR)"Key", "1", (LPCWSTR)"C:\Test.ini"); int result=GetPrivateProfileInt((LPCWSTR)"Section", (LPCWSTR)"Key", 0, (LPCWSTR)"C:\Test.ini"); The above code works to a point, the INI file is located and successfully opened in both cases, but the information in the INI file is never read or written. Example INI file: Test.ini [section] Key=2 ...So does anyone have any experience using the above function set?

I became involved with this project as you say around 1 year ago but as the initial post stated this thread was made at request of the project head. The project itself I quickly discovered was not at a stage where it was ready for collaboration. I've been working with the project head since that date, slowly sorting out the details of what he was after and helping him work through the project in what I consider to be the smartest way. So with that said I have chosen not to write a single line of code until the project has a complete and detailed design which is at a stage where programmers can get involved. As for a detailed update here goes: • Most importantly the project is still in full swing and work has never waned • The project is on so grand a scale that it was decided to initially develop a demo to allow the current members to get used to the ideas and practices of team work within a project of a much smaller magnitude, also a demo will provide something to “show” to attract funding and serious collaborators for the project itself. • The demo plot is finalized • The game play document is finalized • Obviously the engine has been decided upon • Initial concept art for the demo level has been created (we’re all very impressed with this) • The demo’s level design is currently in full swing (thank you Guest_Belfast_*) • The project head is currently seeking a concept artist to work with on designing the demos main character. Now as a demo project was decide upon post my involvement the main game itself already has a finalized and detailed plot ready for when the real development can begin. In answer to the programming specific questions, I am just that, a programmer, so even though I have not put pen to paper so to speak, class designs, hierarchies and possible game modules have been formulating in my head from day one. I won’t give an estimated release date, but the main cause for any delay is, as most of you would already know, is finding the right people who are willing and able to contribute. If half a dozen 3d modelers, concept artist, programmers, etc. came forward tomorrow, hell you might be seeing the demo out within a month, but we all know this does not happen so the project continues along at the pace it can. I’m always around on the forum and happy to talk more but for collaboration offers I think it best to send them straight to the project head “Tom” at, tjpmay @ tpg.com.au

I've made a number of small but significant improvements, download link has been updated. *EDIT* (1.8.10). Final update: I've brushed back up on my C++ and made a few small changes to the class declaration (see below). I've also added an optional method to dynamically change the length of each cable node when the cable is in motion so you should no longer be able to see the cable nodes separate when extreme forces are applied. This method should be called after UpdateWorld(); see new implementation and download below. As I said this will be the final update to the polygonal based implementation, I’m going to try my hand at a particle based implementation in hopes to simulate the cables created in the source engine, stay tuned. CPhysicsCable cable(startPos,endPos,0.05,40,1); cable.Update(); CPhysicsCable.zip

Cheers macklebee, I can't thank you enough, I appreciate it.

To further enhance my Physics rope implementation I was wondering if anyone would be willing to make a capsule model for me. Incase someone does I'll list the specifics I'm aiming for: The capsule will be a total of 1 unit in length, width and height, it will be a hexagon (6 sided cylinder), the flat cylinder section will be 0.5 units in length and the 2 dome ends will be 0.25 units in length each making a cubic capsule model. If this model could be textured then all the better. One important factor is to have the origin of the capsule positioned at the tip of one of the domes. GMF format too. Well heres hoping.

Fixed, cheers.

you are both welcome to the code here. cocopino if you could combine this with your LUA node implementation then I'm sure you'll make the community very happy.

I thought I'd try my hand at making physics based cable (rope), and if I had any success, share it with the community. It's still early days for me with this engine and this was really just a learning exercise, it's by no means perfect, but I did learn a bit in the process, so it’s been worthwhile. Its now up to you more capable individuals to make it even better, perhaps a LUA implementation of the code for the Leadwerks Editor would open up the functionality to a wider range of engine owners. One improvement I can think of would be the creation of a “capsule” model and use that instead of the cylinder implementation. This would also open up texturing capabilities too. Grab the code and with a simple implementation like the one below and you'll be off and flying. #include "CPhysicsCable.h" TVec3 startPos = Vec3(-20,15,0); TVec3 endPos = Vec3(20,15,0); /* Parameters from left to right: cable start position – Vec3 object cable end position – Vec3 object cable thickness – float cable segments (quality) – integer cable free hanging (not attached to the end point) - boolean */ CPhysicsCable* cable = new CPhysicsCable(startPos,endPos,0.5,30,1); If anyone makes any improvements then keep the community up to date.

Something like this? Not done is LUA but in C++, its got a lot of work to make it perfect mind you but I could work on it and pass it onto another forum member to implement into LUA when its done.

I wanted to see if anyone would be interested in making the following simple models: There are 2 models in the request. A flag pole (cylinder) and a flag (plane). Green is geometry Red is a vertex/bone position Blue is a vertex/bone position with a meaningful name The important aspects of the flag are that it has evenly distributed equilateral triangles and a bone positioned and parented to each vertex. Both models should be to the same scale. With the flag model in particular I’m not after a million polygons the lower the number the better (without being stupidly low). They don't need to be textured but they do need to be in GMF Cheers

I'm also experiencing some rendering anomalies. The program: Marleys Ghost's framework example, found here When loading "tunnels.sbx", 90% of the models will randomly disappear whilst "traveling" around inside the tunnels. When loading "train.sbx" the train carriages will disappear when still on screen and when you reach leading engine depending on your height above the ground the train line will also disappear.

Through my learning’s thus far I have come across a difference in the rendered output from 3 different "programs". My findings centre on the “firepit.gmf” model and its associated LUA script and MAT file. Program 1: The Leadwerks Editor (with no post process effects) The heathaze emitter created in the LUA script renders correctly employing an alpha blend even though the MAT file does not. The fire emitter created in the LUA script is very dull and appears to perhaps to be rendering in the main world and not in the transparent world. The fluctuating pointlight created in the LUA script renders correctly. Program 2: My framework free program (with no post process effects) The heathaze emitter renders incorrectly causing visible "tears". This is caused by the heathaze MAT file not employing alpha blending. The fire emitter renders correctly being significantly brighter than in Program 1. The fluctuating pointlight renders correctly. Program 3: Marleys Ghost's framework example found here (with no post process effects) The heathaze emitter renders incorrectly causing visible "tears". This is caused by the heathaze MAT file not employing alpha blending. The fire emitter renders significantly brighter than in Program 2, and eclipsing Program 1. The fluctuating pointlight does not render at all. Any thoughts on the 3 different outputs? I would have thought Program 1 and Program 3 would render the exact same output, as to my knowledge (though admittedly not great) the Leadwerks Editor also creates a framework object. I’m aware that I can edit the “heathaze.mat” file to employ alpha blending for my program but I’m really seeking a greater understanding of the engine here.

Solution found, knowledge gained, thank you.

I spent some time on this today and managed to solve my problem a short while ago so thank you for your replies Lumooja. My next question is: When creating a framework object the scene "tunnels.sbx" which now includes a spiffy "Firepit.gmf" model, will correctly render the heathaze emitter. But when creating the world manually I get the following results: Now it appears that the buffer’s colour component is not being passed correctly to the “texture1” parameter in the "heathaze.mat" file associated with the "Firepit.gmf" model. How does the framework class go about passing this information to the MAT file? As there is no “SetMaterialTexture()” command present in the models associated LUA script.

The more I learn the closer my solution gets to the old Framewerk class which I assume is almost exactly the same as the new Framework class. So I can see your point of view and may one day simply create a Framework object rather than implement it all myself especially if "It doesn't have anything unnecessary in it" as this is my concern. The fact that the old Framewerk class has been permanently incorporated into the Leadwerks engine is a strong indication that this is so. But right now I'm learning the engine so to speak and creating Framework object is going to get me no where, as creating a Framewerk type class is well within the abilities of many Leadwerks license owners, in my opinion. So like I said I'm after the information as to how the Framework class implements the change where my solution does not. As I mentioned it is not part of the assets LUA script, nor does the asset use a material file. So get my ball rolling how does the engine knows that particular model needs to have the colours in its texture intensified to become almost white? It is governed by the colour and intensity properties within the SBX file, values which are used to correctly create a spot light for the model but for me the additional glow effect does not occur. To am I right to say the effect requires a "transparency world"? I’ll continue to make progress myself but I'm sure someone can help speed this up.

I have a program which simply loads "tunnels.sbx" ans enables camera controls. When creating a framework object the scene will adjust the properties of "fixture_hanginglight.gmf" causing the said model to appear to glow. When creating the world manually this change does not take place I'm here to find out why. I know that the change is not created via the assets accompanying LUA script and that the Leadwerks editor the change is governed via the intensity and colour properties. What specific part of the framework class handles this change?

Cheers

I agree that my given example is out of the ordinary and strictly pointless so I shall reword it, identifying the same premise but in a more likely application. Say I have a simple program that loads "tunnels.sbx" and enables simple camera movement. After the player enters the first room on the map I want an in game cut scene to play. This cut scene is written in and controlled entirely by a LUA script. So the question remains how is one to load and execute a LUA script under the above circumstances? (Thinking on this I will examine “switch.lua”) I've looked at many LUA examples and I don't mind adding the LUA dll's to my project but LUA is "integrated" into the Leadwerks engine and the above functionality may already be available without having to add the LUA dll's, or it may not. So my question remains

No ideas on my new question?

Cheers

I have a simple program that loads the scene "tunnels.sbx" and allows simple camera movement. Upon hitting the Escape key to exit the program I'm hit with a warning message box stating "Null Framewerk". This message started appearing after I correctly included the “Scripts” folder in my programs root directory. My program obviously does not use Framewerk or Framework. I could not find the message being invoked within any of the LUA scripts and without having access to the engines source code I feel that it is possibly part of the Terminate() function. Any help in stopping this message being invoked would be much appreciated. And please don't just say “use Framework”.

That’s what it was. The "directory's root" is the same location as the executable, and not the location of the source files as I had mistakenly thought. Very much appreciated. Next question: I'm hoping to gain a better understanding of how "integrated" the use of LUA scripts is in the Leadwerks engine. I'm aware of its use in the LoadModel() command, and the combined use of Engine.exe and the script editor, but how "integrated" is it? A practical example derived from the above code. Say I rename the fixture_cagelight.lua to simply cagelight.lua, The LoadModel() command will fail to locate an accompanying LUA script and therefore the script is not run. The program then enters a loop waiting for the user pressing the "Q" key. Upon pressing the "Q" key how would I then get the program load and run cagelight.lua?

(I reopened this thread in the C++ section as it is more appropriate) This topic will hopefully serve to educate me into where and how the Leadwerks engine implements LUA Scripts. I have spent a few days reading, analysing and testing various situations and I'm seeking confirmations and further education on the above topic. My questions are many and some (in my opinion) quite in depth but to get the ball rolling I'll start small. It is my understanding that the LoadModel() method will, amongst other things, search for an accompanying LUA script to the specified GMF model. So why does the following code not "Draw" the models "alignoncreate" onto the screen? and why is no light created (DebugLights() #include "engine.h" int main(int argc, char** argv) { Initialize(); Graphics(640,480); TWorld world = CreateWorld() ; TCamera camera = CreateCamera(); MoveEntity(camera,Vec3(0,0,-1)); TModel model = LoadModel("abstract::fixture_cagelight.gmf"); DebugLights(true); while(!KeyHit(KEY_ESCAPE)) { UpdateWorld(AppSpeed()); RenderWorld(RENDER_ALL); DrawText(0,0,"%s",GetEntityKey(model,"alignoncreate")); Flip(0); } Terminate(); return 1; }

***TOPIC REOPEND IN C++ SECTION***