Pretty underwhelming compared to the cool stuff in here so far but I'm redoing Holopad because the old code was a mess and I ran into a few roadblocks with it. New approach is keeping all elements in separate frames and using better OOP principles, and dear god this is working better. Faster progress too because I still have the old code and a new class diagram to look at. 0 to this, super quick;

(don't suppose anyone would like to take this concept art for a breen-statue NPC? )

Found some very odd results when messing with the MYSQLOO module. It's hard to explain what exactly is happening, or atleast logically. Essentially this is what i have noticed:

Using normal query (callback functions)
-Long delay before the queries are called (nearly 1 second per 10 queries)
-Once the queries are called, they are called EXTREMELY FAST

Using wait query (Query2 function, using the query:wait())
-Instantly starts the queries
-Each query takes about a tenth of a second (coincidence?)

Total time seems to always seems to come close to each other.
From what i understand about threading, for the normal queries, the data could be getting queried and retrieved during that strange delay period, and then afterwards once the thread rejoins it is running the callback functions, which takes no time at all, which explains the next to zero execution time. Since they are threaded, and possibly ran all at once since they are all made instantaneously, they may all be loaded onto one thread to be ran, and then their callbacks are run when the thread finishes.

Found some very odd results when messing with the MYSQLOO module. It's hard to explain what exactly is happening, or atleast logically. Essentially this is what i have noticed:

Using normal query (callback functions)
-Long delay before the queries are called (nearly 1 second per 10 queries)
-Once the queries are called, they are called EXTREMELY FAST

Using wait query (Query2 function, using the query:wait())
-Instantly starts the queries
-Each query takes about a tenth of a second (coincidence?)

Total time seems to always seems to come close to each other.
From what i understand about threading, for the normal queries, the data could be getting queried and retrieved during that strange delay period, and then afterwards once the thread rejoins it is running the callback functions, which takes no time at all, which explains the next to zero execution time. Since they are threaded, and possibly ran all at once since they are all made instantaneously, they may all be loaded onto one thread to be ran, and then their callbacks are run when the thread finishes.

It exports a 4096^2 heightmap in png format. I used Python and a couple of libraries to read the png and convert it to chunks. Each chunk is 32^2 tiles and in total there are 4096 chunks.

The chunks are simply binary shorts stored in files. Each chunk is 8KB of data. In total there are 32MB of world data. Of course this isn't really that bad considering networking is progressive as the clients move across the massive world.

In the first image, the sublime text file is showing the python code I used to turn the png into binary chunk files. The window on the top left is a pygame display I whipped up in that script to show the chunks and their average height ( it's just eye candy ;) )

Since Gmod13 lets us read binary data now, I was easily able to make a chunk parser in-game and have a chunk rendered...

I've been working on engine sounds and other details on SCars.
Have tried to mix several engine sounds before at different RPMs because it's how most racing games do it to get a good engine sound.
Each time I've tried it I've failed.
Have always sounded weird or choppy.

Think this was my third try and this time I actually succeed.
Sounds a lot better than just pitching a single sound.

Also got a model from TDM which allowed me to change the steering wheel, rpm gage and the speedometer through poseparams.
Sometimes it's the details that matters after all.

I've been working on engine sounds and other details on SCars.
Have tried to mix several engine sounds before at different RPMs because it's how most racing games do it to get a good engine sound.
Each time I've tried it I've failed.
Have always sounded weird or choppy.

Think this was my third try and this time I actually succeed.
Sounds a lot better than just pitching a single sound.

Also got a model from TDM which allowed me to change the steering wheel, rpm gage and the speedometer through poseparams.
Sometimes it's the details that matters after all.

The engine sounds have always bothered me, but now they sound fantastic.
Great work.

I've been working on engine sounds and other details on SCars.
Have tried to mix several engine sounds before at different RPMs because it's how most racing games do it to get a good engine sound.
Each time I've tried it I've failed.
Have always sounded weird or choppy.

Think this was my third try and this time I actually succeed.
Sounds a lot better than just pitching a single sound.

Also got a model from TDM which allowed me to change the steering wheel, rpm gage and the speedometer through poseparams.
Sometimes it's the details that matters after all.

After some down time due to life (mainly due to my father and how his perception/comprehension deemed my words as false, when they had a far deeper meaning, taking away my main laptop, and since he's a stubborn/hardheaded fat & candy-assgot, I'm not even bothering arguing), I got some work done with the Minecraft-esque addon.

In Minecraft, not all blocks are perfect cubes. Liquids (lava and water), farm land, stairs, end portal frame, portals, doors, signs, rails, seeds, pressure plates, pistons, vines, ladders, saplings, tall grass, etc. etc., blah and blah, and of course half slabs. To easily add support for new blocks, such as adding slopes and what-not's, why not have a value / function to render out the vertices of a block, instead of having predefined vertices during chunk mesh rendering. Plus with a separate function to render out the block, it'll be better to call specific checks, such as rendering a portion of a side, such as if there's a block like farm land near the side that's being rendered.

Of course, due to the possibly-QQful aside/anecdote/whatever and the lack of a good computer to show it off, I can't really show that in action. Plus with the lack of documentation with meshes, it'll be a while to actually show it. I am using a MacBook (Yes, they are bad, but surprisingly good frame rate on high video settings, which is really weird because it gets higher frame rate than lowest graphic settings.

I apologize for the, once again, large wall of QQ and blog-esque post. Just pissed. Oh, and also contemplating about deep, philosophical shit.

Edited:

I almost forgot. I was working on adding the Clock Town music to play in the LoZ addon, but I didn't really continue with it, since 'net.WriteTable()' breaking and all. I'm updating the Workshop version to support this. Alas, the rain on Day 2 prevents the song from playing.

Edited:

If only 'util.AddNetworkString()' worked faster. Running this addon under Singleplayer makes it where I have to delay the two 'net' streams to send the world data (seed, chunk sizes, render distance) and the initial chunk data (position, blocks). On a dedicated server, it wouldn't really matter as you can easily delay when a player initializes by not joining as soon as the server gets up. But, there's an issue with map changes, which I highly doubt since this project is now not aiming for "what could I do with adding this to any game mode and what practical purpose this will serve?".

Edited:

Hm... So the issue wasn't due to 'util.AddNetworkString()', but it was because I forgot to add '[ufDOS]' before streaming. Anyways, a new issue has occurred:

I added, to the 'Stream' module thing, stream queuing, plus adding the callback functions to the table. It's nothing neat, it's just a delay by how long and uses a 'timer.Simple()'. Nothing fancy. It was just an alternative to delaying everything, but that entire error was due to string mismatches. I'm starting to get sick of that.

While I was contemplating on how the hell will I get data values, the ones that tell apart birch logs from oak, and different wool colors, since it'll be costly to add that into a table for chunks and block data, why not use floats?

For example, wool's ID in Minecraft is '35'. Black wool is '35:15'. In the instance of storing the block data, it would be '35.15'.
The block ID can be obtained by using 'math.floor()', while the data value can be obtained by '35.15 - math.floor(35.15)' I'm sure there's a much easier alternative to grab the decimal number. In theory, this would allow an infinite amount of block combinations under one block. Perfect to keep shit organized! There's still the issue with memory, and since I don't know how to easily store bytes like the C# interpretation, I guess I'll have to deal with the RAM usage.

Too bad that the mechanic mentioned above won't see light for a while. Still working on meshes, which I'm probably going at a completely wrong angle at it.

Thanks. My father is a bit... anal, about me and 'electronic devices/entertainment'. Just can't wait until I move out. As long as I have this horrible-yet-lasting MacBook, I should be able to push content still. That, or I could sell it and buy another Asus G53 or something and keep it hidden like Anne Frank, minus the attic. Oh look, more blog-esque posts that can be comprehended as QQ. Gee...

I added, to the 'Stream' module thing, stream queuing, plus adding the callback functions to the table. It's nothing neat, it's just a delay by how long and uses a 'timer.Simple()'. Nothing fancy. It was just an alternative to delaying everything, but that entire error was due to string mismatches. I'm starting to get sick of that.

While I was contemplating on how the hell will I get data values, the ones that tell apart birch logs from oak, and different wool colors, since it'll be costly to add that into a table for chunks and block data, why not use floats?

For example, wool's ID in Minecraft is '35'. Black wool is '35:15'. In the instance of storing the block data, it would be '35.15'.
The block ID can be obtained by using 'math.floor()', while the data value can be obtained by '35.15 - math.floor(35.15)' I'm sure there's a much easier alternative to grab the decimal number. In theory, this would allow an infinite amount of block combinations under one block. Perfect to keep shit organized! There's still the issue with memory, and since I don't know how to easily store bytes like the C# interpretation, I guess I'll have to deal with the RAM usage.

Too bad that the mechanic mentioned above won't see light for a while. Still working on meshes, which I'm probably going at a completely wrong angle at it.

[offtopic]

Thanks. My father is a bit... anal, about me and 'electronic devices/entertainment'. Just can't wait until I move out. As long as I have this horrible-yet-lasting MacBook, I should be able to push content still. That, or I could sell it and buy another Asus G53 or something and keep it hidden like Anne Frank, minus the attic. Oh look, more blog-esque posts that can be comprehended as QQ. Gee...

Last night (or earlier this morning), while trying to get meshes working, I thought of an easy way to prevent something like "zombe's ore finder" in Minecraft. Instead of streaming out the blocks, why not stream out the vertices? With that, there will be no need to calculate the vertices twice, once for client and once for server, and there will be no way to truly have an ore finder.

Alas, there's a complication. There can be a shit ton of vertices in a 32^3 world, versus sending out a constant 32^3 amount of numbers into the world. For a flat world, there will be 4 vertices for each face, so about 1024 vertices. Sure, 1024 is smaller than 32^3 (or 32768), but vertices are Vectors, more data than numbers.

I'll give sending the vertices idea a try. When the previously mentioned idea about rendering vertices based on a block, it will/should prevent any mismatches if the client's values are modified somehow.

The texture, material, hardness, and light aren't being used right now. Opaque the main value for rendering the sides. If the neighboring block is not opaque, then it'll render the corresponding side. While most examples on how to make a simple voxel engine uses Solid as the variable to render a side, there's a lot of caveats, such as ice is opaque, while it's solid, yet you can see through it. Same with glass, farm land, doors, fences, and other blocks.

The vertices functions, like Left and Right, are what renders that corresponding side. The 'Table' argument is not needed, as that's only used to store the vertices into a table. This is mainly for the Entity.PhysicsFromMesh function. Calling this function without 'Table' would use 'mesh.Position' and such to render the side.

Well I'm on a roadtrip of what seems to be around the entire state of Pennsylvania... so I was able to crank out some cool things for the Sassilization Deathrun again. I added new RTD effects :>

-Bombard (typical bombard effect, you freeze - cloud forms above you and arrows fall down on to you)
-Decimate (get set on fire)
-Heal (heals you obviously)
-Paralyze (freezes you for 10 seconds)
-Blast (explodes you)
-Gravitate (sends you flying up into the air at 300 velocity)
-Vanish (invisible for the rest of the round)
-Treason (swaps your team)
-Strike (lightning strike comes down and takes 50hp away)

Speaking of this, how come props aren't lit per triangle yet? Most modern games and I think CS:GO have lighting like that. In GMod either props, players, and viewmodels are always uniformly lit, which is unrealistic in many cases.