Rick

I know, sorry about that. I honestly don't try to. I just want to express my thoughts and opinions about things. We can disagree about those with some kind of respect and we have come a long way it would seem. Thanks for the good luck. I'll keep on truckin'.

Yeah, that's why I made both comments about that image. Making a video game isn't a simple task. One could probably say making a basic script to rotate a windmill model could be the simple task, but I'd say that's like brushing your teeth with a really bad toothpaste. The toothpaste would be better if you had a rotate logical entity that you could piece together things in the editor to make the blades rotate because it then can be applied to many different things that need to be rotated. Some timers aren't triggered by a player pressing it. Also "press the switch" itself is a task that would need to be programmed. Josh's switch is nice and all but it's very specific and tied to his model. I feel if you ask a non programmer to adapt that thing to their own needs and they won't be able to because of what it entails. How would you propose this is done without coding? I think we are sort of on the same page but just slightly off. There really is no worrying about stopping or starting the script. Sending "enable" or "disable" output/message to it will do this for them. It might seem a little more clear once I get this game out, but we aren't really that far off from each other I think as difficult as that might seem by the posts. I guess a side point to the topic is to give many features to us from these scripts so we can put game logic in them instead of having them be just simple basic rotating windmill that LE2 pretty much is used for. Not argue, discuss. You make a point, I make a point, and we go back and forth

The problem with that approach, I feel, is that you still have to be a programmer or know a programmer to make that happen. I'm trying to help the non programmers and I don't want to do that by creating a very specific model script just for 1 person. I'd rather like to reach more people with reusable components they can assemble themselves. I've used C#, C++, & Lua back and forth back and forth and I've programmed a good number of game elements for each language probably twice lol. My personal findings of doing that is that the Lua components, even with logic, to be neatly bundled and use again and again. Even in LE2's less than ideal target/message system. Honestly that's basically what I've done I just called things enable/disable. Stopping a timer component is basically the same as stopping the script that is the timer object. When thinking about other components like GUI elements and such I may want to disable the update method of the script so no input can be had (if the control is disabled) but still keep the drawing part enabled so it's still drawn. The way the timer object works is by updating the timer in the Update() method of the script. Right now when I disable I have a variable inside this specific script that holds if the timer is enabled or disabled. Then inside the Update() method of this component I check that variable and if it's enabled I update the timer code. Any component that would have a constant ticking or drawing could benefit from being able to disable/enable those components directly instead of indirectly like I'm doing. The reason I don't feel I'm doing the below image is because he's not using reusable components and he's solving a much simpler problem then a video game . I currently have about 15 components that I reuse over and over again between about 14 scenes where the entire game logic is inside the scene by combining these components to make the entire game. For this game I'm purposely breaking things down to smaller components that I can see being used in other games and by other people. I don't pretend it's the prettiest in LE2's design but it's a proof of concept I think.

I like talking things out so I won't try to take your drink away but will just state my case. The need I have for this is because I'm creating scripts like a Timer (for example). I'll be showing all of this and how I'm working with it in a few days but it's working out pretty slick and it's somewhat how I'm thinking LE3D will work but not sure. I'm using the targeting system and messaging system as outputs from one script to others. A common theme I'm finding is enable/disable of certain parts to get a flow of functionality. It is my understanding LE3D will have a similar output/input type of system so I would think this would be handy. Below is some of the components I've been working on most the day. To follow the flow of the screenshot top left is a timer object. By default it's set to enabled, while all the other components are set to disabled. I have the timer set to an interval of 2 seconds and only run once in the properties. It's target 0 is the P-Var component. When the 2 seconds of the timer are up it sends the "enable" message to the P-Var (this message is configurable in the properties). P-Var is a persistent storage for variables (uses an xml file to pair name/value variables that need to be saved through runs of an exe). You define the xml file to read and the variable name in the file to get the value for. When it gets that value it to sends messages messages to it's targets and the msg to send is configurable by target. If this case target 0 is linked to the If component so I'm sending a "compare" msg, it also passes as extra data the value Pi-Var read in. The IF component has a setting that you give a value. It will compare that value with the value passed in from Pi-Var (in this case) and if they match it'll fire it's messages to it's target. In this case it has the sound component as target 0 and it will send an "enable" message to it so it plays it's sound. So the Timer object is the only thing that starts out being enabled (because I only want the sound to play 2 seconds after the game starts AND if the data in the file matches the data in my IF statement). I think perhaps the work enable/disable could be talked about, but this is how I thought of it. Sometimes I may want a sound to play right away when the scene is loaded so in that case I would enable it in the editor. Each of these scripts have enable/disable. I'm actually really excited about the possibility of this kind of style and if this could be LE3D's Lua implementation because it will allow non programmers the chance to actually get some kind of functionality into their game without coding. I understand this is controversial to some of the programmers in LE, but I think there could be a future in it within LE.

I didn't have anything, but after copying the atmosphere GetKey() it worked. So why is that needed? The other values were fine without having anything in GetKey(). Is this a cork of the PROPERTY_COLOR? Now it's showing 4. Aw bugger I swear it was only showing 3. I'll have to see if there was some scenario that caused that. Thanks for the help. [edit] Sometimes it's 3 and sometimes it's 4 it seems

Making a model script where I have a setting in the properties dialog defined as: group:AddProperty("bgcolor", PROPERTY_COLOR, "1", "BG Color") Inside object:SetKey() I have it defined as: elseif key == "bgcolor" then self.bgColor = StringToColor(value) Notify(self.bgColor.w) The alpha is always 0 for me. I'm looking at the environment_atmosphere script to see how it does it and I can't see what I'm doing wrong. w is always 1 for that script. In the properties dialog when you define as PROPERTY_COLOR it only gives you 3 boxes for r,g,b and no place for the alpha so not sure how that's working. I've been coding all day for I'm sure my eyes and brain just aren't connecting something

I think you are reading into it wrong. The pure coding that you know sounds like it'll still be there, but for the people who want to use the Lua system can too. But I don't agree with your thinking of not thinking a game/component system won't make commercial games. Unity has a similar system and many commercial games are created with it.

From what I can tell a decent amount of people asking for these tools have left for other engines that have them until LE3D comes out. Niosop would be an example as such a person. Sure there are artists asking for things like 3rd person camera and I'm with you in that it shouldn't be part of what Josh creates but he's not really promoting us programmers to make things easier for the artists either. Adding a Lua system was a first good step but by supporting so many languages and not having a game system built into LE hurts it when it comes to those people, but helps it with the programmers to reach more people. I have a small marble game I'm making and I'm using only (for the most part) basic, reusable entity scripts that I'm creating. Joining them together via the targeting system and property settings to make more game functionality. I'm hoping this will show that you can make games using such a system. If LE2 had a better game component system this would be easier and most likely adapted by non programmers and promote programmers to make components that everyone can use in a visual manner. Some things to use this way can come off awkward because of the lack of extendability by the editor. On a side note, one issue I find again and again which hurts these kind of components is the ability to create bodies in Lua AND have collision callback be called on it. This would allow volume triggers which is a huge gameplay component in a good number of games. Currently a model has to be created and then you have to code specifically for that model. That's not very user friendly at all and will generally shy artists away unnecessarily. It's so many little things like that which hinders the engine to be user friendly to artists. BUT the biggest hindrance is Josh not supporting a game/component system by making the system and promoting the system. This has no effect on the programmers who don't want to use it and a big effect on the non programmers. At the end of the day there are more non programmers than programmers out there who want to make a game and will pay for an engine that makes it easier and looks good too.

If you are talking about my Pi stuff you have to consider what Pi-Main is doing. It calls Initialize() functions of each script if it has it, it's setting the game mode variable and 1 or 2 other things. When you load the scene from your C++ program Pi-Main isn't running. If you set that game mode global variable in C++ then it should work, however I'm not sure how you'd be able to call the Initialize() method of the scripts from C++. Those scripts were meant to be ran from the editor or engine exe and not a custom game executable. You might have to make a custom Lua file that does the Initialize() function and then from C++ call that script with the LE Lua_State variable after the scene loads.

you can loop through the objecttable variable and it'll give you all the model script objects. If you download my Pi scripts in the Asset Store/Scripts look at Pi-Main and you can see I loop through this table and call the Initialize() function (if it exists) of those scripts. That's a function I define in the script itself. The objecttable gives you access to all the model entities in your scene (for the most part). There should be a name variable for each one or if you want another way to ID them you can make your own variable inside the model scripts and read that to tell what is what. Another way to access model scripts from other model scripts is to use the targeting system. It's more efficient than looping through the objecttable, however it can also get overwhelming and confusing when you have a bunch of targets in your scene. You get lines being drawn all over the place, but it's how LE2 works and it can be viable. I will be coming out shortly with a timer and decal model script which I'll do a little video on how to use them. I need them for my marble game. The way you use the timer script is giving it targets, define an interval, and a message value. When the interval hits it'll send the message you define to all the targets it has. Nice and easy way to do some timed events. Making a relay model script also that just relays the message along with a possible delay. This is needed because you can only have 8 targets per model, which is limiting but being able to have a relay can extend that number to unlimited but it would get more complicated to follow.

I make easier games. Generally most of us bite off more than we can chew when it comes to picking a game to make without even having 1 single "completed" game under our belt. What makes us think we can make Crysis when we haven't even made pong (or some other simple game)? I think completing games is infectious. It gives you that accomplishment feeling that you want to feel again and again. It also helps practice getting past the boring part (generally the 20% you speak of). This is my new approach to making video games and so far so good. I started with the Simon Says clone in the Asset store (very simple), and should be done with my little "Marble" game by next week. With each game I learn new things that help me with the next. I also try to up the difficulty a little with each game. It's an ego hit for sure because we all generally start off wanting to make the next amazing AAA quality game. I've switched to sacrificing my ego to get completed games in the hopes that it'll be a launching pad to making the bigger games I want to. If I was a sports guy, which I am (I think you mentioned sometime you were too), I think of these little games as scrimmages. You generally want to do some scrimmages before playing a real game. That's the way I see it anyway.

NA correct me if I'm wrong but you didn't use LE's editor in making your games right? I assume that meant you created tools, exporters, and dialog's of your own? This isn't a bad thing but trying to make the point that the one person who is the farthest in selling a game using LE didn't use LE's tools. How much easier would it have been for you if LE's tools were extendable? Do you think you would have extended then instead of creating your own and would that have saved you time and money? This is a nice thought but if the tools aren't sufficient then most people won't be able to make their games. Which seems to be the consensus with LE2. Sure you'll have a couple people like NA finish their games but the idea is to reach the majority of people. When you allow your tools to be extended it gives you a better chance to reach the majority because now you have 1000+ programmers potentially helping you make community tools which has more potential to make something useful for others to reach their goal of making a game easier.

Not to fix it, enhance it to meet their needs in a timely fashion. The only argument that would make sense to not do this would be if you fear that it could eat away at your income because adding features and such and making a new version and charging for that version is how you make your money then I can understand that, but if you truly think your product will solve everyone's needs/wants then I think that's misguided.

Will we be able to enable or disable entire scripts in LE3D? In making this marble game I'm using all entity scripts with a generic minimal main script so I often need to disable and enable between scripts to get the functionality I want. In LE2 I'm using the message system, targeting, and custom entity script variables to do this but would be nice to have a default way to tell the engine/editor to not call a certain instance of script methods. I don't know how far it can be taken because I believe there are multiple methods the engine/editor will call by default so not sure if you do an all or nothing thing but might be nice to determine what you can enable/disable. I would think the most basic separation would be update & draw methods. Maybe something like: scriptInstance:Disable(ALL) scriptInstance:Disable(DRAW) scriptInstance:Disable(UPDATE) An example of how I'm doing this and would do it in LE3D from my understanding of the system Josh wants is as follows: I have a LevelStart entity in my scene. The level starts by having the camera behind the marble which has it's own script to allow player movement BUT it starts out disabled so the player can't move yet. The LevelStart entity starts some music and does a 3, 2, 1, GO countdown. When it reaches GO it enables the marble script which allows the player to move the marble. The connection between the 2 is the target system. When they reach the Goal entity, that script will disable the marble script so the player can't move anymore. It kicks off some music and changes scenes to the next scene. Being able to enable/disable parts or all scripts out of the box is useful. Just checking that this was thought of.

How would you hide the instant popping that would occur with models and textures like Ken said above or are you OK with that? Much like the day/night cycle this would have to be very gradual. I can see that working with textures, but models would be tough without them being animated (or else you'd need a ton of gradual versions which at that point animation would be easier). Even today most LOD changes are pretty noticeable. Would be nice if those could be somehow blended together instead and if so that might play into having separate models.

If every model had an animation to change it through the seasons you could just play the animation on them very very slowly to get a nice natural feel. For the terrain change the textures slowly. For random snow hills have models that grow in animation and again play that. The central manager would manage all those animations and texture changes. It would be cool to see but to get it looking nice would most likely be a ton of work. Excited to see what you can come up with.

@Ken Also when linking there is a visual line drawn. Tools->Linked Index let's you change which link you are viewing and linking. You can only view1 link index at a time. Also pressing keys 0-7 will change this selected index. @Dozz I know you said without Lua but currently you have to use Lua to do this in the editor. In a way Ken's comment could work for parenting but it would still require some coding in the model scripts. You'd want to add the following function so you know when something is linked and then you could call EntityParent. The model script function would be: function object:SetTarget(target,index) end You can look at the lua template in the Scripts folder to see this and all other Lua model functions that the engine calls. I fought for this function because it can be useful to know when a target is set. Like in this case you could put code in this that actually does the parenting of models. Should just be a 1 liner in each model that you want this functionality in.

I think some people might be able to turn that around on you and say it frightens them that you would think you can give them everything they want, because it's not realistic. Like any other piece of software having the ability to extend it yourself is a very powerful and attractive feature. That's just the reality in today's world.

Has anyone tried the program in Josh's link above and gotten good results? That product seems interesting. I'll give the demo a try but just curious if anyone has first hand experience with it.

Very cool. Question. I'm not an artist and so I buy a lot of models. From what I've seen they all have their own naming conventions for diffuse/normal/spec. Let's say a specific convention doesn't work with the automatic method you have to guess what it should be. What would the flow at that point be? Would it be to just drag the diffuse onto the model, which will create a mat. Then go into the mat editor and manually set the spec and normal and others? Might be cool if when dragging we can tell the editor what we are dragging so we can apply each texture type from this model viewer? Just an idea of maybe holding down certain keys while dragging the editor will put the texture as that type. Hold 'd' key while dragging diffuse (maybe that's the default and you don't have to hold the key). If it can't find any pattern to find normal or spec you could hold 'n' key and drag it to set it as normal, 's' for spec and so on. Might be handy when multiple models use the same normal or spec but different diffuses too. Just thinking out loud in that situation. Clearly it's not that bad to go into mat editor but the fewer editors someone has to go into the better and faster it'll be. This is so much better than the current flow though. Love it!

That would be handy. Still can't figure out why I get that error telling me I can't do this in LE now when I didn't before when LE2 first came out.

I apologize then. Thought it was more about the thread topic which is why I made my statement. I'll try to read more context in the post.

I think the truth of the matter is nobody has really asked for a handout to the extreme level some think. Nobody here is asking from someone to write their entire game for them. I've never seen a comment like that at all that maybe wasn't from the very first and last post of a new member. That's why I point out comments like "people these days are asking for handouts." Those comments are in line with "things were better in my day" or "kids respected adults in my day". Thinking that asking for a handout directly relates to creating a common system so that there is a market for programmers to make money and artists and designers to make games just doesn't make sense to me. I'm sure that's what people said before there were grocery markets. I mean why can't you grow your own corn and raise your own cows and chickens to make your dinner? No thanks, but I do grow my own corn, but I would rather buy the chickens and combine the 2 to make my meal (game). I honestly think anyone who thinks they'll make the next WoW or Crysis by themselves without a huge amount of help is kidding themselves. If finishing that game is what really matters to you, then take the help of components both in the code area and art. If you just want to learn how things work then by all means code every system yourself in your spare time. Just don't get mad when you don't finish that game.

I'm confused by his anger as well and just going with he's frustrated with something else so not taking it personally. I'm trying to make the argument that if there were a common interface in this game engine it would open the door for programmers to make some money from their hard work. I'm a programmer and I want to make money from making components for this community. The market just isn't there because this engine is so fragmented and/or Josh doesn't want to come up with a system because he feels he'd be forcing people. I'm even saying it doesn't have to be the only thing he goes with. I say keep the API as it is for those who want free range, but build a system on top of it for those who want these common components because there is a market for it, but only if the system is in place and nobody is going to buy code created for a user created system because tomorrow that programmer will be gone and then you're stuck (yet to see if LE3 will be that system and some might say wait and see, but that's what everyone said about LE2, combine with Josh's hesitation to let code be sold on the asset store).

The "handed to them" comment is often brought into the argument when one tries to make libraries and systems that don't require direct coding but perhaps configuration of predefined components (ie something like FPS which clearly is the butt of many jokes). Predefined components that we share is what the topic at hand is about. So therefore when that comment was made I figured it was around the topic at hand. If it was just a general comment and not directly related to the topic then I apologize. If it was, them I'd say my "who draws the line" is still valid. Unless someone is saying that just because of the act of programming (typing out code) is required to use API's makes it mean it's not being handed to them, because I'd argue that point. I'm clearly being handed networking to me on a silver platter because of RakNet. I don't know if that's fair. If a person wants to share or not is their decision and I won't hold it against them. The system I'm talking about in this thread allows sharing for free or for a fee. If the infrastructure is in place and solid and everyone is using it, then programmers will code for it and can sell their code components and people would be more willing to buy it because it plugs right into the system they are using. A strong community doesn't always have to equal free in my eyes and honestly I think some of the strongest communities charge because it makes a market and people are generally more motivated in doing something if they know they'll get a return from it.