Jump to content

Search the Community

Showing results for tags 'lua'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Categories

  • Models
    • Animals
    • Barriers
    • Characters
    • Containers
    • Environments
    • Furniture
    • Props
    • Rocks
    • Vegetation
    • Vehicles
    • Weapons
  • Materials
    • Brick
    • Cartoon
    • Decals
    • Dirt
    • Grass
    • Industrial
    • Medieval
    • Metal
    • Plastic
    • Plaster
    • Rock
    • SciFi
    • Sky
    • Signs
    • Tile
    • Stone
    • Walls
    • Wood
  • Scripts
    • GUI
    • Object
    • Utilities
  • Shaders
    • Post-Processing Effects
    • Surface
  • Sounds
    • Ambience
    • Effects
    • Music
  • Tools
  • BATTLE LEAGUE's Assets
  • BATTLE LEAGUE's Mods

Blogs

There are no results to display.

There are no results to display.

Forums

  • Leadwerks
    • Technical Assistance
    • General Discussion
    • Programming
    • Game Art
    • Suggestion Box
    • Bug Reports
  • Platforms
    • Windows
    • Mac
    • Linux
  • Community
    • Showcase
    • Promotion
    • Off-topic
  • BATTLE LEAGUE's Topics
  • Vec-Tec's Releases
  • Vec-Tec's Topics
  • Forth's Development
  • Forth's Game design
  • Forth's Graphics
  • Forth's Documentation
  • Forth's TODO
  • Forth's IMPORTANT
  • Forth's Screenshots
  • The uncertain world's Game Design
  • The uncertain world's Programming
  • The uncertain world's TODO
  • The uncertain world's Graphics
  • The uncertain world's Screenshots

Categories

  • Records
  • Entity
  • Command Reference
  • Vec3
  • Vec4
  • Script Reference
  • Shader
  • Index
  • Material
  • Object
  • Buffer
  • Asset
  • Font
  • Shape
  • Sound
  • Texture
  • App
  • Context
  • Model
  • Light
  • DirectionalLight
  • PointLight
  • SpotLight
  • Attractor
  • Camera
  • Emitter
  • Listener
  • Pivot
  • Bone
  • Sprite
  • FileSystem
  • Key
  • Source
  • Surface
  • Math
  • AABB
  • dVec3
  • Mat3
  • Mat4
  • Plane
  • Transform
  • Vec2
  • Vec3
  • Vec4
  • Mutex
  • Prefab
  • PickInfo
  • Map
  • Stream
  • System
  • Thread
  • Time
  • Window
  • World
  • Driver
  • SoundDriver
  • GraphicsDriver
  • PhysicsDriver
  • OpenGL2GraphicsDriver
  • OpenGLES2GraphicsDriver
  • OpenALSoundDriver
  • NewtonDynamicsPhysicsDriver
  • Draw
  • Color
  • Blend
  • Joint
  • Debug
  • Component
  • Steamworks
  • LensFlare
  • Vehicle
  • Decal
  • Quat
  • Leaderboard
  • Probe
  • Analytics

Categories

  • Games

Product Groups

  • Software
  • Gear

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Location


Interests

Found 362 results

  1. I'm working on a game engine and winging it as i go along, now i realize this leaves me open for flack from the more seasoned programmars here, but i figured it best to start somewear and go on the advice that people can offer. And if they can provide test code, it will give me something to go on, an encentive. I've started work on the engine but i've hit a snag. #include<iostream> using namespace std; int main() { /*Initializes the main world, before loading entities, physics, etc...*/ int WORLD_MAIN; /*Initializes the default physics designed for the game*/ int INITIALIZE_PHYSICS; /*Initializes the environment, sounds, lights, wind, water splashing, etc..*/ int INITIALIZE_ENVIRONMENT; /*Initializes the world, after checking to makesure everything is in it's default place*/ int INITIALIZE_WORLD; /*Initializes the shaders in the world*/ int INITIALIZE_SHADERS; /*Initializes the scenery, after first initializing world_main, physics, environment, world, shaders, then scenery.*/ int INITIALIZE_SCENERY; /*Initializes the camera in the game*/ int INITIALIZE_CAMERA; /*Initializes the game sound and audio in the game*/ int INITIALIZE_AUDIO; /*The idea for this part of the code, is to create a checker. Which checks through WORLD_MAIN for any errors It's also the first file to be initialized when executing. So this line of code might be edited to fit it's purpose*/ cout << "This may take a few minutes, please be patient\n"; cin >> WORLD_MAIN; cin.ignore(); cout << "Ready!" << WORLD_MAIN; << "\n"; cin.get(); } This code more specifically. /*The idea for this part of the code, is to create a checker. Which checks through WORLD_MAIN for any errors It's also the first file to be initialized when executing. So this line of code might be edited to fit it's purpose*/ cout << "This may take a few minutes, please be patient\n"; cin >> WORLD_MAIN; cin.ignore(); cout << "Ready!" << WORLD_MAIN; << "\n"; cin.get(); The idea behind that specific line of code, is to create an initializer. That checks to see if all the variables are set to their default setting. I think what I'm doing currently is only setting the code up to paste some text to the command screen, this code will be changed if I'm forgetting some variables or integers.
  2. ChrisMAN

    Lua Emitter

    I have abstracting a component of my gui library out for general consumption. https://github.com/friesencr/lua_emitter Fork and publish issues. OSS <3 It allows for simple event communication between objects. Check out the readme. If you want a similar experience as SendMessage but with a small decoupled object. Try emitter!!! I will be creating a promise system for lua which will allow for a really nice asynchronous story over the next week. A deferred value system is vastly superior to a system where the server takes callbacks. I find that dealing with certain problems using events and callbacks clearly states the problems and therefore simpler solutions. STATE MACHINE Y U NO EVENTS. Thanks, Chris
  3. If you are using lua and not using underscore you are probably doing it wrong. It is the only sane comprehensive set of utility functions I have found. Gives you alot of nice iterators, some OO facilities, some functional programming. If you have used other languages and miss nice things this gets you closer. http://mirven.github.com/underscore.lua/ Check it out. Hate lua less. I did have a problem with the module export. I manually aliased the '_' to Underscore require 'scripts/underscore' local _ = Underscore:new()
  4. Some screens of the prototype from a moody, maybe fabulous environment. Wanna have a lot of space and many vegetation-objects. Frames are great so i could concentrate now on more types of trees, further details in foreground like rotten stumps, branches and other gnarly matter. Wanna reach an including atmosphere - life breathing audio-visual environment. Next step will be a more deeply instruction to LUA (i´m generally new to coding) - to develop scripted, environment depending AIs for example animal classes. Simple a wolf class, deerlike´s, an eaglelike and a few fishs in some tarns. all the best
  5. I just finished uploading the framework so that some friends can help out with the content and scene. I already have the overall theme and game put together, I just have to make them, and in this case get help with converting models, creating materials, and so forth. The framework is going extremely well. I've been working on it more than I should be to be honest but I did spend most of the day on the important matters. Plus it's Sunday for crying out loud. Anyways, I've changed several things about the framework. Here is a brief overview: Configuration is now available in the engine. This provided the gateway to the rest of the features I had plan for the framework, such as key/mouse binds, and generic configuration information for both the "engine" and "game." The key/mouse bind configuration file looks similar to: forward=w backward=s left=a right=d jump=space leap=lshift+space crouch=c | toggle fire=leftmouse aim=rightmouse grenade_toss=middlemouse | release grenade_cook=middlemouse debugphysics=f6 | toggle use=e It's fairly straight forward but the configuration file can contain basic instructions, such as "release" and "toggle." The configuration class itself provides the rest of the support. Examine the following, which is now accessible to Lua: if input:hit("leftmouse") == 1 then -- fire logic end if input:hit(input.get("use")) == 1 then -- use logic end if input:toggle("crouch") == 1 then -- do crouch end The engine configuration is managed with: config.get("resx") The game configuration is managed with: game.get("difficulty") One last feature I've added is a way to change between behaviors. These behaviors are strictly Lua, a hybrid, and strictly C/C++/C#/BlitzMax. If you provide the file "engine.lua" into the root of the project, the framework will only execute that LUA file after creating the graphics context and managers (config, input, game, etc.). The "hybrid" is a mix of the two. The framework calls upon specific Lua files at specific times. They could be looked at like "hooks." The Lua files are located at: "/scripts/dice" Examples are "update.lua" and "flip.lua." The framework also now handles scenes. It allows Leadwerks to process the scenes at the moment but then each entity in the scene to turn into an actor by the framework. This way you can get any actor: local actor = engine:getactor("myEditorAddedActorName") actor:translate(vec3(0,0,0)) actor:setkey("health", 20) Actors have their own Lua files and due to the structure described above we should be able to swap Lua files on the fly. The plan I will be attempting is similar to the following: local actor = engine:getactor("myactor") actor:setscript("newscript.lua") actor:runscript() I assume it will work, but who knows. Since per entity/actor scripts work the flexibility with the framework is fairly polished. I'm starting on default controller mechanics, soon to get into third person characters, and so on. Once my buddies can help me out I'll have more to test mechanics. Everyone should also check out Scarlet Thread Studios work, it looks to me like an RTS/TPS style framework, similar to Diablo series. Slight modifications can turn that into an RTS, FPS/RTS, and so on. Same with Pixel Perfect's engine Neutrino, which utilizes EKI One, and is turning out fantastic. I've bugged him to lease it but he isn't budging. Sorry everyone, lol. Just playing, Pixel. MG, always awesome work. Thanks for joining up to help with the content. Macklebee, hoping you'll come aboard and help me out with Lua. I'm really not in the mood to fully learn Lua at the moment. I plan to stick with hard-coded mechanics, lol. Read the above, it explains how to force the framework to let Lua control the main loop. Figured that would be your expertise. Awesome hangout session. I never planned to make it, thought it was out of my schedule, so it was kind of unexpected, lol. I had to register with Google+ and everything. It was fun, meant to talk about more, and to everyone else instead of just Josh, but I had to go AFK; turned out to be too long. I hope I'm invited to the next hangout but I don't have a camera. Thanks for reading.
  6. I thought I'd spend a little more time on this integration, using the laptop whilst watching the Olympics. The next phase was to automate the routines for NPC update and compacting the code routines. Ultimately, the idea is that after the scene is loaded, it will be parsed and flagged Dark AI objects, NPC's, Paths and Zones will be set up automatically via information taken from the relative lua scripts. Paths and Zones will be later, collision objects are done, so I was working on how to go about NPC's using this method. As some may have noticed I am using the FPSC Model Pack 53 characters. I converted about 5 or 6 characters to Leadwerks format and all the weapons for this exercise. I will eventually convert them all but I hand "prune" the bones of the rig and that takes longer than I want to spend at any one time on this side project. The FSM is still very basic but the first goal was to derive a current Animation state with each of those states having sub-FSM's to dictate the current behaviour based on the previous state and internal and external inputs. The framework is in place for the animation state which is derived by performing Boolean logic on returned values and strings from the Dark AI runtime and some stubs are in place nested inside for some basic behavioural sub-FSM's. First though I want to able to set up the scene and then place all the Dark AI objects, NPC's, Paths and Zones directly in the editor and then use the load routines to set all that up in an automagic way inside the application. The collisional objects were easy and are done with some simple tick box flagging functionality added to their property scripts. The NPC's a little more in depth , due mainly to the large amount of usable settings! lol. But I wanted to be able to place the model and then assign it some basic attributes to be read on load, this included what weapon to attach. So that was the basic NPC property script setup (wasn't that painful anyway). So using the test scene from Leadwerks 2.5x + DarkBasic's Dark AI [Part 2], and placing a few enemies and some friendly's to look after the player, this is the result of the current stage reached in the integration.
  7. Paul Thomas

    And, Hello

    There are several here who already know me, but for those who don't, my name is Paul Thomas. I've been programming for a long time now; I started when I was 16 (I'm now 30) with HTML, CSS, Javascript, and CGI/Perl. Hell back then there wasn't a lot of people who even used the internet at home, lol. At least in my area, I'm sure others, especially in California, were a lot further ahead at that time in terms of technology and the interest in the technology. Through the years I've learned multiple languages from strictly web-based to software based. My interest in computers when I was 16 was to make a game, but at the time I thought it would have been much easier to prototype the whole idea in a web-based browser game. I had completed the browser game, which was the original "Eternal Crisis," and worked nicely. My plan was to update the entire web-based system, polish everything, and officially advertise (I had invited friends to play the game). That's when I learned about a "fried hard drive" and eventually learned about "backup" and how to install a hard drive. Those whom already know me, know what Eternal Crisis is, and my Blogger shows some of the history on that project. I had taken that project, along with another, over to Unreal Engine 3 because it best suit the project. Along the years of learning that engine I was using LE for prototyping ideas and so forth. While I'm not working on my own engine (temporarily titled "3D Dice"), FPS/RPG framework for UE3, or R.A.T.S., I work on my framework for Leadwerks Engine 2.5. I've never shared this framework before, in fact it always felt like I had to pull it out of a shallow grave each time I added to the framework design and programming. I'm a notebook junkie, I plan out mechanics, structures, and so forth on paper, before going over to digital. Old habbits that die hard I guess. Now I felt like sharing the progress, which isn't a lot, but it's a great start to me. It's a great start to me because it actually runs, lol. The state of the framework isn't even close to the final planned and written design, but progress is progress. Always move forward until it's finished, even if you can only pick that project up once every two weeks (by then I/you should probably take a look at your workload and fix it instead of attempting such project schedules; however this isn't vital to me and rates low on my importance scale), if it's updated then progress is moving forward. This is also harder to work with if you don't plan your software before actually programming (unless it's routine for you with available libraries for shortcuts in development). As most programmers should know, the programmers "update" isn't as glamorous as an artists "update" as it's not about visual stimulation but overall program/software flow. In the case of my LE framework (obviously untitled) it's all about providing mechanics and how that is achieved is important especially in the case of LUA access and how everything works together; from configuration/data management, to input binding, and all the way down to AI. Until occupied again by my other tasks I will eventually share the entire framework structure and I will always be showing examples of syntax; cause that's what programmers do. Just to clear the obvious questions that may come from the community: Q) Do I plan to give away code, the framework, and be an open source kind of person? A) No, not really. First of all, you would have to wait, to anyone else at the moment the framework is as useful is a partially finished library. How long you would have to wait would depend on how much time I can spend on the framework and in all honestly it's not much at all (read above, and actually read). Q) Do I plan to sell or lease the framework? A) No, don't think so. I even think that's against Leadwerks terms since it could be deemed an "FPS Creator," which is definitely in the terms. Q) Is my framework really that great? A) Nah, I mostly ramble, and I'm actually writing this to share with long time friends here at Leadwerks. Some won't even visit anywhere else to communicate because they are so used to using Leadwerks for that; it is indeed where we all met. Q) Who are my friends? A) I have none, it was a lie. Now, about this framework. This "framework" isn't the same, exactly, as the framework that comes with LE. The framework that comes with LE handles some dirty work for you when it comes to creating the worlds, cameras for those worlds, shader effects, and helper functions. The framework I'm designing is technically similar to a game engine. I personally consider Leadwerks Engine as a rendering API with physics and this framework uses that rendering API and provides mechanics. The mechanics the framework provides is what makes up the detail of the framework. INI SQL Application Graphics Game The above are considered "managers" in that they only handle what they should be managing. The "INI" only works with INI files, such as a configuration manager. The "SQL" only works with SQLite3, providing helper functions for easier SQL management, and so forth. There are more planned managers than the above, but these are what are completed in terms of programming. The only real interesting portion to discuss about the framework is within the "Game" manager itself. The game manager provides two special classes/managers; "Object" and "Actor." Actor inherits everything about an Object. What defines an Object is a game entity that is never interacted with by the player. Objects are useful as it can be used for multiple purposes without consuming a lot of resources for each "component" or "plugin" I'd like to add onto the framework. For example, a Timer would be an Object. You don't interact with a Timer in a game, but there is a timer running in the background. Example: class ETimer : public EObject { public: ETimer(void); virtual ~ETimer(void); void Initialize(void); void SetTimer(float StartTime); void StopTimer(); }; While working with the framework you would do something similar to: // EGame::EObject // EGame::Objects EObject Objects; // .. ETimer Timer; Objects.Add("Timer", Timer); // .. ETimer Timer = Objects.Get("Timer"); Timer.StartTimer(0.0); // .. Timer.StopTimer(); // inherited by EObject Timer.Unload(); An Actor inherits everything that defines an Object. The difference between the two is that an Actor is something that a player could see, hear, interact with, or can move, rotate, and so forth. If you can see how this is all going, everything starts extending the Actor, such as the character, weapon, or items. Here are some examples of working with Actors in the framework: // EGame::Actors Actors.Add("oilbarrel", "oilbarrel.gmf"); // .. Actors.Rotate("oilbarrel", vec3(10.0f, 0.0f, 10.0f)); // .. Actors.Translate("oilbarrel", vec3(10.0f, 0.0f, 0.0f)); // .. EActor barrel = Actors.Get("oilbarrel"); // rotate with interpolation barrel.Rotate(vec3(1.0f), 0.1f); barrel.Translate(vec3(0.0f, 1.0f, 0.0f), 0.1f); // .. EActor Barrel; // new name Barrel.Name = "barrel01"; // new mesh Barrel.LoadMesh("oildrum.gmf"); Actors.Edit("oilbarrel", Barrel); A quick overview of an Actor: //EActor ID Name Tag Parent Location Rotation Mesh Sounds Particles Each Actor can also have children which are also Actors. This provides another version of parent/child relationships but also provides additional benefits which will be discussed in later blogs. The ID and Name variables are provided by Object and the Object provides more variables, but is listed for importance. When creating an Actor it is automatically tagged for unique identification. In the above example "oilbarrel" is actually stored as "oilbarrel_0" and simply incremented for each Actor that is created. This is identified by the Actors "Tag". The "Name" variable is a forced name, therefore searching for an Actor by the name, with more than one Actor having the same name, the first result is returned. Actors will be automatically created properly for each entity in a scene. The framework will be using a custom scene manager and handles initial Actor creation. Programmers/Scripters can then add to the Actors list with C++ or LUA like the above examples. class MyGame : public EGame { public: void Load(void); void Update(float DeltaTime); // .. void MyGame::Load(void) { Actors.Add("custom_actor", "mymesh.gmf", "force_tag_name"); EActor actor = Actors.Get("custom_actor"); EActor actorCopy = Actors.GetTag("force_tag_name"); actor.Translate(vec3(0.0f)); } void MyGame::Update(float DeltaTime) { EActor actor = Actors.Get("custom_actor"); // interp move with speed and threshold option actor.Move(vec3(10.0f), 1.0f, 1.0f, 0.35f); } }; In upcoming blogs, when I do get the time, I'll post up some videos. Those selected for the invite only alpha testing will get their information on how to use the framework. Friends of mine that didn't get an invite and are interested in alpha testing please private message me; I most likely didn't send you the information because I figured you were busy with your own project(s). Well, out of time. Thanks for reading.
  8. I wish to implement my own set of Entity Types when assigning EntityTypes in the editor; as the currently provided ones in the properties system don't meet my requirements. Am I correct in the following assumptions: The properties combo box simply returns an integer representing the entry position of the chosen type which is output as the collision type in the sbx file. The collisions defined in the collisions.lua file are then implemented based on the constants defined in the collision_const.lua file So all I would need to do is redefine the set of Entity Types for the combo box in base1.lua and add my own constants and collision definitions? I assume the Engine implements this in the same way as the Editor.
  9. If you are thinking about using Dark AI as a cheap option for an AI solution and are wondering how to use both LE2.5x and Dark AI together then I suggest the best way to think about how to interface the two, is to think along the lines of how EKI One works, where you have two parallel but identical worlds running at runtime and the interface is the channeling of information between "identical twins" with one twin in the "AI world" and the other in the "Game world", that is what one "twin" is doing in the "AI world" the other is mirroring in the "Game world", the interface merely opens a line of communication between them so they know what each other are up to. The "Game world" is the physical world in which the player interacts, but the "AI world" is merely a "ghost world" that overlays it. Sounds more complex than it really is. Most of the commands for Dark AI relating to collision objects can be used, except the couple that relate specifically to DBobjects and levels. None of the debug commands are of use as they will probably rely on a DX7/DX9 drawing context and not an OpenGL one like LE2.5x. The good news, the other 128 commands should all work via some good interfacing, which will require a good working knowledge of the LE API and a good understanding of what those Dark AI commands actually do. Although there are some automatic behaviours from which information can be retrieved and used in the interfacing to LE, the best option I would think is to create NPC types/classes and use FSM's in conjunction with the Dark AI command set to create behaviours, it gives more control and should allow a higher level of complexity in behaviour. Just remember, you get what you pay for! You can download a demo of Dark AI working in DarkBasic Pro here, should give you some idea of what to expect. Of course, NPC entities (and objects) can all be tied to the integration with lua scripting allowing placeholder placement in the editor, with settings and values passed to the application for each when loading the scene. As I said this was just an hour and half's work, an experiment to see if it could be used. Blog entry: http://www.leadwerks...-dark-ai-daile/ Demo of DAILE WASD to move the player, mouse look, mouse wheel to zoom in and out. Note: There is no physics collision between the player and the obstacles, this is intentional and was used to check the virtual boundaries worked with the NPC's (that is, although the player could pass through them the AI had to plot a course around). NPC1-3 : Freindlys that will follow the player and defend him. NPC4 : Enemy that defends the circled zone when the player enters it. NPC5-6 : Enemies that are set to chase and attack (and search for) the player and his allies. NPC7-15 : Neutrals who will just move about.
  10. I am currently working with EKI One, working through its format and structure, getting to grips with the lua behavioural scripting side and trying to brush up on my c++ skills, actually brushing up on my c++ skills is an overstatement as I don't actually have any to brush up! .. lol, I have also been going through my Blitzmax code and trying to compile all the game mechanic functions and methods into a single .mod, trying to keep things tidy. Whilst going through my **** drive, I mean, my well organised storage drive, I found some DarkBasic/DarkGDK stuff, which included the Dark AI library. I have never really used DarkGDK, although I did start out a few years back with DarkBasic. So I wondered (as you do), could it be utilised in LE2.5? Having never used Dark AI (which came in a bundle, that I have never used either, but it was a bargain lol) I knew that R.T.F.M. would be in order. If it relied solely on DBobjects and inherent DarkBasic functionality then probably not. I spent half an hour looking through the commands, and an hour later had it working in an LE context. So to answer the question, it seems you can. I'd have upped a better quality image but I am told "You can upload up to 7.74K of files " Its all a work in progress, and probably will remain that way as its certainly nowhere near the solution that EKI One is, but as an exercise it wasn't a bad use of a few hours. I will post a demo in the showcase later for those interested. EDIT : Demo posted here : http://www.leadwerks...-ai/#entry45564
  11. After the first hour and a half I spent on this little exercise, I followed it up with another couple of hours. The basic integration now has an animation FSM. All still pretty crude and basic but a template to build on at some later date. The NPC's Entity script controls the models animation routines and gun attachment, the c++ application interfaces with the Dark AI library, and then uses messaging to communicate with the NPC Entity via lua script. Again this was just more experimentation and practice for me using c++ to build up techniques that will be beneficial later. Special thanks to Pixel Perfect for pointing out the error in my ways with regard to text strings in c++. Anyway this is the result, I just threw in some values for speed and animation blending off the top of my head just to test the FSM functionality, it will need those tweaking, thats for sure. I'd have posted some pictures, but I seem to only have 7k of space left in the blog section, not sure why, as it was over 200MB last time I did an entry here and not just a link to an entry on my off site blog.
  12. from switch.lua - does this actually mean something or is it outdated... function object:Reset() self.model:SetKey("active","0") self.model:SetKey("valuetouse","1") self.model:SetKey("keytoset0","active") self.model:SetKey("arguments","self.active") self.model:SetKey("message0","Run Code") self.model:SetKey("message1","Activate") self.model:SetKey("reloadafterscript","1") self.disable = 0 end thx
  13. I can see that the choice made in the Editor Options dialog are saved to Editor.ini. Now I'm trying to find out which LUA command each option line in Editor.ini corresponds to. Anyone that can help me with filling in the blanks? Editor.ini LUA Command Trilinear_Filter TFilter Anisotropic_Filter AFilter FOV ??? TextureQuality SetTextureQuality Physics_Quality SetPhysicsQuality modeldetail ??? ShadowQuality SetShadowQuality reflectionquality SetReflectionElements VerticalSync Flip terrainshadows ??? grassshadows SetVegetationShadowMode (exist in C++, not in LUA??? ) Godrays SetGodrays SSAO SetSSAO Antialias SetAntialias HDR SetHDR Bloom SetBloom DOF SetNearDOF or SetFarDOF ??? doffarrange SetNearDOFRange or SetFarDOFRange ???
  14. I wrote a 3x3 grid of planes treadmill. Currently the whole grid is repositioned if the camera would exiting the range of 1 tile size (from center to center). Obviously that just works if the camera if following n/s/w/e exactly (the tilable texture dictates) - if going diagonal the camera is located between the tiles and repositioning does "snap" the view/grid to the center of the treedmill again (very noticable because of the tilable texture). question : How do i rewrite the grid repositioning to find the exact opposite point ? currently : require("scripts/class") require("scripts/constants/collision_const") local class=CreateClass(...) function class:CreateObject(model) local object=self.super:CreateObject(model) -- Load all the parts for the 3x3 grid -- & setup --[[ \ | / patch 1, 2, 3 - o - patch 4, 5, 6 / | \ patch 7, 8, 9 -- --]] local oldViewPos local newViewPos local patchPos local viewLevel = -1.0 function object:Init() patchPos = Vec3(0,0,0) patchPos.y = patchPos.y + viewLevel self.model:SetPosition(patchPos) oldViewPos = self.model.position newViewPos = fw.main.camera.position -- preSetup w/o update -- self.treadmill_patch1:SetPosition( Vec3(patchPos.x-340, patchPos.y, patchPos.z+340), 1) self.treadmill_patch2:SetPosition( Vec3(patchPos.x, patchPos.y, patchPos.z+340), 1) self.treadmill_patch3:SetPosition( Vec3(patchPos.x+340, patchPos.y, patchPos.z+340), 1) self.treadmill_patch4:SetPosition( Vec3(patchPos.x-340, patchPos.y, patchPos.z), 1) self.treadmill_patch5:SetPosition( Vec3(patchPos.x, patchPos.y, patchPos.z), 1) self.treadmill_patch6:SetPosition( Vec3(patchPos.x+340, patchPos.y, patchPos.z), 1) self.treadmill_patch7:SetPosition( Vec3(patchPos.x-340, patchPos.y, patchPos.z-340), 1) self.treadmill_patch8:SetPosition( Vec3(patchPos.x, patchPos.y, patchPos.z-340), 1) self.treadmill_patch9:SetPosition( Vec3(patchPos.x+340, patchPos.y, patchPos.z-340), 1) end object.treadmill_patch1=LoadModel("abstract::treadmill_patch1.gmf") object.treadmill_patch2=LoadModel("abstract::treadmill_patch2.gmf") object.treadmill_patch3=LoadModel("abstract::treadmill_patch3.gmf") object.treadmill_patch4=LoadModel("abstract::treadmill_patch4.gmf") object.treadmill_patch5=LoadModel("abstract::treadmill_patch5.gmf") object.treadmill_patch6=LoadModel("abstract::treadmill_patch6.gmf") object.treadmill_patch7=LoadModel("abstract::treadmill_patch7.gmf") object.treadmill_patch8=LoadModel("abstract::treadmill_patch8.gmf") object.treadmill_patch9=LoadModel("abstract::treadmill_patch9.gmf") object.treadmill_patch1:SetCollisionType( COLLISION_SCENE, 0 ) object.treadmill_patch2:SetCollisionType( COLLISION_SCENE, 0 ) object.treadmill_patch3:SetCollisionType( COLLISION_SCENE, 0 ) object.treadmill_patch4:SetCollisionType( COLLISION_SCENE, 0 ) object.treadmill_patch5:SetCollisionType( COLLISION_SCENE, 0 ) object.treadmill_patch6:SetCollisionType( COLLISION_SCENE, 0 ) object.treadmill_patch7:SetCollisionType( COLLISION_SCENE, 0 ) object.treadmill_patch8:SetCollisionType( COLLISION_SCENE, 0 ) object.treadmill_patch9:SetCollisionType( COLLISION_SCENE, 0 ) --parent all parts to form the model -- object.treadmill_patch1:SetParent(object.model) object.treadmill_patch2:SetParent(object.model) object.treadmill_patch3:SetParent(object.model) object.treadmill_patch4:SetParent(object.model) object.treadmill_patch5:SetParent(object.model) object.treadmill_patch6:SetParent(object.model) object.treadmill_patch7:SetParent(object.model) object.treadmill_patch8:SetParent(object.model) object.treadmill_patch9:SetParent(object.model) --object handling will now be performed relative to its parent -- object.treadmill_patch1:SetPosition(object.model.position, 1) object.treadmill_patch1:SetRotation(object.model.rotation, 1) object.treadmill_patch2:SetPosition(object.model.position, 1) object.treadmill_patch2:SetRotation(object.model.rotation, 1) object.treadmill_patch3:SetPosition(object.model.position, 1) object.treadmill_patch3:SetRotation(object.model.rotation, 1) object.treadmill_patch4:SetPosition(object.model.position, 1) object.treadmill_patch4:SetRotation(object.model.rotation, 1) object.treadmill_patch5:SetPosition(object.model.position, 1) object.treadmill_patch5:SetRotation(object.model.rotation, 1) object.treadmill_patch6:SetPosition(object.model.position, 1) object.treadmill_patch6:SetRotation(object.model.rotation, 1) object.treadmill_patch7:SetPosition(object.model.position, 1) object.treadmill_patch7:SetRotation(object.model.rotation, 1) object.treadmill_patch8:SetPosition(object.model.position, 1) object.treadmill_patch8:SetRotation(object.model.rotation, 1) object.treadmill_patch9:SetPosition(object.model.position, 1) object.treadmill_patch9:SetRotation(object.model.rotation, 1) function object:Update() local distance local range = 340 patchPos = fw.main.camera:GetPosition() patchPos.y = viewLevel distance = PointDistance(oldViewPos, newViewPos) print(" distance : ", tonumber(distance) ) if ( distance > range) then print("exiting range : ", tonumber(distance) ) -- ?! -- ?!self.model:SetRotation(Vec3(0,self.model.rotation.y+fw.main.camera.rotation.y,0), 1) -- ?! patchPos.x = newViewPos.x-range patchPos.z = newViewPos.z+range self.treadmill_patch1:SetPosition( patchPos, 1) -- ?!self.treadmill_patch1:SetRotation(Vec3(0,fw.main.camera.rotation.y,0), 1) patchPos.x = newViewPos.x patchPos.z = newViewPos.z+range self.treadmill_patch2:SetPosition( patchPos, 1) -- ?!self.treadmill_patch2:SetRotation(Vec3(0,fw.main.camera.rotation.y,0), 1) patchPos.x = newViewPos.x+range patchPos.z = newViewPos.z+range self.treadmill_patch3:SetPosition( patchPos, 1) -- ?!self.treadmill_patch3:SetRotation(Vec3(0,fw.main.camera.rotation.y,0), 1) patchPos.x = newViewPos.x-range patchPos.z = newViewPos.z self.treadmill_patch4:SetPosition( patchPos, 1) -- ?!self.treadmill_patch4:SetRotation(Vec3(0,fw.main.camera.rotation.y,0), 1) patchPos.x = newViewPos.x patchPos.z = newViewPos.z self.treadmill_patch5:SetPosition( patchPos, 1) -- ?!self.treadmill_patch5:SetRotation(Vec3(0,fw.main.camera.rotation.y,0), 1) patchPos.x = newViewPos.x+range patchPos.z = newViewPos.z self.treadmill_patch6:SetPosition( patchPos, 1) -- ?!self.treadmill_patch6:SetRotation(Vec3(0,fw.main.camera.rotation.y,0), 1) patchPos.x = newViewPos.x-range patchPos.z = newViewPos.z-range self.treadmill_patch7:SetPosition( patchPos, 1) -- ?!self.treadmill_patch7:SetRotation(Vec3(0,fw.main.camera.rotation.y,0), 1) patchPos.x = newViewPos.x patchPos.z = newViewPos.z-range self.treadmill_patch8:SetPosition( patchPos, 1) -- ?!self.treadmill_patch8:SetRotation(Vec3(0,fw.main.camera.rotation.y,0), 1) patchPos.x = newViewPos.x+range patchPos.z = newViewPos.z-range self.treadmill_patch9:SetPosition( patchPos, 1) -- ?!self.treadmill_patch9:SetRotation(Vec3(0,fw.main.camera.rotation.y,0), 1) oldViewPos = fw.main.camera:GetPosition() oldViewPos.y = viewLevel end end --[[ function object:Collision(entity,position,normal,force,speed) end ]]-- --[[ function object:UpdateMatrix() self.treadmill_patch1:SetPosition(self.model:GetPosition(0), 1) self.treadmill_patch1:SetRotation(self.model:GetRotation(0), 1) self.treadmill_patch2:SetPosition(self.model:GetPosition(0), 1) self.treadmill_patch2:SetRotation(self.model:GetRotation(0), 1) self.treadmill_patch3:SetPosition(self.model:GetPosition(0), 1) self.treadmill_patch3:SetRotation(self.model:GetRotation(0), 1) self.treadmill_patch4:SetPosition(self.model:GetPosition(0), 1) self.treadmill_patch4:SetRotation(self.model:GetRotation(0), 1) self.treadmill_patch5:SetPosition(self.model:GetPosition(0), 1) self.treadmill_patch5:SetRotation(self.model:GetRotation(0), 1) self.treadmill_patch6:SetPosition(self.model:GetPosition(0), 1) self.treadmill_patch6:SetRotation(self.model:GetRotation(0), 1) self.treadmill_patch7:SetPosition(self.model:GetPosition(0), 1) self.treadmill_patch7:SetRotation(self.model:GetRotation(0), 1) self.treadmill_patch8:SetPosition(self.model:GetPosition(0), 1) self.treadmill_patch8:SetRotation(self.model:GetRotation(0), 1) self.treadmill_patch9:SetPosition(self.model:GetPosition(0), 1) self.treadmill_patch9:SetRotation(self.model:GetRotation(0), 1) end ]]-- object:Init() function object:Free(model) self.super:Free() end end PS : you might ignore "object:init()" and "object:UpdateMatrix()" plus you might replace ":update()" with ":draw()". tia
  15. Hey, i want to use the lugi thing for a server application wich is not using leadwerks at all. I found this on blitzmax forums: http://www.blitzbasi...s.php?code=2579 its from joshk i tried it with the following: Include "glue.bmx" 'the generated gluecode Global lua:TLua = New tlua 'create the tlua type lua.dostring(str) Type test {expose} Method foo() Print "say ausgefuehrt" End Method End Type the content of the str string is this: (moved it out for better reading) print("test:") local dings = NewTest() dings.foo() the result that i got is: test: Lua error: [string "print("test:")..."]:3: attempt to index local 'dings' (a function value) executing a lua script works fine, but i the object pushing ist not working Dies someone knows what i made wrong? edit: it looks like i just made an . instead of an : so nevermind this thread, and sorry for bugging.
  16. A quick question since I search didn't yield much. Are any of the openGL commands exposed to LUA scripts in Leadwerks?
  17. About: This is a short series for the Leadwerks community on the process of creating a simple game using procedural content. In part 01 we looked at one theory of generating random maps in the style of old school dungeon crawlers. This week we'll put that into practice to generate map data, room geometry and mesh colliders. The easy part was adding a flying physics based camera to act as our first-person flown "spaceship". Again I want to flag I'm not a LUA expert, this is not a LUA tutorial but like most languages they are a syntax away from common functionality. It includes examples and explanations of some LUA code to relate why I did something a certain way. What you see is what you get. All code is freely available for use and modification however you see fit. How to use the code and run any examples in this series After working on the code a short time I found using the Leadwerks ScriptEditor.exe better for the process rather than attempting to run and debug it as an editor script. And one last note before we get on with it, 99% of the assets are included the Leadwerks SDK media folder so please edit the "MediaDir" in the LUA source. Any other required media will be included as a download. Pre-amble over with. Lets get to it. Map Data to 3D Geometry - first experiment The focus for this tutorial is generating map data then creating 3D geometry from it. The latter raised several questions about what would work for a tutorial and flexibility for use in different kinds of games. So I've focused more on this side for part 02. (Also I had to re-write it meaning less time to work on the map data code). My first room generator working prototype created "shoe boxes" as pictured below. With lighting, ambient sounds and the physics on a controller to fly your 'ship' around in first-person view it was a passable bit of code. figure 2.2 - "ShoeBox" room and corridor structure "ShoeBox" was efficient in that it was a collection of flipped volumes with light sources, individually painted surfaces (6 materials) and would be good for a simple iPhone adventure. When it came to merging volumes for more complex rooms I realised there would be a lot of code needed to split up geometry and re-build it. Rather than turn it into an exploration of CSG, triangulation and mesh simplification (which is not trivial) I ditched it for another simpler approach. Going back to how 2D games work, room geometry became a collection of grids (figure 2.2) that can be thought of in terms of traditional 'tiles'. figure 2.2 - tiled room (aka a regular mesh) Looking more like a terrain mesh with walls and roof, the grid structure makes it easier to merge volumes, add doors, corridors and holes traps or vertical shafts. And by increasing the mesh density and adding vertex noise you can turn rooms into caves with bumpy walls. I felt justified in presenting this method as it allows more possibilities and simplifies geometry construction. In appearance it's quite like old-school cells and tiles, similar to existing 2D dungeon map generators. In my working prototype you can't individually paint a tile but it might be possible to modify the code to allow for UV painting and save out this data. Each room can have it's own unique set of materials. LUA code-time. Geometry Construction Leadwerks like other engines provides tools to create solid shapes entirely in code. First you need to create a Mesh object then a Surface object attached to that Mesh. local room = {} room.mesh = CreateMesh() room.surface = CreateSurface(room.mesh) Note: For clarity this is using ONE surface, this will be expanded to use a six surfaces for each side of the room. The important part is that you add geometry to surfaces, you paint surfaces with materials, you create colliders with surfaces. It's all about the surfaces baby. All room elements such as walls, floor, lights, props etc. are parented to the room.mesh which is positioned in world space. Moving the room is as simple as calling Map:Room[id].SetPosition(x,y,z) Really evil dungeon masters might want to re-position a room with players inside. Well you can do that, even rotate it. Parent the room to the whole map (which has a pivot) and you can roll the entire map around for a marble game. All walls are solid but as they are one sided you can see right through them when viewing from outside. Patch Maker Let's look at a LUA code snippet for creating the roof and floor mesh, I want to draw attention to one of the cute things LUA can do and if you've not come across it before it can be confusing. So I draw your attention to it now. The assignment of (nameless) functions to a table and indexing them by string. Depending on what part of the room we are building we take care vertices are wound the correct way and the vertex normals are perpendicular. So I put the AddVertex() and AddTriangle() calls into a table and for ease of identification indexed them by string such as "roof", "floor", "north_wall" (walls not included here for clarity). addvert["floor"] = function (s,x,y,height,xsize,ysize) return s:AddVertex ( Vec3( x-(xsize * 0.5), height , y-(ysize *0.5) ) , Vec3( 0 , 1 , 0 ) , Vec2(x / (ysize*0.1), 1.0- y/(xsize*0.1)) ) end addvert["roof"] = function (s,x,y,height,xsize,ysize) return s:AddVertex ( Vec3( x-(xsize * 0.5), height , y-(ysize *0.5) ) , Vec3( 0 , -1 , 0 ) , Vec2(x / (ysize*0.1), 1.0- y/(xsize*0.1)) ) end addtris["floor"] = function (s,v,ysize) s:AddTriangle ( v-ysize-1, v , v-1 ) s:AddTriangle ( v-ysize-2 , v-ysize-1 , v-1 ) end addtris["roof"] = function (s,v,ysize) s:AddTriangle ( v-1, v , v-ysize-1 ) s:AddTriangle ( v-1 , v-ysize-1 , v-ysize-2 ) end function Map:CreatePatch( surface , width , length , height , mode ) for x=0,width do for y=0,length do vcount = addvert[mode](surface,x,y,height,length,width) -- we degenerate first row and column when making a grid if ((y>0) and (x>0)) then addtris[mode](surface, vcount , length) end end end end Our room geometry code needs to call the patch builder with dimensions and the name of the component like thus... -- example useage from the room builder Map:CreatePatch(room.surface, 8 , 8 , 0 , "floor") Map:CreatePatch(room.surface, 8 , 8 , 2 , "roof") That's the easy part. We will need to extend Map:CreatePatch to take our merged room data and generate an appropriate mesh to fit the irregular shape of our rooms and corridors as supplied by our dungeon creator. Now we have a method to generate basic rooms which is easy to modify we can look at the other problem; creating our random map. Remember the map structure we're looking for, a grid of cells into which we position at random offsets a regular set of rooms (see figure below). Each room being of variable size and can overlap. For this part of the tutorial we're going to keep the rooms small enough to prevent overlap to keep the source size down and reduce the complexity. We'll cover triangulation for a more advanced geometry function in a later part. In other words I couldn't get it to work properly in the time allotted. figure 2.3 - room and corridor structure We'll begin with a creator function... -- function to build entire map -- params: random seed value, xsize and ysize (dimensions of map in cells) -- roomscale (is multiplier of room size in world units) function Map:Create( seed , xsize , ysize , roomscale ) math.randomseed( seed ) if roomscale == nil then roomscale = 1.0 end Map.roomscale = roomscale Map.roomheight = 2.0 Print("Creating map, dimensions " .. xsize .. " x " .. ysize) -- table to store our rooms Map.Rooms = {} ... ... end For our dynamically generated game level, we need to know a couple of things; How big in game cells (how many rooms across and down) The seed from which the random nature of all springs forth (how poetic) How big we want the rooms to be relative to each game cell (room scale). A tile is simply a value stored in a 2D array e.g. tile[x,y] Our data would benefit from being organised into a grid. A 2D tile structure which represents an overhead view of our 3D world. This makes tile arrangement makes it simple to merge rooms and corridors, flag as walls, doors, traps and anything else we might want to generate. However...(c'mon you knew that was coming)... If we want to make really HUGE levels then array mapping will be inefficient, the 400x400 grid in our example will be fine but anything larger will become resource hungry as we increase the world size. Much of it becomes empty space. To avoid unnecessary memory usage and run-time costs we will virtualise the space a little. We've done it already with our room nodes (figure 2.4) figure 2.4 - room nodes are virtualised rooms Note: A room object simply exists at world_x, world_y and is this >< big. This is for boundary test and positioning. We will use a 2D array of tiles for each room. Each tile maps to a room_x, room_y. This way the data is available to game logic for locating objects, spawn points. After room generation is complete we run a post processing function to merge rooms, this is where the tile array comes in handy. The room merge steps through all rooms, a boundary check is performed on neighbours and merging into a new room as needed. Corridors are considered rooms (just thin), where they bend they are in fact two overlapping rooms and should be merged during the same process. After rooms have been merged, the geometry builder works on the new set of room tiles to spit out all the required meshes, lights and props. Infinite Power! In theory we can make an infinite dungeon if we move the rooms around us at the origin and use world space as a random seed for new rooms. An order of magnitude more advanced than Very Big Cave Adventure. 10 PRINT "You are in a cave (N,S,E,W)?" 20 INPUT a$ 30 GOTO 10 Out of time! Yes I've run out of time for part 02 due to code re-writes. I'll write up the room generator code as part 03 and post the example code with it. Then we'll start to see the two halves coming together and creating our procedural maps. Preview: HUD Overhead Map First pass on HUD to show location of rooms (with ID) within the randomly generated map complex.
  18. with the current release in mind, and also in anticipation of the upcoming version release, i'd just like to open up a discussion on how c++ and BlitzMax coders feel about writing an entire game in lua script... personally, i've got no problem going back and forth between c++ and blitzmax, but i've always found lua to be a lil akward, hence my resistance to using it... but i'm of an open mind here, and would like to hear opinions from those who use lua extensively, and from those who do not... pros and cons... thx --Mike
  19. Hi, i want to convert my sceneLoader C source to c++ and hit a wall with retrieving the lua state for using its transparency script settings ... this is/should all be frameWork. The entities in question are not handled within ProcessScene(), are the usual suspects firepit, waterplane and the atmosphere but loading fine first time around. from the engine.log Loading script "c:/devlab01/le23sample/vs2008_proto_arena_01/media/engine/models/props/firepit/firepit.lua"... Lua error: c:/devlab01/le23sample/vs2008_proto_arena_01/media/engine/models/props/firepit/firepit.lua:25: attempt to index field 'transparency' (a nil value) I init lua like this : // -- // Set Lua framework object SetGlobalObject( "fw", fw ); // Set Lua framework variable BP lua = GetLuaState(); lua_pushobject( lua, fw ); lua_setglobal( lua, "fw" ); lua_pop( lua, 1 ); // ... i brute force reLoading in the main loop like this : // -- // Prepare App for new sceneLoad if( KeyHit(KEY_F5) ) { FreeFramework(fw); fw = CreateFramework(); // Set Lua framework object SetGlobalObject( "fw", fw ); // GfxSetup // -- SetBloom( true ); SetHDR( true ); SetGodRays( false); SetSSAO( false ); SetAntialias( true ); SetReflectionElements(ENTITY_MESH | ENTITY_MODEL | ENTITY_TERRAIN); playerIndex01.~cController(); // -- // recreate layer_world for new framework TLayer _layer_main; TLayer _layer_background; TLayer _layer_transparency; _layer_main = GetFrameworkLayer(0); _layer_background = GetFrameworkLayer(-1); _layer_transparency = GetFrameworkLayer(1); // Set its global vars for lua ... SetGlobalObject ("main.world", _layer_main ); SetGlobalObject ("transparency.world", _layer_transparency ); SetGlobalObject ("background.world", _layer_background ); playerIndex01.SetCamera( GetLayerCamera(_layer_main) ); playerIndex01.CreatePlayer(); // -- scene.~cScene(); scene.Load( "abstract::SceneParaTropique_GTownCamp.sbx" ); // add camera from scene PositionEntity( playerIndex01.GetCamera(), scene.GetCameraPos() ); RotateEntity( playerIndex01.GetCamera(), scene.GetCameraRot() ); // add controller from scene camera PositionEntity( playerIndex01.GetPlayer(), scene.GetCameraPos() ); } As you can see i even tried to pass framework layers with "SetGlobalObject" - however, i just want to assign/get the previous lua state back to use fw.transparency etc ... hint&help appreciated
  20. DigitalHax

    Weapons

    Hey everyone. I am looking for creating a lua weapon script for long term use. I want to be able to have them loaded in the editor and picked up on the hit of a key. I have seen the power tutorial with gamelib to load weapons. But I am not to keen on using it. Now I understand a few people are developing something similar, like the lua weaponwerks. One example I know of is pixel perfects weapon system. Something like that would be just what I need. If anyone knows anywhere I can get started(i am not that great with lua) or provide some basis would be great. Thanks in advance.
  21. I tidy up some of my stuff and realise that 2.5 is somewhat falling behind earlier releases in terms of included content or does contain slight outdated material ... since josh got his head running leadwerks3D - i like to suggest to make it a little easier for him maintaining future (final ?!) builds of leadwerks 2.x and have the community find those loose ends. e.g. -the light fixture "Hanginglight" seams to be no longer a physical object -the switch shader "switch.frag" is missing the normalmap slot ... thats how it appears to me at least - there is possible more. Ill start and add the missing shader line to the bug tracker. thx for reading [edit] - forget the "switch.frag" - seams to be fixed already.
  22. Hey all, I tried to run LETheora outside of the editor, but it gives me the: EXCEPTION_ACCES_VIOLATION error. it's even not working inside the editor. the code I'm using: and my error log: Please don't mind the path it's created in, since I'm a very lazy person to create new paths every time... Anyhow. it gives me a error every time it arrives at the LETheora part. because when I delete that it will run as it should be. How can I fix this? it only give me the exception error. but not any specific error. Regards,
  23. Hey all, I tried to run LETheora outside of the editor, but it gives me the: EXCEPTION_ACCES_VIOLATION error. the code I'm using: and my error log: Please don't mind the path it's created in, since I'm a very lazy person to create new paths every time... Anyhow. it gives me a error every time it arrives at the LETheora part. because when I delete that it will run as it should be. How can I fix this? it only give me the exception error. but not any specific error. Regards,
  24. In continuing of conversation about SetZipStreamPassword() in Lua... Can we hide a password in starting lua-script? I tried to obfuscate starting lua script and hide my password for pak-file. So if you are interested in, look at my starting lua-script and try to guess the password. If you could guess the password you'll get reward: obfuscating script which generated this starting lua script. So you can improve it with your knowledge about cracking it. Main quest is starting here... 1. Extract folder from archive to some place. 2. Copy to that folder "engine.exe" and "newton.dll". 3. Now you can run "engine.exe" and see the spinning cube. 4. But your goal is to crack the "start.lua" script (it's even not compiled) and find out the password for pak-file. "start.lua" script looks like this: If you succeed, please send me PM, don't post the password here. Of course I'll share the obfuscator script later if it's not some sort of useless.
  25. I have the following code: [...] // Set graphics mode LEO::Engine engine(AppTitle,ScreenWidth,ScreenHeight); if( !engine.IsValid() ) { ErrOut( "Failed to set graphics mode."); return 1; } engine.AddAbstractPath( MediaDir ); // Create framework object and set it to a global object so other scripts can access it LEO::Framework fw; if(fw == NULL) { ErrOut("Failed to initialize engine."); return 1; } // Set Lua framework object engine.SetObject( "fw", fw ); // Set Lua framework variable LEO::Lua lua; lua.PushObject( fw ); lua.SetGlobal( "fw" ); lua.Pop( 1 ); LEO::Model skybox("abstract::environment_atmosphere.gmf"); [...] Leadwerks is installed to "D:\Leadwerks\SDK", which is what the "MediaDir" value contains. I'm trying to add a skybox to the test, and when it hits the line that loads the one provided with the SDK, I get an error message that says "can't open scripts/class". The console has the following text regarding this problem: So...what am I doing wrong now?
×
×
  • Create New...