ZioRed

Mike, I see you're around here since 3 months only, I'm here since 2010 so I read TONS of posts like yours over these years neither of which had any or most influence on the company decisions (except may be one only time about a very high price offered) and that's why I say that now it's disgusting me. It didn't mean I disgust you or your point of view or your posts, but the topic itself because I know it will not have any influence at all having tried in the past. I'm sorry if you felt offended by my post, it was definitely not my intention, I love communities and helping people (collaborated to the community C# headers for LE2, created the LE Builder software myself and gave its source to Josh and I think it was used as base for the "Project Manager" you have now, and others) and I think everyone around here knows me enough to understand that I'm almost never so rude. So if you really felt offended or insulted, please excuse me.

Do you really expect Josh can have an exact roadmap from here to next year? You know what's under the hat for the next paid version ("probably" OGL4, Linux and Steam if all his campaigns will be completed successfully, and they will likely be if you consider their current status so it's more a half-sureness than a doubt) and he already stated that the mayor releases will be paid (you cannot expect to know the price earlier!), whatever else do you need? Please stop complaining about that, you know how the things work and will work for the near future, any more discussion about this topic is definitely disgusting and make me sick! oufffff you better have to concentrate to work on your game and leave these inconclusive and unuseful points. Leadwerks Corporation is definitely not PS4 or Xbox teams who make awful decisions at first and reverse back when players (thousands, millions players, not tens!) cry, I think he likely knows what people expect and definitely knows his own stuff and what is needed to survive, so please just stop whining about paid or free or "what I'll get in 2076's", if you don't like just quit and stop boring me with this discussion. All of this is definitely out of topic ("linux version", not "roadmap, paid or free"), I suggest to Josh to finally lock this topic as everything needed to say has already been told on "linux version" topic.

Yes I liked exactly your suggestion of Script["Scriptname"] (I didn't said it was my own idea eheh), "awful" was for both Script:GetScript and "inconsistency" was for using only Script to access the first. I don't like any scripting language at all, I love only high-level strong-typed programming languages where I can do everything (even interact with the operating systems libraries and functions; I know python could do this work, but its syntax is as awful as LUA as bash), so of course I was talking about C#, but I know that Microsoft and NET is definitely seen as the last and most evil around this community so I neither feel to discuss here (but I use it elsewhere and everywhere, with no bottlenecks, no FPS drop, no any of the "cons" that many around here complain, when you know your stuff) And of course as ever it's only my own opinions, I don't expect others agree in any way.

@Furbolg: This kind of inconsistency is simply awful. As you, I also think that an entity should definitely not contain only one script but as many as we need, no matter if you can "require" other scripts, it's just weird that you have to use a glue to tie all the scripts (lol it reminds me LOTR: one ring to rule them all!). But in my opinion the way to go to access other scripts should be your second (entity.Script["MyScriptName"]), it's just more readable than Script:GetScript. And also I think that we should have the possibility to connect a script member (Entity type) to a prefab/model from the assets folder instead of only actually existing objects in the scene (and this way you should be able to declare a member type as Material, Texture, Source and any other type of "entities" but selectable from the assets folder too). This kind of stuff (and the weird LUA syntax and limitations at my programmer's eye against other well known great languages for scripting) is the main reason I don't use scripts at all, besides the fact that I Love to do much more experience in C++.

ehm.... this is YOUR personal feeling, the reality is not ever exactly this (don't know how much experience you have when it comes to business), mostly depends on the features and above all the timing (I mean, you cannot expect that your source code for a version 4 years old will run with today's, but neither that 2 or 3 versions or 1 year later you have to rewrite most of your code..for example). PS: I'm sorry talking ever about business, but I chose to make this as job, so I need to make points on the commercial point of views (and rewriting systems means more time and so more money you'll invest).

Oh so is that the problem? Please Josh, stop talking about "3.1" and call the next "4.0" and keep minor versions for bug fixes (which is fairly and usual in versioning) so everyone is happy to pay! panz3r my friend, the bugs MUST be fixed and of course at no cost, it's not only market but the law (at least here in Italy), about what is missing I see only terrain is a must and all what you don't see in the list of features is definitely not "a missing feature" but it's simply not here so you cannot complain about something you know was not present in that list when you bought (no opengl4, no linux support, no GUI). Isn't it so?

"Fair" is something very subjective, you probably wanted to say "fine for a hobbyist" and I personally think that LE should overcome hobbyist way nowadays and move towards indies (I mean not a hobbyist, but own job) if they want to survive in the mid/long run (and provide much more features than it has now to compete, last but not least GUI [possibly both visual in editor and through code] and graphics improvements). I think that as far as the upgrade price remains the same as it is now (200$ for one or one and half year) is already a fair price for indies, you cannot expect that with the current community base (may be 99% hobbyists) a company makes enough money to support, pay taxes, marketing, rentals, salaries and engine improvements with only "pay-per-support" model (how many hobbyists would pay for support? I'm also against crowd-funding at all to fund an upgrade, because I want upgrades and am more happy to pay for it being a sureness than rely on a doubtful campaign which may or may not happen to finish successfully). Besides this, I got really bored to speak and listen to the current price, if the price will increase without apparent/personal reason or the new mayor version will not be worth the price for my own projects/usage then I'll just not buy it without complaining. So I'll just sit down and wait for the new release (in the mean time I think can do something with the current LE3 version, waiting for my OculusVR to be shipped [may be in 2036] ).

I tried to use Copy on my testing project and you're right, no animations are played on it. Though I don't know if it's working as expected or not, but on the reference page it says "Copied entities are unique and will not be rendered in batches. Consequently, it is preferable to use Entity::Instance() when possible" so I tried to replace Copy with Instance and the animations worked again. What is strange now is that Instance method is displayed with strike format in the Entity reference page, which usually in the world should mean that a command is deprecated/obsolete and should be avoided.

A function that is expected to raise an exception when it's called is definitely superb! I hope the doc is wrong and it's NOT expected to raise exceptions, once that you'll discover how to use, else I wonder what should be its utility.

Tried and everything is red like your screenshot. Though sorry but I don't know what the problem could be, I never used nor understand how BSP works (and personally I'm neither interested in it).

Because I noticed that when you create a file in the Windows project, it saves it in the folder "/Projects/Windows" while all the other default files are in "/Source" (and at least on my VC++2010 it seems I cannot set the directory where to write the new class). So if you are not going to build a cross-platform Windows+Mac I suggest to move the default files (main.cpp, App.h, App.cpp) in "/Projects/Windows" and you will not have any issue with the weird behavior of the Windows project. I use Xcode on Mac so I'm not having this issue because I can set the physic path of a filter, if someone knows a workaround for this on the Windows side too please let me know. PS: To create both .h and .cpp at once, you can right click on the project name in the solution explorer of VS and choose Add->Class->C++ Class, then set the name of the class. PS2: You must not #include .cpp but only the .h to access your class.

I don't know why, but on the documentation it says "expect an error when you run this", don't know why or if it matters your issue.

I don't remember what UpdateController did on LE2, may be SetInput

Of course, it is like common models but you can integrate more models and camera and whatever else you need into them. I can send you my project source if you like, to see how I'm managing it, I created a component based system very similar to another engine (and to Aggror's system may be) which should help to spread features over different small chunks (I have only two components by now "player input" and "character animation" and should be easy to follow).

I think it would be a lot better if you setup your model in the editor, then save it as prefab and finally load it through code (Prefab::Load). It is like I'm doing now and it seems fine, besides the fact that using a prefab is much easier since it can save lot of code.

It seems there are as many undocumented functions as documented (or possibly even more)... wtf!

No problem, buddy. I edited my previous post with the reason why you usually want getter/setter method instead of changing directly the variable "mesh", it of course depends on your game/variables (for example you won't need getter/setter for a "speed" variable, so you will add it to "public" declarations of the class and change it like "actor->speed = 10");

Don't know about why should have unzip headers, it should already have been unzipped during update/install. About the warnings you can ignore them, here is our discussion about them: http://www.leadwerks.com/werkspace/topic/6988-leadwerks-3-trial-c-linker-warnings

You can add a constructor to your actor class which accepts an entity as parameter: Actor.h class Actor { public: Actor(Model*); Model* GetModel(); // you want a getter method because you don't want your entity to be changed outside the class private: Model* mesh; } Actor.cpp Actor::Actor(Model* model) { mesh = model; } Model* Actor::GetModel() { return mesh; } How to use: Actor* actor = new Actor(Model::Load("mypath/mymodel.mdl")); // this line calls the constructor above // Now you can access its model Model* myModel = actor->GetModel(); I hope it can clarify a little your doubts. This code is almost similar to what I'm using in my component based project. Now why would you want a getter method like GetModel instead of just adding a public member which requires lesser code? Take this example: for some reason you want your "actor" mesh to be changed dynamically, in this case you want of course at least that the new model has the same position and rotation like the old one, so instead of eventually duplicating the code in more than one part you want to call one only function everywhere that does it for you so you add a setter method to the class: Actor.h class Actor { public: //... void SetModel(Model*); //... } Actor.cpp // ... void Actor::SetModel(Model* model) { // Get the old entity's rotation/model, or default values if entity was not set Vec3 pos = (mesh ? mesh->GetPosition(true) : Vec3(0,0,0)); Vec3 rot = (mesh ? mesh->GetRotation(true) : Vec3(0,0,0)); // Release the old entity if (mesh) mesh->Release(); // Set the new entity and assign the old position/rotation mesh = model; mesh->SetPosition(pos, true); mesh->SetRotation(rot, true); } // ... so to change the current model you'll only write: actor->SetModel(Model::Load("mypath/myothermodel.mdl"));

It seems more an issue with the templates (may be the template sources are released with full path to C:/Leadwerks, I didn't try but off the top of my head I bet it is so), you should look at your project settings, most likely it contains links to C:\Leadwerks folders for additional include directories, additional library directories and the path of Leadwerks.lib and OpenAL32.lib in the Library filter. To quick fix (if you don't want to manually change the project settings from the VS IDE) just open the .vcxproj file with a text editor and replace all "C:/Leadwerks" with your installation path, then I think it should work. If it still doesn't work then it's strange since klepto is not having this issue (I haven't a second HD/partition on bootcamp to try myself)

Well, at this point I think your meaning of "automatically" is far from mine... If you take care of my written words then you'll get what I'm suggesting here is: avoid workarounds, avoid scripting and avoid changing source code or exit the editor for something that should logically be there. There's no need for you to fight a perfectly logical request with workarounds, I am definitely not a hobbyist, I am a business company not for love or hobby, and if I wanted to go through workarounds then I would have gone for open source, don't you think? I don't think this request is so odd, and the reason why I am still here after 3 years is because I would like to support LE and help as I can to push it to the other big stars, else there wouldn't be any point for me to be still here since I already own other much higher-priced licenses too However this is my suggestion, let's stop this flame between us and leave to Josh the faculty to accept or decline, I can perfectly live with the current workflow, but since this is SUGGESTION forum then I like to suggest what could be useful.

woah! didn't notice ahahahah sorry my bad, that was why I asked Jorn what library he was using because it looked so cool CEGUI supports both: http://www.cegui.org.uk/docs/current/rendering_tutorial.html

No Furbolg, I meant exactly what Jorn answered (about the screenshot posted just after the video). Ok thanks Jorn, thank you for your kind sharing option but I'd like a robust full-fledged GUI library with all the whistles&bells (labels, textfields, textareas, windows, boxes, popup lists, grid, buttons and any other common widgets)... will take a look again at CEGUI.

The answer is exactly in your sentence: it starts the map that you're loading from the C++ project, not the scene you're currently viewing in the editor (that is if you're creating a new scene, not "start.map", you cannot run it in the editor until you change your C++ code). Starting the EXE with parameter is simply not an option, since you have to open a prompt console to execute, while it should logically be done from inside the editor itself. Also take for example your artist is doing the level 2 of your game, with the current workflow he will need to play the game from start and complete successfully level1 before he can see the new work-in-progress level, "oooops I put that object in the wrong place/rotation" so quit the debugger, apply the patch and again have to play the game from start and so on... definitely not feasible for a team work (and neither for one-man, in my opinion, too much steps to only see how your new scene is rendering).

Wtf I would have changed job/role/engine if I had to build levels in code, too lazy that is why I never approached XNA eheh