[Running a dedicated server]

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.

[Running a dedicated server]

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.

[Running a dedicated server]

1 hour ago, Josh said:

Haha, most insecure script ever. Just looking at that gives me chills. But I guess I can make one that just launches the application.

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

[Running a dedicated server]

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)

[CodeLite IDE support]

You might want to consider supporting cmake. cmake is able to generate projects for different IDEs. So you only have to support the cmake-files and by that you gain support for various IDEs. cmake can e.g. generate Make-files, as well as CodeBlocks-, CodeLite-, Eclipse-, or Sublime-Projects.

Though I really don't know much about it, it looks like something worth looking into!

[Vive / Oculus owners]

I have a vive and will test this later. The last time I tried it, the camera was always stuck at 0,0,0 with no way to move it. Is there some way of moving the camera while having the tracking relative to the movement implemented?

[C++ Random Errors]

A memory leak won't cause access violations! A memory leak is when you allocate space on the heap, by using malloc or new and then simply abandon it without ever releasing it with free or delete. Smart pointers should do that sort of management for you and even if you were to do that wrong, it would simply cause the memory used by your program to rise steadily.

An access violation occurs, when you are trying to access memory in a way you're not supposed to. This means, it is either not in an allocated state (never allocated or allocated and then freed) or it has protections active. In most cases, this happens, when you freed some object but did not set all pointers to null. This sort of problem can cause very weird types of errors. In the worst case, the memory you freed is reallocated for a different purpose and the next time you write to it, you modify some completely different structure

[Leadwerks 5 example]

It might be a good idea to allow us to register a callback before the context-sync is executed, so we can put other drawing stuff there.

[How easy is Linux porting]

Is it a C++ or a LUA-project? In the case of LUA, I think, you don't have to do anything (except maybe e.g. if you hardcoded paths somewhere, you might need to change them to use forward slashes instead of backward slashes). In the case of C++ it depends on the additional includes you are using. The Leadwerks-API-functions should work without modifications, just like most standardlib-funcitons. Unfortunately there are some functions existent in the standardlib, that are not present on the linux-version and vice versa. However, if you didn't do any "exotic" includes, you should be fine.

[Design Question]

You're right, at the moment this is working but what Josh is asking is about the future with smart-pointers. The question is, if the user should have to maintain these source-references for them to keep playing or if the engine should do that for you. (At least that's how I interpreted the question)

[Design Question]

14 minutes ago, Rick said:

Who isnt doing this already today? In Lua people are making class variables to hold thier sounds because you almost always need to play your sound more than once.

Yeah, holding the sound is one thing but holding the sources played from that sound is another thing: If you have a gun, which you can fire quite fast, you will play the sound everytime you pull the trigger. However, you would expect there to be sometimes 3-4 sources of the same sound playing at the same time if you're trigger-happy. This would mean, you'll have to keep a list of all sources emitted around and periodically check, whether you can release the individual sources.

So: It's reasonable to always have a reference to the Sound, but not to all the Sources.

To sum up the design I would prefer with a clear differentiation between Sound and Source:

- Source has a smart-pointer to the Sound, which gets nullified when the source gets deleted. 

- Engine has a list of smart-pointers to all currently playing Sources. As soon as a Source is Stopped/Paused, this smart-pointer is nullified. The reasoning behind this, is that if the user plans to Resume/Restart the Source, they need to have their own smart-pointer anyway (otherwise they have no means of calling Resume()/Play()), which by itself prevents it from getting deleted. (This replaces what I previously stated as the source having a smart-pointer to itself)

 

Bonus: The Sound::Play()-function should return a smart-pointer to the emitted Source-object!

[Design Question]

1 minute ago, Josh said:

I was thinking along those lines.  The engine would maintain a list of all currently playing sources.  However, this would mean you had no way of stopping a source once you lost the handle (other than iterating through the global list, which seems kind of wrong to me).

Correct, if the user wishes to stop the source, they have to keep a pointer to it themselves. If the user only wants to play the source once, without planning on stopping/resuming it, I see no reason, why you would want to force them to keep their own pointer around and continually check, whether the sound is done playing, so they can release it. The way I described it above, the user can choose whether to keep a pointer to it or not. Basically: Whenever the sound is playing, the engine makes sure that it is not deleted, while whenever the sound is not playing, it can be deleted.

If you go down the other route of always forcing the user to keep the pointer, I can already see a new thread coming up every other week complaining about their sounds not playing. I'm pretty sure that for most users, playing a sound is a "fire-and-forget" kind-of-thing.

 

PS.: What I forgot to mention above is, that if the user calls Play() after they called Stop(), the pointer needs to be populated again, of course

[Design Question]

I think, it's most reasonable to have the source maintain a smart pointer to itself. When the sound is finished playing or the user calls Stop(), this smart pointer is set to NULL.

This would mean:

- If the user keeps his own smart-pointer, there will be two smart pointers to the source and it will not be released until it is done playing and the user releases their own one.

- If the user does not keep his own smart-pointer, the source is deleted once it is finished playing.

[C++ Or Lua??]

Regarding Performance:

 

[Getting the right people...]

Oh, I thought, you went there, so you're exposed to cyrillic and thus find a motivation to include unicode support to Leadwerks

[What am I doing wrong?]

The error message tells you that you're missing a fourth argument (#5, because "self.entity" is implicitly #1 and r,g,b are #2, #3, #4), which should be a number! Looking at the documentation (https://www.leadwerks.com/learn?page=API-Reference_Object_Entity_Camera_SetFogColor), you can see that there is also an alpha-value expected.

[how can I do this in c++?]

#include <stdio.h>
#include <unordered_map>
unordered_map<std::string, Model*> models;
...
  
std::stringstream mid_stream;
mid_stream << -dim << ":" << -df << ":" << dim << (...)
std::string mid = mid_stream.str();
if (models.find(mid) == models.end())
{
    Model* model = Model::Create();
    model->SetRotation(orientation);
    models[mid] = model;
}

Edit: meh, 5 minutes too late

[Where you are in the animation]

10 hours ago, Josh said:

We could do something like this:

float GetAnimationTime(int sequence=0)

Where 0 is the last sequence you played, 1 would be the previous one (if it is still active, otherwise 0 is returned), etc.

How about instead having PlayAnimation return a handle/id, which you could later use to query the status?

[Steam?]

To the right, there is a box, which says "Controles del propretaro". if you scroll down, you will see the last item in that box to say the spanish equivalent of "Change Visibility". There you can define who can see your item

[Extra Networking commands.]

17 hours ago, Josh said:

For position, etc. just have an iterator and discard packets that are "older" than the last one received.  Hmmm, new feature candidate?

According to http://enet.bespin.org/Features.html under the heading "Sequencing" (third paragraph), ENet already does that:

Quote

For unreliable packets, ENet will simply discard the lower sequence number packet if a packet with a higher sequence number has already been delivered

 

[AppDataPath()]

Actually, for linux "~" doesn't have any meaning at all... expanding "~" to the current user's home-directory is a feature of most shells (bash, zsh, ...). This means, if you type "~" in the terminal, the shell that is executing in the terminal replaces this by the user's home-directory. However, if you try to use "~" from your program, it will not mean anything to linux and your program can't do anything with it.

Look at the following example-terminal session:

$ echo foo > ~/bar
$ cat ~/bar
foo
$ python
Python 2.7.6 (default, Oct 26 2016, 20:30:19)
[GCC 4.8.4] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> f = open("~/bar")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: [Errno 2] No such file or directory: '~/bar'
>>> f = open("/home/user/bar")
>>>

As you can see, e.g. Python can't find the file "~/bar", since "~" doesn't mean anything to it. Using the complete path, however, works.

The same would hold for your Leadwerks LUA/C++ project: You can't use "~" to refer to the current user's home directory. Using the result of getenv("HOME"), as Josh mentioned, is the correct way to get the home-directory. (And yes, for the SHELL it is equivalent to "~/", but for your program)

[On-screen text messages]

1 hour ago, psychoanima said:

It works, but it scales/changing all fonts in the game, including menus.

Then save the old font:
 

oldfont = context:GetFont()
context:SetFont(myfont)
[write...]
context:SetFont(oldfont)

 

[Screens/Monitors inside gameworld]

You need to create a separate buffer, render to this buffer and set this buffer as the texture for the corresponding material. For a code example, look at the code here: https://www.leadwerks.com/community/topic/16413-draw-on-buffer-to-apply-to-sprite/#comment-107677

 

[Draw on buffer to apply to sprite]

For me the text is red (given, it's a very dark red...). You should be able to make it more visible by using "diffuse+normal+emission+alphamask.shader" and binding the texture to both, channels 0 (diffuse) and 4 (emission):

i.e.:

    local shader = Shader:Load("Shaders/model/diffuse+normal+emission+alphamask.shader")
    local currentBuff = Buffer:GetCurrent()
    local mat = Material:Create()
    mat:SetShader(shader)
    local sprite = Sprite:Create()
    sprite:SetViewMode(0)
    sprite:SetMaterial(mat)
    local buffer = Buffer:Create(20, 20, 1, 1)
    
    -- draw the text on the buffer
    Buffer:SetCurrent(buffer)
    self.context:SetBlendMode(Blend.Alpha)
    self.context:SetColor(Vec4(1, 0, 0, 1))
    self.context:DrawText("Hello", 0, 0)
    local tex = buffer:GetColorTexture(0)
    mat:SetTexture(tex, 0)
    mat:SetTexture(tex, 4)
    Buffer:SetCurrent(currentBuff)

That should make it more crisp.

[Draw on buffer to apply to sprite]

The shader is the problem. Use "Shaders/model/diffuse+normal+alphamask.shader" instead of "diffuse.shader", then it should work.