Rick

I'm using CopyEntity() for a cube. I want to paint different mats on this cube but since I'm using CopyEntity() it creates an instance so painting a mat on one does it for all. My needs with this are very basic. My texture would just be white, blue, or red. Ideally I would be able to make a 512x512 where I have 4 256x256 inside of it where each section is a color. Then I always paint the same material on the cubes, but just adjust the texture mappings on the ones I want to show different colors. I know that one nio guy created something like this but for shader. I wonder how would one go about doing this in LE code instead? Shader isn't an option as I don't want other people to have to modify their shader.pak file if they use this Thingoid. Any code or point me in the right direction would be great. Thanks!

nvm, copied picking code from another file that didn't have the camera variable. Can we delete posts?

When I output the value of terrain.resolution for a 128x128 with 1 meter per tile I get 82309936. When I'm generating my grid I'm looping through the entire terrain and so for a 128x128 1 meter per tile I setup my loop from 64 to -64 stepping by -1. What is the relationship between 82309936 and 128x128 1 meter per tile in such that I can get the x & z values of the corners of the terrain?

lol 2 years ago.

I don't understand. Right now it's showing 2 items. This one and "Callback/Variable Interaction?". I check pretty much every day many times a day. If at some point I don't check it for a weekend or whatever I like the fact that it shows me everything I missed (multiple pages possibly) since I missed them I want to see what I missed in case I can respond. I noticed sometimes it actually doesn't show EVERYTHING I missed. I would prefer it show everything I haven't read yet from every forum and when I have read it keep those for maybe a day or 2 on the list. Why would anyone want to miss new topics? You might be able to help with them. If you can't help and don't want it to show up just enter the topic so it's marked as read then go back out. Would be better if there was a "mark as read" feature but just going into the thread is a workaround.

That's what View New Content is for. I think that link needs to have bells and whistles around with with giant signs saying "Us me"

Such is the danger when passing a function pointer as (byte*)

There is actually http://www.leadwerks.com/werkspace/forum/6-programming/

LE3D will have that. Another solution for LE2 is to use a shader that lets you offset a giant texture that has the textures you want to use from a value in SetColor I believe. Here is the post and somewhere in here is the shader file you can try out. http://www.leadwerks.com/werkspace/topic/607-non-instancing-copy-command/page__p__5296__hl__instancing__fromsearch__1#entry5296

I get that, but adding 3 headers and 3 source files is just as easy as adding 1 source file in my view. Now you can still say you haven't done that either, BUT I would say that's because libraries are solving much bigger problems. Small snippets of code are solving much smaller problems. If the design you are doing with Lua is more for people to make these smaller scripts that solve smaller problems and be able to combine them to solve a bigger problem, that same thought process can be transferred to C++. Just because it's C++ doesn't mean I have to treat it differently in functionality. If I write a Lua script for LE3 that just takes an entity as input and rotates it, if the same structure is setup for C++ I can write a class in C++ that does the exact same thing. It'll be 1 header and 1 source and probably 10 lines of code. A person would take that, include it in their project, then in the sandbox editor define that they want that functionality (defined by name or whatever) to be attached to x model and now it works. This is basically how Half-Life works. The Hammer editor, just like 3DWS, has functionality entities. These entities are directly mapped to C++ classes in code and these classes are often self contained and small. In the editor you pick 'tie to entity' assign that entity the entity functionality you want, fill out parameters, and when you run the game it passes that to C++ in which the objects get created and ran. This is almost exactly what you are doing in Lua and so it can be done in C++. I get that you haven't experienced this in C++ before but it does exist and can be done. I have both of these in the works using thingoids directly with the current LE editor. It won't be perfect, but I'm trying to show that these components can be separated out and smaller and that they don't require external editor dependency. As long as a common interface is defined people can write their own AI script that use that common interface to get pathfinding data. In LE2 one of the drivers for this is the target system (a common interface). It's sort of clumsy to work with but it's all we have in LE2. I also think Zaphos is a great example of what I'm trying to get at and understand why more people don't do or join in on. He has defined bones and their names for all characters he's doing. That is the common interface for his character models. Now think if everyone accepted that and would create 3D accessories for his models that follow his bone and naming conventions (his interface). People could sell their models and advertise that they work with Zaphos character models right out of the box and make money indirectly from Zaphos. It would benefit the community in such a fashion I can't even imagine. I believe a common interface for coding is a logical tool that can be provided by us or LE.

I don't fully understand where you are coming from with that but I respect it and so it seems a valid reason for number 4. 4) Don't want to give source code for components. So in the form of DLL's for components as Roland suggests this would work and satisfy your requirement. I'm assuming you can make DLL's in BMax and use them in C?

File Name: Pi-Scripts File Submitter: Rick File Submitted: 13 Dec 2011 File Category: Scripts Consolidated my Pi scripts into 1 zip file. Going to be adding some more functionality in the future and wanted to just have them all together. =============================================================== Pi-Main Description This is the main script that works with all my other Pi Thingoids. Place this in \Scripts\Games and then point your editor to this script via Tools->Options->Paths->GameScript setting. This is a very simplistic main loop game file. I designed it this way to allow the Thingoids to do the main work of the game and not have custom game code in the main lua file. Ideally, when the Pi library of Thingoids is complete, you would only need to use this main game lua file for all your games that you make in lua. =============================================================== Pi-CharacterKeyboardControls Description This allows you to send movement messages to the Pi-Character thingoid. The settings allow you to configure what keys are used for what movement. It's still very early and not everything is available yet. Just want to get these things out there for people to play around with and maybe give advise/help. =============================================================== Pi-Character v 0.1 Description Very early version of my character objects. Place it in your scene and go to the settings and give it a model. It creates a character controller and receives some messages to help it move. This works in conjunction with Pi-CharacterKeyboardControls. =============================================================== Pi-3rdPersonCamera v 0.1 Description Here is a very basic 3rd person camera thingoid. Just drag it into your scene and give it a target =============================================================== Pi-MoveTo Description This will move a body with SetPosition() as long as the Thingoid you are moving has a object:GetBody() method. Works well with Pi-Body. Target 0 is the body to move. All the other targets should be Pi-Pivot (1-6) is the points to move between. In the code you can change between Reverse or Loop. This determines what will happen when it reaches the last Pi-Pivot. This will be a setting in the next version. =============================================================== Pi-FixedJoint v0.1 Description This creates a FixedJoint between 2 bodies. You can use this with your custom Thingoid that creates a body as long as your Thingoid defines a function named object:GetBody() and returns a body. The link 0 is the parent and link 1 is the child. The fixed joint is created as soon as you define both parent and child. =============================================================== Pi-Body v0.1 Description This is much like Pi-Cube. It allows you to create a dynamically sized physics body. When in editor mode a white cube mesh is shown, but when in game mode nothing is shown. TODO: Working on getting collision working You might ask what good this is if no collision works. When I combine this, the Pi-Cube, Pi-FixedJoint, Pi-Pivot, & Pi-MoveTo I am able to get a cube that moves from pivot to pivot that has physics. I joint a Pi-Body to a Pi-Cube, then Pi-MoveTo calls EntityMove() on the Pi-Body to move from pivot to pivot while Pi-Cube still retains physics collision. =============================================================== Pi-Cube v0.1 Description This allows for dynamic cube sizes with matching dynamic body size and you can apply any material file to it. The body mass is not set until you run game mode (and are running the Pi-Main lua game script). TODO: It needs to be able to scale/rotate the texture assigned. If anyone knows how to do this please let me know. Click here to download this file

I don't think it necessary, no. I'm observing, more recently in the last 3 months or so, a huge number of people doing the exact same thing in different languages or slightly different ways. As a programmer you would never copy and paste chunks of code that do the same thing all over your project. You would make a function or class and use that instead. So when I see what has been going on and is going on in LE, and I see what some other engines do, and benefit because of, I know it can be done more efficiently and more importantly it promotes games to be completed. There is so much talent in the LE community but it's being spread out. That does the community no good and it means games aren't given their best chance to be completed. So I raise the question to see what people think about the situation.

I don't consider myself wise as I have many faults I just really want to see the community come together to share code (free or paid) so we can all get some games made. From my perspective this is a big issue for this community.

I agree, the chances of a community coming to some agreement on such topic is most likely not going to happen. I don't expect we'll come to an agreement on a structure, I just want to explore the reasons why it's an issue and have them written in stone for everyone to think about, Josh included. I think it's always nice to have it in black and white in front of people to get their gears turning on the subject. I also agree the vendor has to be the one to support the structure. Note I didn't say force, just support. I would fully support LE still being open like it is, but I would also support a common game structure and component interface even between the 3 major languages although I'd personally say 1 language would bring more benefit for the community as a whole. Even if that language was BMax (which clearly I'm not a fan of but for me the realization of separation because of languages is bad). I agree 100% on this too. It is hard, but sometimes the right thing is hard ya know. I recently ran into this. For GvB I was making my own GUI even though I knew Josh had a Lua GUI out there. I spent a ton of time on my GUI but because I wasn't doing gameplay programming my motivation was dropping for the project. I realized this and just yelled at myself and forced myself to use Josh's Lua GUI. It took some time to get used to it and I certainly don't agree with every aspect of how he structured it and I made enhancements to it and extended it with more controls and that took even longer to figure out because I had to figure out the details of his system. At the end of the day it saved me time though and was more efficient and kept me going from seeing results faster. It was hard, but it was worth it and in terms of seeing results and continuing with the game it was the right thing to do. So maybe this is number 3 on the list. 3) It's hard to give up personal style. Or perhaps it can be thought of as ego. Good or bad.

It can but there is some glu code specific just to Lua that has to happen for lua to use it from my experiences. I don't mean to argue either and often the devils in the details, but it for sure is a possibility and probably the only possibility if multiple languages want to be supported. At the end of the day for someone in Josh's position, that's all that really matters. I think he's shown his concern about the lack of games being made so he cares about it, but enough to make drastic changes to promote it? It's asking a lot and a risk, but how long without having a "successful" game title released with said engine is the engine not take "seriously" for game studios? This is a general question I would ask anyone making a game engine and in no way aimed directly at Josh, but hard questions have to be asked at some point. LE3's scripting attempt is probably the 2nd or 3rd attempt to promote something like this. If it works and solves all these problems then that's great. If it doesn't, at what point do you think separating the community because of language and lack of component framework is to blame? Pixel's response is very valid and as it may have been assumed up to this point that this code would be free, I don't think it's the assumption that should be made. I believe people are willing to pay for code (I've gotten paid on this forums to do small code work). The LE community would be less likely to buy Pixel's hard work because he had to make his own structure and chances are to fit that structure into another structure is probably painful enough where people wouldn't spend the money to get his code. That's a shame and of no fault of Pixel's. If LE supported a robust design with all languages or just 1 supported language, Pixel may have been inclined to fit his code into that design, which would have the added benefit that he could sell his code later to the LE community. People would then be more willing to buy Pixel's code because they know it fits the LE design and can be plugged in without trouble. If you provide a marketplace that supports structure and support, people are more willing to follow your rules to sell things for it and buyers feel more comfortable giving money to buy things. Think of a grocery store. A farmer wants to grow cows because he knows the grocery store is a place where a bunch of people come to buy his beef. The grocery store has rules, structure, and support around quality and such so consumers feel more comfortable buying beef from the grocery store than some random farmer. Topic 1 above is around this entire premise. I would challenge that to understand the basic concept of the underlying parts doesn't mean you have to have actually coded them. Many of us use shaders every day in LE and many of us understand the basic idea behind them, but many of us have never really coded them. Clearly it would benefit us to know how to code them as we could do amazing things, but if someone else does that and we buy and use them, are we considered bad programmers or lazy? If that were the case we would all lazy because we are all using Josh's shaders. If someone wants to do the coding for learning then clearly nothing wrong with that but I won't fault or judge someone who simply wants to buy and use instead.

I believe each language would still require some glue code to get those working though. Which I think adds complexity and doesn't make it very plug and play. I think the support of multiple languages helps individuals but hinders the community. It splits the community in more than just forums It does it with code sharing as well. We have 3 major languages for LE: BMax, C++, & Lua. People generally make their libraries or code snippets for only 1 language. That's not good, but you can't expect people to duplicate their code for 3 languages. We end up with either the same general thing done by 3 different people in 3 different languages (not very efficient) or something amazing in just 1 or 2 languages. We are all fighting the same battle with different guns but we can't exchange bullets. I don't see Josh dropping to 1 language because it'll most likely hurt his customer base, but it's a pretty decent problem that most other engines don't have. Unity supports 2, BUT you can use them together without doing anything special, which makes integration issues non existent.

I believe the cost is only high because you haven't defined a framework to be followed in C++ like you are doing in Lua. The cost would be the same in Lua if you didn't have this framework because you run into the same problems. I'm not saying a C++ framework is something that should be required for people to follow, but if it was there and robust enough I bet a good number of people would. You've taken the giant complex task of game objects and in Lua you setup a system to have them broken out into small code snippets that can be combined via the editor. That doesn't have to be different in C++ just because it's C++. I can still make a class in C++ that JUST rotates an entity just like you'd have in Lua. Would be nice if the framework system like this is available to all languages and the same or very similar with all languages. Might make code reuse between all languages easier as they would be in the same kind of "format". This sort of plays into topic 1 of a common structure.

OK so some common obstacles to overcome are: 1) Code generally/possibly not created in a modular fashion to be independent of other parts. 2) Creators of code don't want to spend the time to support it. So if anyone wants to brainstorm with me on possible solutions to those 2 specific problems that would be great. 1) There is no doubt making your code modular is tough. Often times like noted above laziness will prevail and we'll break the modular design to get something to work because it's easier than finding a modular solution. I can't help but think that if a common design philosophy was encouraged it would help people think a different way to solve their problems. A way that could be more modular. I'm no means a design pattern expert but does anyone have ideas around this area? Another plus side to this is that reading code that all follow a certain design philosophy should be easier. 2) Maybe as consumers of the code we shouldn't expect direct support from the author? If the code is free then I don't think we can expect support, but if the code costs money I think it's fair to expect support. The downside to this would be if the code is bugged OR doesn't do exactly what you want you might have to get into the code and fix it yourself. The question would then come up around how do you push that fix or change to the asset store in a fashion that either overwrites the "bad" code or let people know about your fix. The good is that making said change should be easier given number 1 above.

So many people are creating their own systems which are duplications, to some level, of existing or in the work systems. There are like 5 people doing pathfinding (I've even had something in the works but haven't posted anything yet), a number of people have 3rd person control code out there (guilty), and a couple are making GUI's (guilty just never posted). Seeing and participating in this situation I can't help but take a step back and ask the question "Why can't we as a community share our code better?" This isn't me judging anyone, it's me simply thinking that things could be done better and more efficient if we were able to share things easier. Many attempts have been made to do this with failure, but has anyone looked at why these have failed objectively? I can't help but wonder if we did we might be able to see why it hasn't worked up until now and possibly come up with a solution. I think as it stands most people are thinking LE3 will solve this problem, but I'm skeptical about that. I feel like one of the reasons we can't share code/components today is the vast amount of supported languages. It segregates the community, and from the sounds of it that's not going away in LE3 so why would we think the problem (I see it as a problem) will go away? If your goal is to make and finish video games and you are a 1-2 man show, it would seem logical that the most EFFICIENT way would be to piece together commonly used code/components. Sure you might have to tweak the code some to make it work, but that basic interface that all the code plugs into together has to be there first. Once that's there, tweaking the code of some specific functionality is still possible and encouraged. Clearly you'll still have to code some components yourself because they'll be unique to your game and you wanting to share those or not is up to you. So why can't we agree on at least a couple main systems if not just 1? Curious to hear your thoughts.

Could someone live with just a Mac in every aspect of what's needed in home computing? If so, then I have no problem with people getting them (as if anyone cared what I thought anyway ). If not. If they ever say, I log into Windows to do x, then I can't agree with that person getting a Mac because what's the point of having 2 OS's to have to know and care about if 1 does everything you need. It almost seems defiant just for defiant sake.

Do you think some kind of shader could actually smooth it out some? That would be pretty cool for us non artists.

3DWS Can do cylinders. You pick how many sides you want it to have. You can see that on the top rightish of the screenshot. http://dl.dropbox.com/u/1293842/3dws.png

I'll see if I can find out more information around this, but coroutines are a built-in feature of Lua and pretty powerful stuff so it would be nice if we were able to use them within LE's Lua implementation.

Josh, are you using lua_newthread(L) in the editor or engine when calling the Lua script? I ran into an issue where coroutines are failing in Lua possibly because you are using lua_newthread(L) instead of lua_newcthread(). I guess in LuaJIT if you use lua_newcthread() it will allow coroutines to work in the situation where the Lua script is going back and forth from Lua to DLL. My Question on the issue and others response http://stackoverflow.com/questions/8459459/lua-coroutine-error-tempt-to-yield-across-metamethod-c-call-boundary/8463031#comment10471100_8463031 A response related to the issue http://lua-users.org/lists/lua-l/2011-10/msg00461.html Note that before you switched to LuaJIT I was able to get coroutines to work in Lua. Coroutines can be very valuable as it basically gives us a form of threading via Lua. I was trying to use it to split up pathfinding between game cycles when I encountered the error I describe in the stackoverflow question.