Canardia

The CameraZoom(factor) function does the same as an optical zoom in real cameras. So CameraZoom(20.0) would be 20x optical zoom.

I tried to SetZipStreamPassword before LoadScene, but it didn't work. In Editor there should also be an option to set the password for each pak file. Well, I could use a thingoid to do it, but then I would need to load a scene with the thingoid before I load the actual scene.

I think LoadScene and Editor should also have an option to use passwords for pak files.

LCP1 crashes with wh1sp3r's and carlb's ATI cards. Wh1sp3r has a 5870. It crashes in RenderFramework(), so there's nothing I can do to fix it, only Josh can. I tried also to downgrade LCP1 from LE 2.31 to LE 2.30, but the same crash happened there also.

You can use ZLib (includes MiniZip): http://www.winimage.com/zLibDll/minizip.html And then you can read a text file into a C++ string: /* unzips testfile.txt from C:\temp\test.zip and puts it in a string */ #include <cstdio> #include <string> #include <iostream> #include "unzip.h" // MiniZip library #define WRITEBUFFERSIZE (5242880) // 5Mb buffer using namespace std; string readZipFile(string zipFile, string fileInZip) { int err = UNZ_OK; // error status uInt size_buf = WRITEBUFFERSIZE; // byte size of buffer to store raw csv data void* buf; // the buffer string sout; // output strings char filename_inzip[256]; // for unzGetCurrentFileInfo unz_file_info file_info; // for unzGetCurrentFileInfo unzFile uf = unzOpen(zipFile.c_str()); // open zipfile stream if (uf==NULL) { cerr << "Cannot open " << zipFile << endl; return sout; } // file is open if ( unzLocateFile(uf,fileInZip.c_str(),1) ) { // try to locate file inside zip // second argument of unzLocateFile: 1 = case sensitive, 0 = case-insensitive cerr << "File " << fileInZip << " not found in " << zipFile << endl; return sout; } // file inside zip found if (unzGetCurrentFileInfo(uf,&file_info,filename_inzip,sizeof(filename_inzip),NULL,0,NULL,0)) { cerr << "Error " << err << " with zipfile " << zipFile << " in unzGetCurrentFileInfo." << endl; return sout; } // obtained the necessary details about file inside zip buf = (void*)malloc(size_buf); // setup buffer if (buf==NULL) { cerr << "Error allocating memory for read buffer" << endl; return sout; } // buffer ready err = unzOpenCurrentFilePassword(uf,NULL); // Open the file inside the zip (password = NULL) if (err!=UNZ_OK) { cerr << "Error " << err << " with zipfile " << zipFile << " in unzOpenCurrentFilePassword." << endl; return sout; } // file inside the zip is open // Copy contents of the file inside the zip to the buffer cout << "Extracting: " << filename_inzip << " from " << zipFile << endl; do { err = unzReadCurrentFile(uf,buf,size_buf); if (err<0) { cerr << "Error " << err << " with zipfile " << zipFile << " in unzReadCurrentFile" << endl; sout = ""; // empty output string break; } // copy the buffer to a string if (err>0) for (int i = 0; i < (int) err; i++) sout.push_back( *(((char*)buf)+i) ); } while (err>0); err = unzCloseCurrentFile (uf); // close the zipfile if (err!=UNZ_OK) { cerr << "Error " << err << " with zipfile " << zipFile << " in unzCloseCurrentFile" << endl; sout = ""; // empty output string } free(buf); // free up buffer memory return sout; } int main(int argc, char *argv[]) { string string_buffer = readZipFile("C:/temp/test.zip", "testfile.txt"); cout << string_buffer << endl; return 0; }

I don't know why most textures which come with the SDK have these horrible 4x4 pixel squares. It's not a issue with DXT5, since you can take a 4x4 pixelated texture and blur it in Paint.NET, and then it looks much better. However, to get the pixel sharp details, you need to have the original texture, which you can then save as DXT5 from Paint.NET without getting those 4x4 pixel squares.

There are 2 control keys, which one do you mean? See in the constants/keycodes.lua for a full list of key codes: like KEY_LCONTROL Or actually, you should always use Wiki when possible: http://www.leadwerks.com/wiki/index.php?title=Input#Keyboard

TD could be in level3 of LCP1, I've thought about that also. After all, originally TD was just one level in WC3 anyway.

I think the houses have crazybumped normal maps. I have tried many times to get better looking textures with normal maps, but so far I think the best looking textures use only diffuse, nothing else.

I can then copy back your class to gamelib 0.1.0.0, if you make it free for registered LE users, because that's the way gamelib is a community project

I tried coronas and many other methods first also, but ended up with the current 3D plane method as it was the only way to get it working.

I would use Scene::AddNameTag(entity,"sometext") from gamelib, and make a modified version of it, as a class, where you can change the text in realtime.

Not only on creation, but you can also read it from the sbx file.

The default value of 0.5, 0.5 is OK. If you make it 1.0, 1.0, the objects will grab to the ground as if they had spikes, and with 0.0, 0.0, they slid like on ice.

The LEO in LE 2.31 has some old files. To fix it, copy the following files from LE 2.30 to LE 2.31: - leoFramework.h - leoLayer.h - leoRenderer.h

Bah, you only put positive comments on your game web page, why not the critics too?

I think it's bad programming style to put anything after the final } of the class definition. Sometimes you create unwanted self-launching global variables with that, which should not be launched before other things have been initialized. I would not create any global variables (=objects), but keep them inside the main() function scope, and use class pointers inside classes if you need one class to talk with another.

I would just walk the controller inside the car, and have somekind of arresting mechanism to hold the controller in place. For example put some invisible physics cubes around the controller when he is inside the car, so he will move when the car moves.

You can set the camera far range to 50000 in the Athmosphere entity. Then things don't fade out so early.

It seems that lights don't cast shadows when they are near an object. You can see that in the shadow of the light cage half of the shadow is missing: I know I could make the cage bigger, but it's really not that small, and it's a realistic size.

Although the engine has no GetTerrainResolution() function, you can easily do it yourself, like in gamelib: http://www.leadwerks.com/wiki/index.php?title=GameLib#GetTerrainResolution

To get an understanding of this person, you should read this article: http://www.escapistmagazine.com/news/view/94711-Bobby-Kotick-Wants-to-Take-the-Fun-Out-of-Making-Games It's nothing against Activision, just one man who just happens to have this job.

It's a problem of your ISP's cache server (someone using the same ISP as you probably started downloading it, and then aborted the download). You could try to add some random string to the URL to fool the cache server and get a new instance of the downloaded file. I added manually a random string to this: http://leadwerks.com/werkspace/index.php?app=downloads&module=display&section=download&do=confirm_download&id=98&rnd=1283128312383128

I agree 100%, I have also many engines, but I don't use them because they don't have entity programming. The only exception is Blitz3D which I also have, but it doesn't have shadows and physics, so I use LE instead. I even asked in the forum of another pretty decent engine if it could be used in entity way, but they said it would require major changes. Which makes me wonder how on earth can something even work decently without entity programming. It must be complete spaghetti code and needing rocket science to even turn an entity (using quaternion maths) One of the biggest benefits of entity programming is that you don't need mathematics at all. You only use vectors and pivots and tell how to turn, move, scale, parent, etc... them.

GameLib 0.0.19.0 is ready. See the release notes here: http://leadwerks.com/werkspace/index.php?/topic/483-leadwerks-community-gamelib/ It has been tested with LE 2.31, but LE 2.0 should still work with it, although I don't have time to test it with LE 2.0. What can I say, it's the best version so far The next version will be 0.1.0.0, as it's finally used for a game project (LCP1). The version point raise to 0.1 means also that everything should work as it is, and it can be integrated with any game, while you can always escape to all other engine layer commands at any point (procedural C++, OOP LEO). The trend is going to have more seperate class files instead of a monolithic source code, and it was already started with version 0.0.18.0. This allows users to use their completely own versions of cpp class files while not needing to alter the main gamelib source at all.