Rick

There would need to be a lot of references to a lot of different things since most everything is public in the API but most of it isn't supported to be used by us. If anything I think you'd be better off making a post in the suggestion forum for this specific thing about what you are after because I think it's valid and you might get some support behind you to have Josh do something about it.

It would be the cleanest way if it was officially supported I agree with you btw, but it's hard to call it a bug if it's not documented and isn't wrapped around a function.

I don't think keydownstate is a supported thing to work with. It's not in the docs at all. Josh pretty much made everything public but that doesn't mean it's supported to be used by us. I think he's incorrect by doing this for reasons like this, but that's the way it's setup.

I'd still argue that there is a demand for mobile but like stated unless you are an LE supporter (not a huge number compared to the others) you aren't going to buy the mobile versions until your game is finished. A kickstarter for mobile would have been the way to go so at least Josh could have received the money up front or if there really wasn't enough support he would have known. The Android/Ouya stretch was hit so there was a need but because he didn't do a kickstarter for mobile only we can't compare the demand for high end PC vs mobile. There are reasons why every other game engine supports mobile.

Ideally a company looks to benefit while respecting and valuing customers at the same time, but you can't expect a company to sacrifice itself for the customer, so if faced with financial issues the company needs to do what it can to survive (Which often means alienating some customers. You can't please everyone.). A 1 man company is delicate and it doesn't take much for them to derail in a hurry. This is the risk you take when dealing with any game engine. Everyone needs to evaluate a game engine more on it's features but it's business model and future. As far as I know you could probably purchase the source still if you had the money. So that option is still there for us.

This is the point Josh is trying to make. He doesn't promise any of this stuff. He says a direction he wants to move in, but there are no promises and things change. If he doesn't say anything then everyone screams for him to say what's coming up. This is what you get with a 1 man show. They have to move to where the money is and in video game land that can change often and fast. The big boys are backed by venture capitalists and millions of dollars so they can give a plan months in advance and can wait for sales to catch on.

I'm not in support of this idea, I just understand the situation Josh is in and realize no amount of complaining will change the fact that mobile didn't bring in the money. So what's the point? Sounds like he offered refunds if people wanted them. And you aren't seeing the business angle. I also think your alternatives are unreasonable given the information we now know from Josh about mobile sales. I know in your heart you believe something but until the bank can cash your heart, it's a failing business plan. 1. Not sure what you mean by this? Maybe to maintain only 1 mobile platform? (guess you want Android where I would actually want iOS so now he's pissing people off still). Also, he's already stated that mobile dev takes a long time and is eating into the other, more profitable platforms. His example was specifically how Android takes longer because of all the devices to support. So this isn't a solution for the Leadwerks business. 2. How does this benefit Leadwerk's bottom line? Again, this takes time away from the profitable platforms. 3. Leadwerks is not open source. Asking a person to display their "lives work" is unreasonable. That's a personal decision. The only real reasonable solution from a business standpoint is to do a Kickstarter for mobile and ask for enough money that would allow Josh to hire a contractor to do a lot of the debugging/testing that is going to need to be done. However, Josh seems like a guy who likes to be involved in every aspect of his engine so he might not feel comfortable releasing a lot of this to another person.

I was here and I was pushing for mobile. He did what he said he was going to do and he had high hopes for it but nobody bought the thing. What is he supposed to do? Push on with something that isn't making any money? Honestly, what do you think he should have done? As a small business it's a little unreasonable to put so much effort into something that isn't driving revenue. He gave it a try but the people just didn't support him with their wallets so he was forced to move in a direction where they would. Would you rather he kept putting all his time into mobile and have Leadwerks go under because he's not getting paid? He placed a bet on mobile because of what we were saying and not everyone came thru for him so what was he supposed to do? Try to think of this from a business owners point of view. I don't think Josh was trying to mislead anyone, I just think no matter what he says it's going to piss someone off. He made a bet, people didn't follow him and he had to change directions for a little while. That's all there is to it. Because this is an option. I'm not saying it's ideal, but it's an option. Show Josh that you have a great game (not an idea) made with LE 3.0 (if you have it and care about mobile) and maybe he'll help any bugs or whatever. He wants games to be made with LE and if you can show him you have something (a great game very far in development that needs polish) he'll be more inclined to help. Again, not saying it's ideal, but it's a possibility.

Josh never said mobile is dead with LE, just that he's focusing on the PC right now. So who knows what will be in 2 years. All I know is right now I can make mobile games using LE 3.0. Will Unity even be around in 2 years? Given the recent developments of UDK and CryEngine who knows. In this industry nothing is a promise. Again, my point was the different ways to support different size businesses. Unity can withstand a year or more of dev cycles before their mobile sales pick up because people are finishing games. LE cannot. What were we promised with LE 3.0 mobile? I may have missed a thread but from what I can tell Josh did give us a mobile version that works. Honestly, you want to get mobile on Josh's radar then make a game for it that rocks. I bet he'll pay attention. Again, this is a different style based on the size of the business. I honestly think if Josh would have done a separate Kickstarter specifically for mobile it would have been a better indication of the demand. He got on the Kickstart wagon too late though which is a shame.

I agree but that's because $1,500 for a lone dev is a lot. What was it, $99 for LE Android? That's much more reasonable to anyone. Also, again, Unity is established in the mobile space and is a bigger company than LE. ?? I still own 3.0. I can still make games that target 3.0 so that hasn't been taken away from me.

Tournamentdan, you are dealing with a 1 man show here. A small shop. They have to be supported differently than a big shop or an engine that already has been established in that specific field (mobile in this case). They can't afford long development cycles by game devs in order to make their money. So when Josh spends lots of time and effort on mobile and you plan on making a mobile game then you need to support that right away or this is what you get. If you don't want to do that (which is your right) then you have to go with an already established mobile engine that already went through the pain of starting up. My simple little mobile game that I made in about a month paid for my copy of LE mobile. Sometimes you have to do things that aren't your dream game to pay the bills.

The end users voted with their wallet. I don't like the lack of mobile in 3.1 but I don't know how anyone can't understand the situation. Basically nobody bought the mobile versions compared to the Linux versions.

Is there any non hacking fog available yet?

In App.lua if you defined EntPlayer as self.EntPlayer then in other scripts you'd be able to use App.EntPlayer to access it. This is still basically global though as the App object is global. This isn't the worst since you'll probably only have 1 player in your game but it makes the scripts you make dependent on this App.EntPlayer meaning you can't share your scripts with others or between projects without your version of App.lua because of how it sets this variable. It means your other scripts are tightly coupled with your App.lua file. This may not seem like a big deal to you but it breaks things for people who have their own App.lua and when the workshop starts could cause issues if you want to share your scripts with others and now you have to modify their App.lua to work with your scripts. They may already have App.lua modified to do certain things like changing maps or whatever. You don't want to modify App.lua and if you do you want it to be a very generic modification. To avoid globals, it sounds like you know what the player is at design time. You could pass that entity around to the scripts that need it as a script variable.

Unless this changed generally you don't create an EntityDate object. SetUserData is generally a way for you to pass around any object. You should be able to cast anything to fit in that function so you can retrieve it later on and cast it back with GetUserData(). I use this inside classes often and pass 'this' pointer to it so my class and the LE entity (which is what LE is based on for everything) are then "linked" in a way so that I can get my class pointer from just the entity itself. I found this useful for collisions. Collisions are handled with an LE callback (which is global to the app) where the entities in question are passed in. This breaks object oriented programming, so to bring it back I make a base class that has a virtual OnCollide(...) function. Then all my things I care about derive from this and inside it's ctor I do the entity->GetUserData((char*)this);. Then inside the 1 global collision function I cast the LE entities passed in to my base class after getting it's data and then call it's OnCollide(). This makes it so my classes can get the collisions and it brings back the object oriented approach to my projects.

You can either set a variable in the script that is attached to the player and check for the existence of that script variable via the pickinfo.entity or you can set an entity key in the player script and look for that. script way: Inside FPSPlayer.lua Start add: self.isPlayer = true You pick code: if pickinfo.entity.script.isPlayer ~= nil then if pickinfo.entity.script.isPlayer == true then attack player end end Note that maybe just the existence of isPlayer (which is what the first if statement with the nil is checking) is enough. If you wanted to use entity key then: Inside FPSPlayer.lua's Start() self.entity:SetKeyValue("isplayer", "true") Inside your pick: if pickinfo.entity:GetKeyValue("isplayer", "false") == "true" then attack player end Note in my case above you'll always want to check pickinfo.entity against nil before doing the code I have.

I don't like that atlas tool I'll make one in .NET that just combines files.

I'll translate this 3.0 shader to 3.1 (if even needed) and do a small demo for people to use. I'll give the nvidia tool a try. It says DDS but I'm sure I can convert the result to png or something.

I think the way I did it was to have 1 value of the Vec4 passed to SetColor() defined how many textures per row. Then 2 values defined the row/col of the sub-texture to use for said model, leaving 1 variable unused. outcolor *= texture2D(texture0,vec2(ex_texcoords0.x*tileselect.z+tileselect.z*tileselect.x,ex_texcoords0.y*tileselect.z+tileselect.z*tileselect.y)); I manually created the atlas in paint.net This is how you would select which atlas gets used function App:SetTextureOffset(entity, row, col) entity:SetColor(col, row, 1.0 / 4.0, 1) end So 1 / 4 tells us there are 4 textures wide in the atlas. So you would have a script variable that would define the col/row/sub-texture per row and then you'd apply that in Start(). However, at design time when you apply the material it won't look right. It'll show the entire atlas on the model which kind of sucks. [edit] oh I think I started playing around with the last variable being a scale factor.

I made it in 3.0 specifically for mobile to take advantage of model instancing and it's performance. Since each instance shares the same material a way to make each instance look unique is to use this texture atlas technique as well. The downside is that you have to bastardize SetColor() to tell the shader what sub-texture to use in the atlas. This is because you need a model unique variable so each model can pick it's sub-texture and the values in SetColor() seem to be the only model specific values that make it to the shader. Also, the UV has to be the same for all sub-textures. I'm not sure if other engines have that restrictions or not?

I (with shadmars help) made a shader in 3.0 that allowed this. However, it was at run-time not design time so it required code to set what sub-texture you wanted to use from the mega texture.

I'm not sure if hiding cameras does the "deactivation" of them or not. Would have to test.

I don't understand how this is much different than buying models elsewhere. Dex-soft for example would run you the same situation for the most part. You can't buy a model and share it between your team members without most likely breaking the license agreement. The Workshop just enforces it better.

You don't have 2 cameras. Instead in 1 frame you move your 1 existing camera to a point (you can define this location with a pivot or something), basically take a "screenshot" of what that camera sees, then move your camera back to it's original position (probably your FPS or something) and render that "screenshot" (buffer) to a texture that is part of a material already that is applied to some 3D object. So the important thing to note is that you only have the 1 camera and you'll need some markers (pivots) to place that camera and take "pictures" all in one frame.

http://leadwerks.wikidot.com/wiki:render-to-texture-security-cam