Rekindled Phoenix

It did! That solved it! Apparently the method that the Sandbox Editor uses creates PHY files that, for some reason, aren't affected by gravity. Should this be reported as a bug?

Thanks Macklebee, I'm going to try: - new PHY (not generated by Sandbox) - new INI (non-existent) Then if that doesn't work I'll have to update my SDK files. I'll post later when all that is done.

Unfortunately, that doesn't work. (When dragged into the editor, properties mass and gravity are set appropriately, but the object never moves / falls) Look at the script for the fixture_hanginglight object. There is no reference to any include file, though they are used and work correctly. Same goes for the oil drum, which doesn't specify keys at all, yet is initialized with gravity. I'm completely confused...

I'm looking at the Oil drum object, and even the cage lights which are initialized with gravity in the Sandbox editor, and can't replicate the same results! What is wrong with this script? require("scripts/class") local class=CreateClass(...) function class:CreateObject(model) local object=self.super:CreateObject(model) model:SetKey("mass",1) model:SetKey("collision",COLLISION_PROP) -- OR function object:Init() self.model:SetKey("mass",1) self.model:SetKey("collision",COLLISION_PROP) end object:Init() end

Thank you Tyler, those questions have been numbing my mind for the last couple of days.

Hahaha.

Can anyone answer the other questions?

First, I'd like to say thank you for the article. It seems to be very informative, with thorough examples. Though, apparently TheoLogic has valid reasons to think this article is rubbish Please, in the future, could you post this within the general programming forums? Since there is a constant wave of C# bashing and would be best if placed somewhere else where all languages would have equal ground for discussion. I don't think any language wants their flaws picked apart, especially if the programmers using the language already know what they are. Basically what Metatron does every week.

I didn't think that I would have to manually call the garbage collector for a script engine... but whatever works! collectgarbage(collect) should work if I'm specifying the exact objects in quesiton.

I wrote a small bit of code to cycle though a collection of entities and draw lines between their positions. The objects were not creating any new meshes, only drawing and looping through collections. I had the fortunate mistake of leaving my computer on while eating lunch, and encountered an out of memory exception within the Sandbox. So I ask... 1. When is the optimal place to use local? What object datatypes are best, if any? 2. Is it possible calling functions within another function delays the garbage collector? 3. using collection = classnametable["info_pathing_node"], can I call this once and reuse it? Or do I have to create it every loop in case a new object was added? 4. Will calling AddHook() with a function cause a small memory leak over time?

I'd want to be able to create high-end graphics, but change the OpenGL settings to allow for extremely simple graphics for customers with dinosaurs as computers. Vindictus does this by allowing you to choose different DirectX versions (8 didn't support certain texture maps, rending faster)

+3 Maybe adding to the number will get Josh's attention

You can definitely include the source within your own engine. I would highly recommend obfuscating it before public distribution though, since the files are for licensed developers only.

Richard would be correct. You would have to model a sphere, texture it, and make the object a child of the scene Looking through the Leadwerks Wiki, I found the skybox vert-shader shown here. Creating a Skybox

+1 For the suggestion. As a (temporary) alternative, you can take the your models and apply the vegetation shader randomly generating terrain coordinates.

Within C# and Leadwerks.Net Framework.Effects.SkyBox.Material = new Material("abstract::FullskiesBlueClear0016_2_L.mat"); You can also do this easily using the Sandbox editor: - Drag an Atmosphere object into the world - Set your desired material file

Don't forget C# / VB.Net! I would follow Pixel Perfect's advice and make something small, learn the content pipeline, and get a grasp on a programming language that feels the most comfortable.

Suffix your filenames appropriately to represent each model. Straight from the Leadwerks Wiki: "The engine will first look for a mesh of the name or file path provided. It will also load any LOD meshes that are found, indicated by adding the suffix "LOD"n to the file name, where n is the detail level." An example: Rocks_Medium_Stone.gmf Rocks_Medium_StoneLOD1.gmf Rocks_Medium_StoneLOD2.gmf

If you mean within your own application, it is possible. I did a quick Google search found this link with several options regarding resources and embedded DLLs: Embed DLL within EXE One option: ILMerge

Update! Community user Raz found that the AlphaMap class had a legacy index parameter. (This invalid parameter can still be found on the Leadwerks Wiki) This has been fixed, and now will no longer throw a managed pinvoke exception. Feel free to offer your critique, suggestions, and feedback!

+1 bump thread for updated logo

Im sorry this didn't solve your issue. So that you may increase the performance and extensibility of Leadwerks.Net, I will consider adding you as a developer account. PM me once you have an assembla username, with the features you wish to improve

Lua scripts initialize objects, and can set keys. Here is a simple example of how you can do this yourself function class:CreateObject(model) local object=self.super:CreateObject(model) -- Sets default keys object.model:SetKey("SomethingAwesome","1") end

This GUI looks wonderful! I can't get it to work. Could you include / update the appropriate shaders in the RAR file?

There is another solution! Within the DLL.cs file you need to change this: internal static class Dll { private const string ReleasePath = "engine.dll"; private const string DebugPath = "engine.debug.dll"; private const string Path = DebugPath //CHANGE TO DEBUG //ReleasePath; Only downside is that you will need to recompile the C# project library yourself. I will update the library to allow for process-bound debugging.