[C+ Actors - No way to remove them]

I also assumed the actors were being released with entity->Release() but I've never checked.

Maybe the entity only stores a reference to the memory and we need to delete the actor like this?

MyActor* actor = new MyActor();
model->SetActor(actor);

//End of game
delete actor;

 

[Remove Surface]

Would be great if we had the ability via code and in the model editor to remove a surface.  I have a lot of models that usually have other bits and pieces merged with them.  Removing them via the editor would save a lot of time.

[Plane.IntersectsLine()]

Plane.IntersectsLine()

If this function could have an overload to take floats instead of Vec3, that would be awesome.

 

[Shader->GetProgram()]

They're defiantly worth it.  Though I have noticed that I can't use post processing effects with mine...  I'll probably post something in tech assistance soon.

[Shader->GetProgram()]

For billboards?

[Shader->GetProgram()]

I'm using shader storage objects to store precalculated billboard data for my trees.  Faster than using trigonometry functions. ?

[Shader->GetProgram()]

Shader->Getprogram()

vs 

((OpenGLShader*)_shader)->program

would be nice

[QUITING GAMES]

It's probably just a coding error that needs fixing.

[AABB will not detect all entities]

Have you enabled debugging of all AABB's?  I'm away from my pc atm but it somthing like camera->debugAABB().

[Lobby::Count()]

Pity we can't remove them from the lobby.  I thought maybe adding them to the blockedusers list, but not sure what impact this might have elsewhere.

[Lobby::Count()]

It would probably cause a crash somewhere along the line too, as they wont be sending the same data as you.    Maybe when a client joins we test to see if they are running the same game or not.  ?

[Lobby::Count()]

Quote

Creating a new lobby to advertise our game is easy. We just call a command to create it, and then we will set two string values. The game title is set so that we can later retrieve only lobbies that are running this particular game. (This should be done if you are using the SpaceWar app ID instead of your own Steam ID.) We also add a short description that can display information about the game.

I should read more often.

[Lobby::Count()]

When I call Lobby::Count() it retrieves a 49 lobbies.  I think I'll have to use one of the overloads and pass a string attribute that looks for lobbies made for only the current game?

int _totalLobbies = Lobby::Count();
for (int id = 0; id < _totalLobbies; id++) {
	auto _lobby = Lobby::Get(id);
	if (_lobby != nullptr) {
		int _totalMembers = _lobby->CountMembers();
		int _maxPlayers = 32;

		std::string _name = _lobby->GetString("lobbyname");
		std::string _lobbyName = String(id) + " : " + _name + " " + String(_totalMembers) + "/" + String(_maxPlayers);
		Lobbies.push_back(_lobbyName);
	}
	else {
		MessageBox(Window::GetCurrent()->GetHandle(), "Could not load Lobby!", "Error", MB_OK);
	}
}

 

[Creating a Lobby]

Thanks for that.  At the very least I can use set key to send the max players.

[Creating a Lobby]

Just started setting up multiplayer and have a few questions about the lobby;

1. Is creating a lobby specific to the games steam id?  So you can't access other games lobbies...?
2. Can we name lobbies?
3. Can we get what the maximum players has been set to?  Like "lobby->GetMaxPlayers()"

Thanks

[Load Package not keeping folder hierarchy]

Hmm okay.  From what I'm thinking, all of my packages will be around the 10 to 30 MB range.  That way the updates should be small unless I add heaps.  I just didn't like the idea of adding 100+ packages to the main game directory.  I think what I'll do is just re-add the hierarchy into each zip.  That way I won't have to change file paths and can keep them in any sub folder.

[Load Package not keeping folder hierarchy]

You mean one for each top level folder?  I.e. Shaders, Scripts, Sound, Models, etc.  If that's the case then I think they still be quite big.

[Load Package not keeping folder hierarchy]

This is why I think it would be better to package the game data into smaller zip files rather than one large one.  If we can get the package system to keep the directory relative to the pack itself rather than the base directory, I think it would be easier.

[Load Package not keeping folder hierarchy]

Here we go; https://partner.steamgames.com/doc/sdk/uploading#Building_Efficient_Depots

Quote

Building Efficient Depots for SteamPipe

The old Steam content system would patch updates on a file level, which meant that if a single byte in a file changed, the entire new file would be downloaded by all users. This was especially inefficient if the game used pack files, which are collections of game content files in a single big file. Pack files can easily exceed 1 GB, so updates often led to unnecessarily large downloads. A common way to avoid these large downloads was to add new pack files that overrode content of already shipped pack files. That worked for updates, but it hurt new users long-term, since they ended up downloading unused, already-patched content.

The new content system fixes this problem by splitting each file into roughly 1-MB chunks. Each chunk is then compressed and encrypted before being distributed by the Steam content system. If the game content has large redundant parts, these chunks are reused and the user only has to download each repeated chunk once. However, the real strength of this system is building efficient update patches. While the system is building a patch, the new content is scanned for already known chunks. If it finds them, it reuses them. This means if you change or inject a few bytes in a big file, the user only has to download the changes.

This works well in most cases, but there are still a few pitfalls that need to be avoided when designing the content layout of a game. Do not compress or encrypt your game data. This is already done for in-flight downloads and retail discs by the Steam content system. If you do it too, you will reduce the effectiveness of delta patching. If you package multiple data files in a single pack file, make sure that with each re-packaging, no unnecessary changes are made. One problematic practice is including the full name of the original source files on disk, because the names may change, depending on the build machine. Another bad pattern is including build time stamps for each file. If possible, always add new content to the end of your pack files and keep the order of existing files. Also, keep your pack file’s metadata (offset and sizes to individual files) in one place and don’t intersperse it with content files. Use a binary diff’ing tool like BeyondCompare to look at two builds of your pack files to make sure that hundreds of unwanted changes don’t show up.

If you follow these rules you will minimize patch sizes and only new content will need to be downloaded. Your customers will thank you for that and you will be able to increase the quality of your product by shipping more updates.

 

[Load Package not keeping folder hierarchy]

I haven't found the Steam-works docs yet but a google search showed this;

Quote

Each and every game on Steam is considered by Steam to be made up of 1MB blocks. When a developer prepares to upload a new version of a game to Steam, the Steam tools scan the game's files, and works out how to make that new version of the game out of the data blocks it already knows about, and uploads any new data blocks that it finds, along with a manifest which specifies how to build that game version out of the blocks.

When you download an update, what the Steam client does is downloads the manifest for the new version, then begins to build the new version of the game in a separate "downloading" folder in the "SteamApps" folder. It does this by comparing the new manifest with the old manifest for the version of the game you already have downloaded. It works out which data blocks it can copy across from the existing install (by using the old manifest to look up where in the existing files a particular block can be found), and which it has to download.

Once the new version of the game is fully built by copying and downloading, Steam deletes the old version of the game, and replaces it with the new version.

I think with encryption and/or compression, more than 1MB of data can change meaning the entire zip archive could be downloaded again for only a small file change.

[Load Package not keeping folder hierarchy]

From memory though it doesn't work on encrypted files.  I'll have to find where I saw it.

[Load Package not keeping folder hierarchy]

Yeah that's it.  I guess if it's not a bug, I could keep them in the base directory, or I could just change the path to them once the game is published.  It'll just be a pain to change all the file paths.  It's a shame really that many packages are needed for steam to keep the update sizes down.

[Load Package not keeping folder hierarchy]

I'm sure I'm not explaining it right.  All my assets are in sub folders as per usual.  When I want to publish the game i package up a group of files in each of the folders so when steam users download the update it's not massive.  Loading each package works well, but I then cant load assets from the package because the file path to that asset has been changed.  Instead of being this;

C:/Users/Matt/Desktop/The Seventh World/GameData/Icons/Bark.tex

it needs to be this in order to work;

C:/Users/Matt/Desktop/The Seventh World/Bark.tex

The zip package is in;

GameData/Icons/ICONS.zip

"GameData/Icons/" has to be removed in order for the texture to be loaded.

 

Hope that's better.  Otherwise I'll put an example together.

[Load Package not keeping folder hierarchy]

Okay I'll be able to put one together later.

[Load Package not keeping folder hierarchy]

But zipping a sub-directory means I can't access those files with the same path as though they are not zipped...?