Ma-Shell

That way makes total sense to me. With Load() you are creating the first instance and with Copy() you are copying that instance... Copying (as opposed to instancing) makes only sense if you already have an object using that model, so you can just use that one. Have you tried the suggestion using the "Asset::CreateNew"-parameter?

For me this behaviour you described makes perfectly sense. The call to "Load" creates your first instance and the call to "Copy" creates your second instance by copying the first one. So if you could get a hand on your other model instance which comes from the same asset, you could go ahead and call other_instance->Copy(true) and you would get what you wanted. Furthermore, the documentation of Load (https://www.leadwerks.com/learn?page=API-Reference_Object_Entity_Model_Load) mentions that there is a second parameter called "flags" but it does not say, which ones are available. The description is simply "asset load parameters". That is something, you might want to add to the documentation @Josh. From the header file Asset.h, I find the following four constants defined, which I believe are those mentioned asset load parameters: Unmanaged, CreateNew, LoadQuiet and SkipTextures. You might want to give the following a shot (I haven't tried it myself): Model::Load("Models/level/ground.mdl", Asset::CreateNew);

The lua interpreter does a lot of memory allocating and deallocating, causing these false positives to show up. See more here:

The problem you are trying to solve is called "Principal Component Analysis (PCA)". The process involves quite a lot of math, computing Eigenvalues, etc. I'm not entirely familiar with how it works either but just throwing this term at you, so you can use the name for further research

Josh seems to have a way to extract the files if you can prove ownership to him: https://www.leadwerks.com/community/topic/16895-do-you-need-your-encrypted-game-files-extracted/?do=getNewComment

Nice, I like the concept you are proposing here. Just adding my 2 ct: When you said, there was no remove-function for a script, that makes perfect sense for scripts that are only setting variables, as you mentioned. However, you might want to have the option to remove these functions. Let's consider your tank-example: If you somehow lose your main cannon, you might want to remove the script associated with it, such that future calls to GetTarget() do not call the function of the main cannon anymore. There is another issue with your tank-example: If you have two functions called GetTarget(), you would likely also name the corresponding setter-function SetTarget(), each. However, this would mean that you can only set the target of both at the same time, if you did not name them AISetTarget() and CanonSetTarget(). For this reason, I think, you should draw a line here so you have to make explicit whether you want to call functions from a different script or only those of the same script. I would suggest, you do the following: SetTarget() will only execute the function from the current script. If there is no function named SetTarget in the current script, an error should be thrown All::SetTarget() (or something similar) will execute functions from all attached scripts (as well, as the current script) with the current name (i.e. the way you proposed) FILENAME::SetTarget() will only execute the function from the script called FILENAME. If this script does not exist or it does not have this function, an error should be thrown So for each function you define in your script, you would need to internally create three different mappings. Doing this would give everyone maximal flexibility while at the same time preventing some unforeseen errors. So, everyone could still use their isolated scripts the way they used them before without even needing to change anything. If you want to call functions from other scripts, you have the choice to select either only one specific other script or all others

In order to move the rotation center, you need to translate the point, such that the new rotation center lays at (0, 0), then apply the rotation matrix and then translate it back. This means, you need to change the last line to something similar to vTexCoords0 = (texcoords[gl_VertexID] - vec2(0.5, 0.5)) * rot + vec2(0.5, 0.5); I haven't tried it out, so you might need to switch the minus and the plus or play around a little bit but something like this should do the trick

Brushes get collapsed to form a single object (except if they have a mass or a script attached). This means, if you have 100 CSG cubes, there is still only one transformation matrix for them and basically everything that runs per object only runs once. For that reason, they should perform better than using multiple objects of box models... If you, however, compose all the boxes in your 3d modeller and export them as a single object, they should perform the same. I suppose, collapsing could have a negative impact as well: since they are only one object, the individual boxes can not be culled. I.e. if one of them is within the viewing frustrum, all of them need to go through the rendering stages until the individual fragments are finally culled when rasterizing, while if everyone is an individual object, they can be culled early. This means that both, a negative and a positive impact on performance might be possible.

You also need to take into consideration that you need to read less data from the harddrive and IO is usually quite a large factor in loading times, so on a slow harddrive you might even see better loading times with a compressed package.

In the following I will use the following terminology: A -> blue point, B -> red point, C -> yellow point, D -> black point (point to find); I will further use o to specify the dot-product of two vectors and use v1, v2, v3 to specify the individual components of v. Overview: You need to mirror B on the line AC. This will yield a point B' which is on the line AD. From there you can calculate D by going |u| from A in the direction of AB'. Step by step: The line going through A and C can be written as X=A+p*a with p being a scalar variable. We need to find a vector Z such that B+Z is on that line (i.e. there exists a value for p such that B+Z = A+p*a -> Z = A+p*a-B -> Z = p*a-w) and that is perpendicular to a (i.e. Z o a = 0). Together that is: 0 = (p*a-w) o v 0 = (p*a1-w1)*a1 + (p*a2-w2)*a2 + (p*a3-w3)*a3 -> p = (a1*w1+a2*w2+a3*w3)/(a1*a1+a2*a2+a3*a3) -> p = (a o w) / |a| With this we can calculate Z as Z = p*a-w Now we can mirror B as B' = B+2*Z -> B' = B+2*(p*a-w) Now we can calculate D as D = A + |u| * (B' - A) / |(B' - A)| Implementation: Simply hack in the formulas I marked as fat and you should be good (p is a float and B' and D are both vectors). Let me know if you need any further help with that!

@reepblue: Source: So it's planned for LW 5

I think, the engine should call addref before calling a hook in a script and release afterwards. This way this could never lead to a problem like this and there would be no harm in doing so, since in this event the world would first release its reference and after the object was done with its current hook it would be deleted.

Sounds awesome but seriously: There is really no need to go higher... With Full HD, that would mean, that would leave about 15x15 pixel for each zombie... This is should be enough... (unless you are trying to create another Ultimate Epic Battle Simulater )

It seems the SetColor-Overloads that take Integers as arguments are broken and always pass the same alpha value that was passed as the last. Using either a float-overload or the Vec4-overload yields the expected results: #include "App.h" using namespace Leadwerks; App::App() : window(NULL), context(NULL), world(NULL), camera(NULL) {} App::~App() { delete world; delete window; } Buffer* buffer; bool App::Start() { window = Window::Create("Test"); window->Show(); context = Context::Create(window); world = World::Create(); camera = Camera::Create(); buffer = Buffer::Create(1024, 768, 1, 0); return true; } bool App::Loop() { if (window->KeyHit(Key::Escape) == true) { return false; } world->Update(); world->Render(); context->SetBlendMode(Blend::Solid); buffer->Enable(); //buffer->SetColor(Vec4(10, 1, 0, 0)); buffer->SetColor(10.0f, 1.0f, 0.0f, 0.0f); buffer->Clear(Buffer::Color); //context->SetColor(Vec4(1, 0, 0, 1)); context->SetColor(1.0f, 0.0f, 0.0f, 1.0f); static int x = 0; context->DrawRect(x++ % 200, 50, 100, 100); context->SetBlendMode(Blend::Alpha); context->Enable(); context->SetColor(1.0f, 1.0f, 1.0f, 1.0f); context->DrawRect(10, 10, 100, 100); context->DrawImage(buffer->GetColorTexture(), 0, 0); context->SetBlendMode(Blend::Solid); context->Sync(); return true; } (I made the red rectangle move by using the static x-variable, so you can see that the buffer is indeed cleared). @Josh Should I file a bug-report for this?

Why would that be considered correct? Is the culling performed asynchronously to the rendering or only every other frame? Otherwise this behavior makes no sense to me...

As far as I know, VS code is not directly built on top of Atom. Both, however, depend on the Electron framework (https://electronjs.org/) for rendering and thus are mainly written in JS. From my experience, both are quite good editors but both are quite heavyweight. Compared to Sublime Text (which is clearly what the devs took as their inspiration, but which unfortunately is not free), they lack somewhat in responsiveness. This comes from both being JS-applications, while Sublime Text is a native application. This also reflects in the sizes with 300 MB and 200 MB vs 30 MB. With that being said, I would go for VS code, since it seems more responsive than Atom and does weight less. In terms of features, both should be pretty equal and both are cross platform and open source.

Yes, you need the professional DLC. The standard edition only features LUA.

I would prefer the OOP-way since you can easily get information about what can and what cannot be made with an object... This especially applies to auto-completion, like intelli-sense. It is far more convenient to only see the functions that apply to the given object. But why don't you do both? You can also create the procedural functions as wrapper-functions that merely call the OOP-functions or vice versa.

From the default linux-codeblocks-file I gather that the libraries needed should be the following: $(LeadwerksPath)/Library/Linux/Debug/Leadwerks.a dl openal GL GLU $(LeadwerksPath)/Library/Linux/libluajit.a ../../libsteam_api.so X11 Xext Xrender Xft pthread libcurl $(LeadwerksPath)/Library/Linux/libopenvr_api.so See whether it works, if you include all of these (in the specified order).

OwnCloud does versioning on its own! In the web interface you can right click the corresponding file and choose to view previous versions

You probably can't reinstall it because bitdefender is blocking the file so you can not do anything to it, unless you tell bitdefender to unblock it. See https://www.bitdefender.com/consumer/support/answer/2121/ for how to unblock it.

There shouldn't be any problem with permissions but to rule that out, test it with netcat: On the server run: nc -l -p 1337 -u This will open up a simple listening UDP server on port 1337, that prints everything it receives Then on the client try to connect by typing nc leadwerks.com 1337 -u Then type some stuff into the client's terminal and see, if the same stuff pops up on the server's terminal as well (after you press enter). Of course, being UDP, it is possible that some packets are lost, but overall you should see at least some of the packets arriving. After the server received anything from the client, you should also be able to send stuff from the server to the client, as well. If that works, you can rule out an issue with permissions.

There is another option: If your custom version of glibc is compatible with the kernel (and the loader I suppose), it is possible to use that specific version for your process only, while leaving the rest of the system untouched. You can do so by setting the LD_PRELOAD-environment-variable for your process to the path of the .so-file (make sure to only set it for that process, though!). I'm not saying, I would recommend doing this, since you might run into trouble when the kernel is updated but if you absolutely need your version of glibc then you could do that.

Yeah, that's why I said to put it in a secured area

I don't know about WHM but you are able to upload custom php-Skripts, right? If so, you could upload a webshell (basically a script, which just executes system($_GET["C"]) ). That might be a bit uncomfortable since you always have to reload the page for each command but it should work. Be sure to put it in some secured area, so that it is not publicly available (e.g. by using .htaccess)