Forum posts

That's all possible. The current implementation already has code for some of that, but it's unfinished. I'm currently writing CMakeLists for the repository, so expect to see some kind of Linux support soon. I hope it works, but there might be platform compatibility issues.

@Urby:

If i can figure out the file format, sure. I tried to reverse engineer it from Jed's and analyze a dol file, but i didn't get very far.

@EsprimoP:

I'll add an option to the settings then. I'll probably have to move settings loading up a bit for this, but that doesn't matter much.

@fuzun:

That bug never really existed here. Both the original HLMV and Jed's have this problem because the GUI framework they use doesn't handle WM_CLOSE messages properly. This is how it handles them:
[quote]
case WM_CLOSE:

if (g_mainWindow)
{
	if ((void *) hwnd == g_mainWindow->getHandle ())
	{
		mx::quit ();
	}
	else
		ShowWindow (hwnd, SW_HIDE);
}
//else // shouldn't happen
	//DestroyWindow (hwnd);
return 0;

[/quote]

It should be calling DestroyWindow here to close the window properly.

mx::quit only sets a boolean. That boolean is used to exit the main loop.
The problem is that it never posts the quit message using PostQuitMessage, so the event queue doesn't exit and keeps the program alive.

As for the CPU usage, that's either a result of the queue not being processed, or the complete lack of a frame limiter in the render loop causing issues:

[quote]
case mxEvent::Idle:
{

g_studioModel.SetBlending (0, 0.0);
g_studioModel.SetBlending (1, 0.0);

static float prev;
float curr = (float) mx::getTickCount () / 1000.0f;

if (!g_bStopPlaying)
	g_studioModel.AdvanceFrame ((curr - prev) * g_viewerSettings.speedScale);

prev = curr;

if (!g_viewerSettings.pause)
	redraw ();

return 1;

}

[/quote]

Without frame limiting, the program will render every time it's idle. I'm using an idle event based renderer too, but it uses the max fps setting to limit the framerate.

If the source for Jed's were available (this is HLMV 1.25's), it'd be relatively easy to fix by adding the call to PostQuitMessage in mx::quit, and making it process messages until it encounters that message in the queue.

Thanks :). I think that bug might still exist in some form in my build, not entirely sure. I fixed one case earlier today while reworking some stuff, and just fixed the other one i know about. My code was relying on automatic cleanup, which didn't work when the program was under heavy load, like rendering a lot of stuff.

I also improved the find command's syntax for '*' characters. Previously, only "find *" triggered special handling by listing all commands.
Now it will interpret * to mean 0 or more characters to skip when comparing characters.
For example, if you wanted to find all commands and cvars that contain "fps", you can do so by entering "fps", but what if you wanted to find something like "framespersecond"? You can now do this by entering the token "*f*p*s*". This will find both "fps" and "framespersecond".

@EsprimoP:

You mean supporting older OpenGL versions? That's possible, though retained mode will require 2.0 or newer. It's currently configured for 2.1, but i'll see if i can make it configurable.

@J-M:

Thanks

I've been working on a new model viewer for the past few months. I stopped working on it for a month to work on HL: Enhanced, and i started working on it again today.

It currently provides an entirely rebuilt GUI with all of the options that Jed's Model Viewer has, without the bugs.

The complete list of changes can be found here, as well as the download for the latest version:
https://github.com/SamVanheer/HL_Tools/wiki/Half-Life-Model-Viewer

Today's changes concern the tool startup, shutdown and frame logic. Library loading, interface management and the render loop have all been rewritten to be simpler to use and perform better. Due to changes in how the render loop is performed, the FPS can now go much higher than before.
Testing with several models shows you can get up to ~350 FPS on modern hardware, though high poly models and effects will bring that down a bit.

This approach (idle events) comes at the cost of increased CPU usage, comparable to Jed's (~18% CPU usage maximum on my system). I'm thinking of providing the old loop approach (a timer) as an alternative to provide a low CPU overhead alternative.

I'm going to try and deal with the issues that have been reported on the Github repository's Issues page, though some will be harder than others.

One of the things i want to do is convert the repository's projects to CMake to allow for cross platform compilation. Similarly to HL: Enhanced, this will allow me to target Linux, and project files can be generated for Macs as well if someone has the means to do so.

I was informed that automatic builds are an option, so i'll be looking into that. If i can get it to compile Mac builds, i'll try to get that set up as well.

I've also been experimenting with an interface design that would make it somewhat easy to implement a retained mode renderer. Once everything's in place for that, i'll give it a try. If it works, it should boost performance even more.

Finally, i've also been working on a sprite viewer program. I'm planning to integrate it into model viewer, allowing it to switch between different model render UIs on demand. That'll probably take time though. I've also noticed some strange bugs where some sprites are loaded incorrectly. I'm not sure what's going on there, but it's definitely something i'll be investigating.

If anybody has any thoughts or requests, i'd like to hear them. Do note that i can't get to them all right away since these things will take time. Anything graphics related will need to be designed properly to avoid performance issues.

Note sure. Try clearing the Gag flag. That might be preventing it from working somehow.

These flags only apply to monsters that can do idle talk, like scientists. Human Grunts can't do it in vanilla HL. For programmers, any monster that inherits from CTalkMonster supports these.

If the Concurrent flag is NOT set, then multiple monsters can talk. If it's set, other monsters will be silenced.

The Interrupt Speech flag will allow monsters to talk even if their normal conditions would prevent this. For instance, if other monsters are talking, then this flag will ignore that and allow the targeted monster to talk as well. This only works if the monster is alive.

If you use Interrupt Speech with Concurrent, the latest sentence takes priority. All other talking monsters are silenced.

If Concurrent is NOT set and Interrupt Speech isn't set, then the monster might not speak at all if another monster is speaking due to condition checks.

If Interrupt Speech is set, and Concurrent isn't, then you can let any monster talk at any time without being interrupted.

Setting the Gag flag and not setting Interrupt Speech will cause monsters to never speak any sentences.

I know this is confusing. The Concurrent flag actually disables concurrent speech. This is why: https://github.com/ValveSoftware/halflife/blob/master/dlls/scripted.cpp#L1171

The flag's state is inverted. So setting it disables concurrent speech, rather than enabling it.

If setting Interrupt Speech and not setting Concurrent doesn't work, then something else must be wrong.

Is the Followers Only flag set? If so, the scientist will only say something if they're following a player.

Try enabling developer mode. Set developer to 2 or higher to see sentence information in the console. That should help you identify the cause of any problems.

You can flag a trigger_relay as not in deathmatch, then have that trigger something to set up the level for singleplayer, and killtarget an entity that sets it up for deathmatch. Trigger both, with the deathmatch one being triggered a bit later to have a level that supports both.