Rick

What are you drawing? These are sounds.. Show that code.

What is self.name? So your sound variable has the GetLength() function. So after you load the sound store that in another variable. local sound = Sound:Load() self.soundLength = sound:GetLength() self.source:SetSound(sound) sound:Release() self.source:Play() If you are inside App functions than you can use self vs App. They mean the same thing because you are in the App "class" but it's general practice to use self vs the table name itself.

I got it going for our game. I need to release the base code and demonstrate how to use it. Been behind on doing that. I'll see if I can get to it in the next day or so. I combined the tween library I was using and make some cool functions around those which can make some cool effects. It's not 100% worked out yet and could have fixes but just might release it and let others improve on it.

I think using Steam to do this is the ideal situation since LE is so tightly coupled with Steam anyway. However that means changing the packaging system LE has now to account for this. Users are going to hate LE games as it stands if every small update requires possibly a gig or more update of the 1 data file.

I'm sure I missed something or didn't understand the impact but when I make a new blank project for testing I get a C++ project but it's just doing the Lua approach. Was the old C++ template completely dropped in favor of this? Just wondering why if that's the case? Also, why does App.h have: Leadwerks::Window* window; Context* context; World* world; Camera* camera; When they aren't created in C++ but Lua. The templates seem screwed up.

Make a 3D array. Imagine a 2D tiled game. You have x and y "tiles". You are now just adding z layers (vertical layers) to that. Now in a 2D game you have tile sizes. Normally like 32x32 or 64x64 which means 32 or 64 pixels in width or height. You normally want width and height to be the same. Now in 2D land you can make bigger objects by combining multiple tiles that makes up the bigger image. Like you can make a house that is 3x3 in tiles. Now translate this all to 3D. Your prefabs are your tiles. Make them all the same size width width depth and pick a constant height value. Ideally you would make the width/height the smallest you can imagine will be needed, but for performance reasons you'll want to not have it so small. If you need bigger things in your scene then you can make prefabs that are meant to be combined together to make that bigger thing. In the 3D array just store numbers. The numbers will relate to the prefab. 1 = hallway.pfb, 2 = hallway_end.pfb etc. Then you just have some code that fills in this 3D array with numbers. On load you loop over it and do a lookup on the numbers to load the correct prefab. Each "tile" has a position (center point) and so placing your models is easy since the width/height/depth are all known. Let's say for example you pick 2cm height, 10cm depth, 10cm width for all your prefabs (just for example). Let's say 0,0,0 in your 3D "map" array is 0,0,0 in the world origin. map 1, 0, 0 means you are moving right on the x value in LE. So you just multiply 10 by that x value and that gives you the new position for whatever model is in that map. If this seems confusing I suggest looking at how 2D tilemaps are drawn and it'll start to become more clear. You could even just use 2D array to start with and just have everything at 0 height. It might be easier to understand to start with.

Also, note that I think that would only work for Windows. If you wanted this on Linux you'd have to research that and probably do some #ifdef in that code.

Yes, sorry. Playing with the collision type would be the way to do it. You want a collision type that collides with the character but doesn't collide with whatever collision type is used in the raycasting. I don't recall what the FPSPlayer.lua file uses as a collision type for the ray, but looking in the docs should show what collision type you can put this barrier to, to give character collision but no collision with the ray. Or you can make your own type as well that does this. Don't recall that off the top of my head but if you do a search here for custom collision type something should come up around that. Ultimately I believe this is all about collision type of the barrier.

Did you set this barrier's collision to None? I think that may be different than the pick mode?

How does that relate to your need to NOT have the icon or interaction show up? Either way, I feel like you'd be better off having a flag in the FPSPlayer script that skips these pickings when certain conditions are met and resumes them (if you need that) when other conditions are met.

Can you explain why you need this? What are you trying to accomplish?

So you have to think about what you want here. You can have in-game message box or you can have an OS message box. The OS message box would have nothing to do with LE. You'd have to code this in C++ for the platform you are on. On windows just look up Windows MessageBox to see how to do this. For Linux I'm not sure exactly how, but I'm sure they have something. Gamecreator's solution is more in-game. You are just drawing images/rects on screen to simulate a window and drawing text and buttons and such. You are making the message box yourself with LE commands this way.

Ma-Shell this is really a great idea I think. Those game lua files could very easily be 1 workshop kit that we decide if we want or not.

I agree with Olby about essential engine files vs non essential files. The game related scripts are just not essential engine files and should be treated differently.

Don't you keep track of LE files per version somewhere? The server that you call to get the updates should have a list of LE files (your files you send to us) in it. If a file does NOT exist in our project then don't send it because it means we deleted it. You would need a file listing on your server per version and then see what project version we are updating and compare. Server ===== version 1.0 Files ----------------------- Noise.lua FPSPlayer.lua Trigger.lua version 1.1 Files ------------------------ Noise.lua FPSPlayer.lua Trigger.lua Isometric.lua Client updating project version 1.0 to 1.1 ================================ Their project has ------------------------ Noise.lua Trigger.lua You can see that they don't have FPSPlayer.lua but the server does. This means they deleted it and so you shouldn't send it to them because they don't want it (since they deleted it). You should send Isometric.lua though because it's new since the last version they have to what they are updating to. This means it's truly a new file that needs to be sent. Now let's say you changed Noise.lua from 1.0 to 1.1. If the hash of the client version is the same as the hash on the server for the old version the client is updating from then you are free to update since they didn't make any changes themselves and won't lose anything. If they are different then act like any source control and prompt for us to decide what to do. Keep ours, accept new, try to merge. All of this is pretty much what source control is doing so I would imagine at some level you could just put your code files into a private git repository and just have the updater use git to manage all of this for you? I'm sure there is some git library out there that would allow you to integrate that functionality directly into the editor and you could host a private git on your server. From a source control view a delete on our side is basically saying ignore this file completely which means don't ever give it to me (in the given project only of course).

I think it comes down to asking us if the file changed from the previous version before just assuming the change is wanted. That way if we made our own modifications we can decide to keep ours, take the updates, or even possibly merge. Really this comes down to source control like features which would really make sense for code changes.

I think this comes back to what is being updated. The update of textures or script files may be something we don't care about and don't want. Updating the LE library of course we would want but that alone shouldn't cause main.cpp or app.cpp to change. Changes to those files we'd just want to know what would change and why. Maybe we don't want or need that change.

Do you have the first person prefab in your scene? A camera is made in code in that script. As far as I know material files are per application. ie they aren't all the same so a .mat in 3dsmax isn't the same as in leadwerks. It's just like the .mdl format. Other engines use that format but they aren't all the same and can't be used between engines. The segments are only for CSG creation. Your model can be as detailed as you want but the more detailed the longer the load and more memory and such. With just a sphere you probably won't have much issue with that though.

There is also a Follow() command that will have your AI follow another character (player if you will).

I've just made a cinematic sequence library that helps with this. Adding more functionality but the idea is that you have a lua function that executes top down but can yield out to the main LE loop. So you make a sequence of steps for your cinematic. For in game you would find the already existing entities and then call functions to make them do things. You'd most likely disable user input at the start and enable it back again at the end of the sequence. I'm thinking of making a video tutorial and posting what I have to the workshop on Friday.

Sometimes I need to know when movement from a controller using the navmesh is complete. Today I generally do a distance check but because of the odd back and forth movement that happens at the end of the controller moving once it's reached it's point, that distance has to usually high enough of a value to avoid that from happening (usually around .25). In an ideal world I think that back and forth and very very slow coming to a stop at the destination that happens wouldn't happen, and allowing a callback to be fired when at the destination would be nice. This part of the navigation seems not very polished the way it is today.

You could use coroutines in lua to make designing such a thing easier and more logical. It sort of gives you the ability to use a poor mans cinematic tool. Coroutines can yield out of the function they are in so the rest of the game can continue to run and when they come back into their function they start off where they left off. So you could be inside a loop increasing a number and yield out each loop and each time you come back in the state of everything (let's say that number) is exactly as it was when you left it. What this provides for you is the ability to make sequences of events rather easily. Each sequence could also be in their own files which makes then nice and separate from each other and easy to maintain. You end up with a script sort of like: -- pass in LE's world, window, & camera & anything else you need or you can query entities from the world function IntroSequence(world, window, camera) local player = FindEntity(world, "player") player.script:DisableInput() PlaySoundAsync("Sounds\Music\IntroMusic.wav") local camera1Pos = FindEntity(world, "camera1_intro") MoveEntityToLocation(camera1Pos, camera1Pos) player.script:EnableInput() end Functions that I want to continue running the script I give Async at the end. Functions that I want to run until it's done I don't. For example I may want a move to point and don't want the script to continue until the entity is at that point so that function would be "blocking". I'm still working out none blocking move script as there would be something to track after the function call and not sure how to do that yet. Dead Anyway needs something like this so going to take a look. Combining with the tween library I posted about this could be pretty slick. I've done tests so I know it works, the question is just making functions to make it easy to work with.

How do you add tags to these things? Nevermind it must be automatic.

Thanks. Never used this feature before and the docs weren't updated so it was obvious.

Looking http://www.leadwerks.com/werkspace/page/tutorials/_/artwork/how-to-use-the-workshop-r111#section5 it looks like the dialog has changed. Now it has File and not folder. I'm looking at adding some scripts but question on this adding process. 1) What if my system has more than 1 scripts but they work together? Can I zip them up together and include the zip file in the Publish File dialog? 2) So these get installed into the AddOns folder in the Assets tab? Is that still the way this works? I assume the folder that shows up there is the Title I give it in the Publish File dialog and should be careful with what characters I use in my title? 3) Everything just is in 1 folder then? I can't have subfolders?