Rick

Coroutines are mostly beneficial for games in cut scenes as they allow you to code stateful things sequentially. Are you looking for a written or video tutorial?

Left panel with contents and index doesn't scroll correctly on iPad. Right side scrolls right now so that's good.

I didn't mention anything about iterating through each bone though. If that's what LE does during animation then it is what it is, but to get the bones you need is a one time thing at start up that you store off. The you call PlayAnimation() on them just like you would if you did it on the entire model. The cost is whatever it takes to play an animation on a model * 2. Given PlayAnimation() doesn't let you set the frame, then syncing doesn't seem possible with that system. You can of course roll your own using the core SetAnimationFrame() function. If you're looking for split animation it's probably best to do that so you have more control.

This is called split animation. Blending in the animation realm is something different. Find the bone at the highest hierarchy for lower body and save it off, and then find a bone at the highest hierarchy level for upper body and save it off. I think you should be able to call PlayAmimation() on each bone and it'll play that animation for it and it's children. http://www.leadwerks.com/werkspace/page/api-reference/_/entity/entityplayanimation-r918 This does present other challenges such as syncing both when you are just running and not attacking. With the old AnimationManager, which you can still get I think, I would create one animation manager for the entire body and another for upper body only. With that we get to control what update function gets called first, so I would call the entire body animation manager update first and then the upper body last. What this means is when running the entire body animation plays and since there is no animation on the upper body it doesn't play but the entire body is playing run anyway. Then when the player shoots for example I'd play the shoot animation on the upper body. The entire body is still playing run but then just for the upper body those bone positions and rotations get overwritten with the shoot animation, and when shoot is done it stops playing anything on upper body and the entire body goes back into running again.

http://www.leadwerks.com/werkspace/page/api-reference/_/prefab/prefabload-r622 Try explicitly telling Load() to call start. There is a little note about that in the doc. See if that helps.

That assumes you are using that system. Marty just said he's looking to save off high scores and other user data. He didn't say it was a multiplayer game with servers players are playing on.

I think it's more about YOUR rest api as I could call it and pass whatever I want. If you don't have them register then you never truly know what you're getting.

The site doesn't work well on my iPad. Can't scroll down. It just cuts it off.

By the sounds of it your issue is that you're rendering ui in multiple scripts PostRender() functions. For basic UI you can get away with that but as you're seeing when working with more involved UI it's best to render your entire UI at the same time. You can either make one Le entity script to do this (or do it in your player script) or use main.lua to do this. It sounds like you might be brute forcing your UI though. By this I mean do you have objects that make up your UI elements or are you simply drawing all your UI elements right in PostRender() with draw commands? Ideally you want to have your UI elements be objects that are configured for how it should be drawn, and then you have some functions that actually draw. So you configure the UI elements in Start() and then draw them all in one place. In my UI there is a main GUI table/class where I add UI elements to. Then in main.lua file I draw all visible elements in this GUI table/class. Inside any script I can add GUI elements (which are just tables themselves with config info about how to draw that element). GUI.addElement("closeButton", { x=5, y=5, width=100, height=50, border= 1, priority=1, text="Close" }) Then you get into how you handle events and that can get involved with many design wars around it. It's a pretty involved topic with lots of different ways to go about designing.

Generally, if I recall, this happens if you don't have a camera in your scene.

@game collecting this information is generally easier with a nice ui. Since it's a launcher and most launchers are generally just UIs it would be easier, pending knowing HTML/CSS/Javascript, to make this with nw.js. I'm thinking of games like Rust for example that show a drop down of supported screen resolutions, and check boxes for all sorts of settings. All done much easier and quicker with something like nw.js vs doing that in Leadwerks itself given its lack of UI. If you try to do this ui in C you run into cross platform issue and now you have to either know each platforms c ui libraries or find a cross platform library to use. Styling this launcher also becomes a problem doing it that way but with HTML/CSS styling can be anything you want. In modern computing it's just a better choice for tool creation for a lot of reasons. But yes the added benefit is later it could also easily be used for auto updates as well if desired.

LE doesn't come with anything out of the box for this. You'd have to make your own. Nw.js would be perfect for this. Web based technologies ran locally and multi platform.

Can you show us your picking code?

What is the collision type set to for those doors in the physics tab?

The Lua debugging could really use a lot of love.

I wouldn't hold your breathe on the ui part. We just really need to come together and create a good community one with a wysiwyg editor to be complete. I have a ui library that I use for our games that handles screen resolutions correctly, does some tween animations if needed and is image based (vs drawing lines) but it's not complete as I use it for what I need at the time. I think tonight I'll make a post and show it and ask for help to make it more complete. It's sort of HTML /CSSish in style where there are no controls just an element that can have a bunch of styles and properties that determine how it looks. Honestly even if josh does release something it won't meet most people's need and it'll be fine for development as it gives something but for production you'll be asking for a lot of additional features that'll take forever to be implemented because he's doing lots of other things. Josh doing a ui to completion implementing tons of features people would want would take a good year of focus which isn't going to happen in my view. In all honestly the ideal would be to recreate an HTML and CSS parser to LE drawing commands but that's s huge effort that nobody is going to do so a close idea to that is easier. Sorry didn't mean to high jack thread. A 3D minesweeper should be fairly easy and gets more into 3D. Could just make boxes for tiles with a slight angle of camera to see them all. When not a bomb a 3D number or sprite appears and rotates around itself.

Bomberman might be a good one too.

You have to to type it.

Any idea when they are projecting to have the xml files finished?

http://steamcommunity.com/sharedfiles/filedetails/?id=843731357 Note that I was one of the programmers on both urWorld and the link above. The 2 games, while both 3D, are slightly different ways of doing isometric. UrWorld used the normal camera mode. What this means is things at the top of the screen seem farther away and so they get skewed a little and look funny when you do it this way if your camera angle is allowed to pitch a fair amount. The zombie game uses orthogonal perspective which means everything on the screen looks the same size even though in the 3D world it's farther away. It's more 2d looking while still being able to work with things in 3D. Visually I prefer that style myself.

"SQL databases...are they files? Then where is the file? I can make some funny tar.gz backups, but I don't know what's in them. They get corrupted and lost. " I for sure get the idea with this, but you could be in infomercials with an explanation like that

Transparent for who? Normally you'd have a web API of DB data to make it transparent for the users and so it's not much difference for us. A URL returning data is the same. If more transparent for you on your web server I can see that. I think it's probably just easier to describe something like this data outside a relational database. As long as we can get the data in a nice format like this I think everyone will be happy. Opens the doors for more possibilities.

The good part about this being xml files we can access is we are able to pull them and make our own presentation of it. If Martyj doesn't plan on it I'd like to make a desktop version that works offline and also pulls updates when available and allows comments.

In the end will we be able to access all the raw XML files directly?

I would assume it's the same issue I have. The controller seems like it's always falling a little then it lifts back up a little creating the jitters we see. @Gamecreator my issue was controller related as well. The controller jittering was/is the main issue. I feel like the controller should be smooth as it's moving.