Added bxt_skybox_reload and bxt_skybox_name

[SmileyAG]

No description provided.

[khanghugo]

My rationale behind having 2 commands is persistence after changelevel. On top of that, it is easier to see what is in place.

[SmileyAG]

Well, you know, I got thought and yeah u have a point about having a cvar + command, since if changelevel happen then it would require updating skybox for the same texture, and it simply enough to type bxt_skybox_reload

But, I wouldn't call the my idea is non-rational too, since typing in one command is really faster, therefore, I have the idea: why we wouldn't combine both of that?

That how it should look:

struct HwDLL::Cmd_BXT_Skybox_Reload
{
	USAGE("Usage: bxt_skybox_reload\n bxt_skybox_reload <name>\n");

	static void handler()
	{
		handler(CVars::bxt_skybox_name.GetString().c_str());
	}

	static void handler(const char *name)
	{
		auto &hw = HwDLL::GetInstance();
		if (hw.ORIG_R_LoadSkys && hw.gLoadSky && hw.movevars)
		{
			*hw.gLoadSky = 1; // Same as calling R_InitSky() function
			strncpy(hw.movevars->skyName, name, sizeof(hw.movevars->skyName) - 1);
			hw.ORIG_R_LoadSkys();
		}
	}
};

[khanghugo]

This seems just like bxt-rs implementation but bxt_skybox_reload also has an argument to load skybox right away. I guess that works.

Whatever more convenient is better.

[YaLTeR]

Why not just use bxt-rs tbh

[SmileyAG]

Why not just use bxt-rs tbh

You can, of course, call my opinion biased, but I will express it as I see it and from what I have previously observed of others over months and I personally think it is partly rational to argue this way:

Half of peoples don’t consider themselves bothering with the installation because in the majority it is positioned as a tool for capturing demos and extended TAS functionality (so they may not know that there are also some commands that do not relate to all this, say, forcing FOV with bxt_force_fov), some simply do not know about the existence of bxt-rs, some simply do not know how to install it (although reading the readme on the repository page does not amount to labor and it does not have overly complex instructions, but there are people for whom this is a whole challenge, for them just give them an unpack where you need to run one file so that everything you need will start, like GoldSrc Package)

Therefore, I personally believe that everything that is not directly related to capturing demos or special TAS functionality should be equally ported to BunnymodXT too (after all, many people use it even if you don’t like the some decisions that were made in its code, it it has been included in speedrun builds for a long time, mandatory for RTA runs, has most of the important functionality)

I'm not disrespecting bxt-rs, I generally like some of the decisions that were made there and it might more flexible to switch for other programming language (because of the some convenient standards in this language that will simplify and make it nicer the task for which in another language you would need to create uglier solutions instead for achieving the same specific goal)
But let continue to be positioned as a tool for capturing demos and special TAS functionality, we have to accept the reality that most of content is would be covered from BunnymodXT and no matter how pleasant or not it is for us to realize this fact at least for now

[YaLTeR]

Thanks