Einlander

If you use the in game menu to change the lighting quality, the lighting seems to be disabled. The shadows disappear and it looks like the scene is only lit with ambient light.

It would be interesting if the asian market latches on to Leadwerks since it is a lower long term cost than Unity and Unreal. Thats a huge market. Them and russia.

"current" desktop resolution. Like if I play this on my TV using HDMI/VGA out. I would want it to run at 720p, but Leadwerks would default to 1080i and I wouldn't want that.

Hey now, I like utf8, I have just never had to deal with coding anything Unicode on Linux. All os's could have conflicting implementations. Is there a bsd/public domain lib that handles Unicode ?

https://www.leadwerks.com/community/topic/15771-beam-class/

I would make sure that the rest of the engine works with utf8 and let lua itself fail with the encoding. 5.3 has utf8 support https://www.lua.org/manual/5.3/manual.html#6.5 but it's not very robust. Since it is still early, you do have the option to choose Lua derived language or a completely different language not based on Lua. As distasteful as it may be the API is changing, the scripts will need to be updated and it might be simpler to start over early with something else. Who knows.

There really should be a function to get the desktop resolution.

I found this blog post a few days ago through reddit to be insightful. https://www.joelonsoftware.com/2003/10/08/the-absolute-minimum-every-software-developer-absolutely-positively-must-know-about-unicode-and-character-sets-no-excuses/ It made me realise everything other than utf-16 is basically a beautiful hack. it also speaks to the about wcs functions in c++

Yes that is the part that is giving you issues. --if gamemenu:Hidden() then --Update the app timing Time:Update() --Update the world world:Update() --end This would keep the game running in the background when you are in a menu. But there is a HUGE catch/problem. Any script that reads input needs to be edited to be made aware that a menu is open or to ignore input. Any script that reads or sets the mouses position or the keyboard or mouses key state will need to be edited. For example,the fpsplayer script will will move your mouse to the middle of the screen and you will not be able to select anything. So you will need to think of a way to let all scripts know that they are in a menu.

Restarted my networking framework yet again. This time I gave it a new name 'Hexe'. The old name was 'Overwatch'. It was named long before the Overwatch game came out. It was based off the Half-Life Overwatch. It oversaw the players, ai spawning, contained a secondary path-finding system, but had no networking as it was not native to the LUA side of Leadwerks. 'Hexe' is German for 'witch'. I don't really know why I chose the name but I have the feeling I will be able to put it to good use. Maybe I'll even mix in some Anglish into it. This restart occurred because the framework became too cumbersome. I had the entity synchronization working correctly, but it did not differentiate between player and an object in the world. That wasn't really that bad, what made messed it up was that a lobby system and teams were needed and there was no space to squeeze any other components into the mix. This rewrite will focus on the player/client and foremost. The components that are currently being written or are complete are: The server browser. This was a side project created out of necessity. I did not want to have to hard code the ip every time. Anytime I wanted to test multiple clients I had to change the code depending on which computer was running the server. PITFALL: Since Leadwerks does not expose the servers local ip address via code, you will need to get it manually from you computer, or use some creative workarounds Network Manager Hexe is split up between a server class and a client class. Both classes use a network manager class that can automatically handle hosting or connecting to a server. The network manager currently handles the handshake and the beginnings of the lobby system. When a client joins it initiates and handles the handshake between the server and client. It also raises events so the server or client can react accordingly if need be. After the handshake is completed, the network manager starts the lobby system The connection handshake. This is was saved from the last version. It makes sure the server and client are using the same protocol version. It will then register the client on the server and give it an incremental number (similar to the source engine) that allows the client state to be manipulated The Lobbying system: This is completely new. After the handshake is complete, it will send a command launching the lobbying system. The network manager only makes sure that a client is in the servers lobby and nothing more. The client and server manually handle the team creation and player switching on their own. Teams are not part of the network manager because it would require large amounts of rewrites depending on the type of game being created. When the lobbying system is complete the client input will be added. So far things are going well and maybe soon I wont be staring at console output for feedback.

I've spent the last few days creating a simple self contained server browser. It will list all the servers of a specific game, allow the user to select a server and send a callback with the selected info. Requirements: The script from this topic placed in a file here: Scripts/Functions/eventqueuemanager.lua The Script: A simple example: It will create a server and open a server browser window. + Starts the move mode, click to exit it. X closes the window. import("Scripts/Functions/eventqueuemanager.lua") import("Scripts/serverbrowser.lua") local window = Window:Create() local context = Context:Create(window) local server = Server:Create() System:Print("Server1 publish::" .. tostring(server:Publish("Example Temp Test Server", "Testing population of server list from masterserver "))) server:Release() function test(ip,port,close) -- callback function System:Print("Callback") System:Print(ip) System:Print(tostring((close == true) and "close" or "")) end local serverbrowser = serverBrowser("Example Temp Test Server",context,0,0) -- create the serverbrowser serverbrowser:SetCallback(test) -- set callback -- do stuff while true do if window:Closed() then return end if window:KeyHit(Key.Escape) then return end Time:Update() context:SetColor(0,0,0,0) -- need to clear alpha!! or the gui will stay on screen!! context:Clear() EventQueueManager:Update() context:Sync() end serverbrowser:ClearCallback() -- remove callback serverbrowser:Release() -- release everything The server browser will obey the limits of your window. If any part of it is not on screen, it will be pushed back onto it. Edits: -2017-8-24: -Added the ability to directly connect to a ip and port. -Moved the code to put the window into a function and check on server browser creation. -2017-8-25: -Added the abilitiy to automatically resize to fit inside the bounds of the current context

[I had text here but in the edit it dissapeared ] I found that there can only be one instance of the EventQueue. This meant that all the widget events need to be handled in a single location leading to possible complications in code and lowering the possibility to dynamic things. This script allows the developer to subscribe to an eventqueue manager and get their event safely, without usurping all gui controls. The script will automatically create an EventQueueManager variable that all other scripts can expect. To use it from a script not attached to an entity use: EventQueueManager:AddListener(Update) -- a simple function On a script attached to an entity or a lua based class use: EventQueueManager:AddListener(serverbrowser.Update) -- convert : into . Place the script into a file at: Scripts/Functions/eventqueuemanager.lua

I am trying to have a generic gui class and I realized that there can be only 1 EventQueue. This means that all widgets must be managed from a single area. This means that I can't create a gui class that handles its own events without using some creative methods that have some serious edge cases. I would like to specify my own function/callback/eventqueue to call for each widget item. It would allow people to create safe, shareable scripts. I would like to create a widget and pass it a local eventqueue such as this one and handle all the events locally.

I discovered that there can only be one eventqueue in leadwerks. I wanted local eventqueue instances, so I created a lua based version of EventQueue called EventQueueEx It is initialized as such: MyQueue = EventQueueEx:Create() It is used EXACTLY the same as the Leadwerks version.

The server list seems to fail when attempting to register multiple servers from the same server but different port. Also, it will fail to register if the name is just one word. Example: server = Server:Create() System:Print("Server1 publish::" .. tostring(server:Publish("Einlanders server stub", "Testing population of server list from masterserver "))) server2 = Server:Create(27015) System:Print("Server2 publish::" .. tostring(server2:Publish("Einlanders server stub", "Testing population of server list from masterserver 2"))) client = Client:Create() local servercount = client:CountServers("Einlanders server stub") System:Print("Server Count::" .. tostring(servercount)) for i=0, servercount-1 do remoteServerData = client:GetServer(i) System:Print("Server Name::" .. remoteServerData.address .."#### Description" .. remoteServerData.description) end The Output: Server1 publish::true ERROR Server2 publish::false Server Count::1 Server Name::xxx.xxx.xxx.xxx#### DescriptionTesting pupulation of server list from masterserver

While writing a server browser I discovered that RemoteGame does not not have a port property. So if you do set your server on a non default port, you will not be able to connect to it by using the server list. Which leads to this issue:

Or to make it programmatically simple but adventurous: Start in a cell where there is just a door, and a high window going outside. Can't open the door, locked. Go inspect high window, bars are loose and one falls off. Pick the bar up, it becomes your first weapon. Inspect the bars again and the player begins hitting the bars breaking it open. When it opens guard comes and opens the door to see what is happening, you need to kill the guard. Player can loot guards body for keys to storage chest where they get their starting items.

Start in a hanging cage. Player needs to run back and forth to make the cage swing towards a wall that has the keys on it. Or same idea but you need to swing towards a guard sitting down and sleeping in a chair. Once you have the key you escape and leave the area or kill the guard.

Still doesn't change the fact that you get artifacts with dxt5n. Random specs here and there and round normals become pixelated.

You simply send the key input and mouse input to the server as you were thinking. The server does the setinput, gets the new location of the player and sends it to the client.

i think he means instead of dxt5, use uncompressed for the texture type. Leadwerks will introduce bad artifacts into your normal map with any type of compression.

I don't think Leadwerks supports unreliable packets. We only have the option of Message.Reliable and Message.Ordered BTW the headers say Message.Sequenced and not Ordered.

Yeah i just found a blog talking about this. http://www.gabrielgambetta.com/client-side-prediction-server-reconciliation.html This will probably need to wait till I have another day off to implement a clientside buffer. The server already has a rolling buffer of 5 frames and 20 world states just because. I knew I would use it one day, but I didn't know it would be this soon. I'm learning all sorts of new things about networking!

With regards to player input, the player would be x frames behind the server. Would the server be applying the input to the most recent frame or x - 1 frames?

When I introduce lag, it's not losing packets, so the all get there eventually. So when they get there they are processed. I have it so that every client update loop it reads from the network 10 times unless it is null. This allows it to 'catch up' with the server if it falls behind. There is no real way other than timestamps synced with the server to know if you are falling behind. http://einlander.duckdns.org:8000/f/6525b9e505824bbba98f/ This is a link of how it looks. Right side is the client. I can hold a button and it will not check the network at all. And after 10 seconds iirc it will disconnect from the server. When it starts reading the network messages it has to go through the entire backlog since eNet has reliable messages, and wont drop them.