Forum posts
- Forums
- Posts
- Posted by
Solokiller
This post was made on a thread that has been deleted.
This post was made on a thread that has been deleted.
This post was made on a thread that has been deleted.
This post was made on a thread that has been deleted.
This post was made on a thread that has been deleted.
This post was made on a thread that has been deleted.
This post was made on a thread that has been deleted.
This post was made on a thread that has been deleted.
This post was made on a thread that has been deleted.
That makes sense, if a scripted sequence tries to possess an entity and it can't, it'll cancel itself (and all other scripts with the same name) instead. So triggering an active script just cancels it.
Try using another scripted_sequence that has walk or run to mark that instantly ends, i think that's how teleport was intended to be used.
This post was made on a thread that has been deleted.
The weapon strip entity has no option to exclude the bomb.
I looked for more information on Joe.to's forums, their mappers did stuff like this in the past. Here's what i found: https://forums.joe.to/viewtopic.php?f=163&t=48274
Unfortunately not much help, you'll have to handle the assignment of the bomb yourself i guess.
I looked for more information on Joe.to's forums, their mappers did stuff like this in the past. Here's what i found: https://forums.joe.to/viewtopic.php?f=163&t=48274
Unfortunately not much help, you'll have to handle the assignment of the bomb yourself i guess.
I think it needs ambient lighting to light those shadows properly. Not sure if light_spot has that option though.
This post was made on a thread that has been deleted.
This post was made on a thread that has been deleted.
MFC has a structure that is very similar to wxWidgets, but it's an obsolete library for a reason. It uses outdated design practices like absolute positioning so try to avoid it if you can.
As far as i know this isn't possible. You can trigger muzzle flashes, but sprites and particles are something that must be handled by the game's code.
The Gargantua handles this by creating a sprite and attaching it to the monster's eye attachment.
You can use event 5002 to generate spark effects at attachment 0 though: https://github.com/ValveSoftware/halflife/blob/5d761709a31ce1e71488f2668321de05f791b405/cl_dll/entity.cpp#L366
The options string is the number of sparks to create.
The Gargantua handles this by creating a sprite and attaching it to the monster's eye attachment.
You can use event 5002 to generate spark effects at attachment 0 though: https://github.com/ValveSoftware/halflife/blob/5d761709a31ce1e71488f2668321de05f791b405/cl_dll/entity.cpp#L366
The options string is the number of sparks to create.
Hammer doesn't use wxWidgets, it uses MFC.
I actually investigated the wgl error, it happens when multiple maps are open and Hammer tries to shut down OpenGL multiple times. I think i fixed that in Sven Co-op's Hammer as well.
I actually investigated the wgl error, it happens when multiple maps are open and Hammer tries to shut down OpenGL multiple times. I think i fixed that in Sven Co-op's Hammer as well.
The game will automatically apply all game_player_equip entities to spawning players if they don't have the "USE only" flag set: https://github.com/ValveSoftware/halflife/blob/5d761709a31ce1e71488f2668321de05f791b405/dlls/multiplay_gamerules.cpp#L551
https://github.com/ValveSoftware/halflife/blob/5d761709a31ce1e71488f2668321de05f791b405/dlls/maprules.cpp#L815
Try setting that flag, it might be triggering them twice.
https://github.com/ValveSoftware/halflife/blob/5d761709a31ce1e71488f2668321de05f791b405/dlls/maprules.cpp#L815
Try setting that flag, it might be triggering them twice.
The SayText network message is used to send chat to all players. On the client side, the CHudSayText::MsgFunc_SayText method receives that message.
See https://github.com/ValveSoftware/halflife/blob/5d761709a31ce1e71488f2668321de05f791b405/cl_dll/saytext.cpp#L166 for more information, the CHudSayText class takes care of chat history and drawing.
See https://github.com/ValveSoftware/halflife/blob/5d761709a31ce1e71488f2668321de05f791b405/cl_dll/saytext.cpp#L166 for more information, the CHudSayText class takes care of chat history and drawing.
This post was made on a thread that has been deleted.
If you're using the Github SDK you can just use Visual Studio 2013 Community, which is free. I'd recommend using that one over any older version because it has SDL support in it.
SDK: https://github.com/ValveSoftware/halflife
VS2013: https://www.visualstudio.com/en-us/news/releasenotes/vs2013-community-vs
To set up a mod directory, create a directory in common/Half-Life with the name for your mod directory. This is usually a one word name, an abbreviation of your mod.
The bare minimum that you'll need is a liblist.gam to point to your server dll, which will reside in Half-Life/modname/dlls. You'll probably also want a client dll, which will reside in Half-Life/modname/cl_dlls.
Your mod will be able to use Half-Life's files by default (with a few exceptions), so you won't need to copy any content over. Files like wads, models, etc can be be used automatically.
You'll need to configure Visual Studio to copy the compiled dlls to your mod directory; you can hardcode the path but then anybody else that uses your codebase will need to have Half-Life installed in the same place, so i suggest adding a PATH environment variable that points to your Steam common directory.
Then you can just copy dlls to ${STEAMCOMMON}/Half-Life/modname/dlls (or cl_dlls for client dlls).
SDK: https://github.com/ValveSoftware/halflife
VS2013: https://www.visualstudio.com/en-us/news/releasenotes/vs2013-community-vs
To set up a mod directory, create a directory in common/Half-Life with the name for your mod directory. This is usually a one word name, an abbreviation of your mod.
The bare minimum that you'll need is a liblist.gam to point to your server dll, which will reside in Half-Life/modname/dlls. You'll probably also want a client dll, which will reside in Half-Life/modname/cl_dlls.
Your mod will be able to use Half-Life's files by default (with a few exceptions), so you won't need to copy any content over. Files like wads, models, etc can be be used automatically.
You'll need to configure Visual Studio to copy the compiled dlls to your mod directory; you can hardcode the path but then anybody else that uses your codebase will need to have Half-Life installed in the same place, so i suggest adding a PATH environment variable that points to your Steam common directory.
Then you can just copy dlls to ${STEAMCOMMON}/Half-Life/modname/dlls (or cl_dlls for client dlls).
@Cd5ssmffan: Id Software limited it to 256², Valve never changed it. It's hardcoded in such a manner that it can't be changed without patching the engine, which will likely trigger VAC bans.
Some render modes only work for some types of models. It could be possible that some are outright ignored as well, i see that only a few are handled directly in render mode changing functions.
The engine hardcodes the OpenGL image size (R_LoadSkys):
Quake equivalent: https://github.com/id-Software/Quake/blob/bf4ac424ce754894ac8f1dae6a3981954bc9852d/WinQuake/gl_warp.c#L661
I guess you could request the maximum be increased, so i did that: https://github.com/ValveSoftware/halflife/issues/1765
It's not very likely to happen though.
glTexImage2D(GL_TEXTURE_2D, 0, GL_COLOR_INDEX8_EXT, 256, 256, 0, GL_COLOR_INDEX, GL_UNSIGNED_BYTE, pImage);Where pImage is the image data, and the value 256 is used for width and height.
Quake equivalent: https://github.com/id-Software/Quake/blob/bf4ac424ce754894ac8f1dae6a3981954bc9852d/WinQuake/gl_warp.c#L661
I guess you could request the maximum be increased, so i did that: https://github.com/ValveSoftware/halflife/issues/1765
It's not very likely to happen though.
This post was made on a thread that has been deleted.
@Instant Mix
I really don't have time to work on yet another project
I can offer some assistance for debugging and perhaps some reverse engineering of Hammer, but beyond that i really don't have time.
I really don't have time to work on yet another project
I can offer some assistance for debugging and perhaps some reverse engineering of Hammer, but beyond that i really don't have time.
Thanks for the bump 
So as i said in the engine thread, i added fullbright support and fixed a depth test bug. I'll be refactoring some code first before releasing a new version.
So as i said in the engine thread, i added fullbright support and fixed a depth test bug. I'll be refactoring some code first before releasing a new version.
To nitpick a little, Valve doesn't have 3.5's source code. The SC team received the 3.4 source code.
Hammer's source code has comments from developers that encountered some weird looking code that a previous programmer put in there, it's also written in VS6 and uses MFC, so it doesn't even compile due to non-standard code that causes fgd parsing to fail silently when fixed.
If i were them i'd open source this old stuff so people can keep it going themselves, they could use the publicity.
Hammer's source code has comments from developers that encountered some weird looking code that a previous programmer put in there, it's also written in VS6 and uses MFC, so it doesn't even compile due to non-standard code that causes fgd parsing to fail silently when fixed.
If i were them i'd open source this old stuff so people can keep it going themselves, they could use the publicity.
This post was made on a thread that has been deleted.
Unrelated to the other comments, i added floating point export support to SC's Hammer as well; i made it an option in the Options menu. Seems like i was following the same train of thoughts.
Nice work on this editor, too bad you aren't working on it anymore though. Is there a list of GoldSource features that are still needed? I couldn't find anything on the site nor on Github.
Regarding SC's engine being old, it's the latest build from the 2013 update. I remember seeing some patchwork code translating OpenGL into D3D code, but it didn't appear to be functional and was removed.
Their engine is using SDL like the vanilla engine.
It's unfortunate that Valve doesn't reply to anybody's requests to open source or license the engine out, because that would also include Hammer. It'd be a lot easier to make a new editor if you had the original's source code, even if some of the code is hard to understand.
Nice work on this editor, too bad you aren't working on it anymore though. Is there a list of GoldSource features that are still needed? I couldn't find anything on the site nor on Github.
Regarding SC's engine being old, it's the latest build from the 2013 update. I remember seeing some patchwork code translating OpenGL into D3D code, but it didn't appear to be functional and was removed.
Their engine is using SDL like the vanilla engine.
It's unfortunate that Valve doesn't reply to anybody's requests to open source or license the engine out, because that would also include Hammer. It'd be a lot easier to make a new editor if you had the original's source code, even if some of the code is hard to understand.
Something like this:
int CGenericMonster:: TakeDamage( entvars_t *pevInflictor, entvars_t *pevAttacker, float flDamage, int bitsDamageType )
{
return 0;
}
If you want monster_generic to not respond to damage you can override the TakeDamage method and just provide an empty implementation. Return 0 so it knows that it didn't do any damage.
pm_shared.c is in the folder pm_shared in the game codebase.
Valve disabled the _special command, which was used for bunny hopping. You can't change that because it was blocked in the engine. You might be able to add a new command that isn't blocked though, assuming it doesn't need engine level support.
Valve disabled the _special command, which was used for bunny hopping. You can't change that because it was blocked in the engine. You might be able to add a new command that isn't blocked though, assuming it doesn't need engine level support.
Ok, it doesn't look like ambient_generic is doing this.
Are there any other entities in the map that are constantly playing sounds, like vehicles? If so, can you check their volume settings?
Are there any other entities in the map that are constantly playing sounds, like vehicles? If so, can you check their volume settings?
Are you using any ambient_generic entities in your map, and are their volumes set to a valid range? (1-10)
I experienced this in CSS circa september 2004. Half-Life 2 wasn't even released back then.
I remember seeing that in CSS back when it was first released as a beta. I think that was the engine wrapping your coordinates around when you went past the maximum map size, maybe it glitched the entities because it's only visual.
Sorry, didn't notice this thread before.
The GameUI007 interface is only retrieved from the GameUI library in "valve/cl_dlls/GameUI.ext".
This is the engine code for it (reverse engineered):
I've created a new issue requesting that GameUI be open sourced so it can be overridden by mod developers: https://github.com/ValveSoftware/halflife/issues/1763
I don't expect a response from anybody.
One thing you can try - and this is an epic hack - is to try to overwrite the vtable for the class so it redirects calls to your own implementation, and then pass them through to the original afterwards. To do this, you'll need to implement the interface in a class with only virtual function implementations and no member variables, then memcpy an instance of the class over the instance you get from GameUI.
I did this in my prototype engine to redirect filesystem calls:
https://github.com/SamVanheer/PrototypeEngine/blob/de14c82fff407bfa99e0153df8c4ec8710974df7/src/engine/CEngine.cpp#L107
https://github.com/SamVanheer/PrototypeEngine/blob/de14c82fff407bfa99e0153df8c4ec8710974df7/src/engine/CFileSystemWrapper.h
https://github.com/SamVanheer/PrototypeEngine/blob/de14c82fff407bfa99e0153df8c4ec8710974df7/src/engine/CFileSystemWrapper.cpp
You'll need to create one instance to memcpy the original vtable from first, then memcpy yours in. Make sure all calls end up in the original eventually, because if GameUI's version calls its own methods using the vtable entry, it'll call yours instead. If it expects its own method to do something, this could cause crashes.
Also make sure you reverse this when the client shuts down so GameUI doesn't crash trying to call the client after it has unloaded.
Pseudo code:
It's your best chance at gaining control over the GameUI implementation without support from Valve.
The GameUI007 interface is only retrieved from the GameUI library in "valve/cl_dlls/GameUI.ext".
This is the engine code for it (reverse engineered):
char szDllName[ 512 ];You cannot override GameUI because it will always load from valve/cl_dlls, and it will always load the interface from that library.
snprintf(szDllName, sizeof( szDllName ), "valve/cl_dlls/gameui.so");
COM_FixSlashes(szDllName);
FS_GetLocalCopy(szDllName);
this->m_hStaticGameUIModule = Sys_LoadModule(szDllName);
CreateInterfaceFn gameUIFactory = Sys_GetFactory(this->m_hStaticGameUIModule);
this->m_FactoryList[this->m_iNumFactories] = gameUIFactory;
if ( gameUIFactory )
{
staticGameUIFuncs = (IGameUI *)gameUIFactory ("GameUI007", nullptr);
staticGameConsole = (IGameConsole *)gameUIFactory ("GameConsole003", nullptr);
staticCareerUI = (ICareerUI *)gameUIFactory ("CareerUI001", nullptr);
++this->m_iNumFactories;
}
I've created a new issue requesting that GameUI be open sourced so it can be overridden by mod developers: https://github.com/ValveSoftware/halflife/issues/1763
I don't expect a response from anybody.
One thing you can try - and this is an epic hack - is to try to overwrite the vtable for the class so it redirects calls to your own implementation, and then pass them through to the original afterwards. To do this, you'll need to implement the interface in a class with only virtual function implementations and no member variables, then memcpy an instance of the class over the instance you get from GameUI.
I did this in my prototype engine to redirect filesystem calls:
https://github.com/SamVanheer/PrototypeEngine/blob/de14c82fff407bfa99e0153df8c4ec8710974df7/src/engine/CEngine.cpp#L107
https://github.com/SamVanheer/PrototypeEngine/blob/de14c82fff407bfa99e0153df8c4ec8710974df7/src/engine/CFileSystemWrapper.h
https://github.com/SamVanheer/PrototypeEngine/blob/de14c82fff407bfa99e0153df8c4ec8710974df7/src/engine/CFileSystemWrapper.cpp
You'll need to create one instance to memcpy the original vtable from first, then memcpy yours in. Make sure all calls end up in the original eventually, because if GameUI's version calls its own methods using the vtable entry, it'll call yours instead. If it expects its own method to do something, this could cause crashes.
Also make sure you reverse this when the client shuts down so GameUI doesn't crash trying to call the client after it has unloaded.
Pseudo code:
//vtable points to original methodsI can't guarantee that it'll work, it worked for me but my code completely overrides the original engine so there's no chance of code calling it beforehand.
CGameUIWrapper g_OriginalGameUI;
IGameUI* g_pGameUI = nullptr;
void RedirectGameUI()
{
g_pGameUI = (IGameUI *)gameUIFactory ("GameUI007", nullptr);
//sizeof( CGameUIWrapper ) is just the vtable pointer
memcpy( &g_OriginalGameUI, g_pGameUI, sizeof( g_OriginalGameUI ) );
CGameUIWrapper wrapper;
memcpy( g_pGameUI, &wrapper, sizeof( wrapper ) );
//g_pGameUI now calls CGameUIWrapper methods
}
void RestoreGameUI()
{
memcpy( g_pGameUI, &g_OriginalGameUI, sizeof( g_OriginalGameUI ) );
}
It's your best chance at gaining control over the GameUI implementation without support from Valve.
You'll have to add events for all 4 attachments to do that. You should be able to define multiple events for the same frame; the code is set up for it, at least.
Muzzleflash sprites are handled by the events we talked about before. Add debug output on the client side to show if it's triggering the events like it should, and whether it's getting the right options from them.
Can we make our own mod (including custom code) for this?
If you ever have problems loading a model that's located in a subdirectory of the models directory, and the model has a T file or sequences files (model01.mdl, etc), you'll have to recompile them with the files in that subdirectory.
The engine will try to load those files based on the path they had when they were compiled. It's pretty easy to fix in code, but you can't change the engine unfortunately :/
The engine will try to load those files based on the path they had when they were compiled. It's pretty easy to fix in code, but you can't change the engine unfortunately :/
Yeah, there are only up to 4 attachments supported. That's a hardcoded limit that cannot be changed without breaking compatibility with all mods, so it's stuck that way. The muzzleflashes are also hardcoded, like every other thing in existence.
I suppose you could add more attachments if you expand the studiomodel format with new data structures, but that's going to be a mess even in the best case.
I suppose you could add more attachments if you expand the studiomodel format with new data structures, but that's going to be a mess even in the best case.
The event number doesn't hold any meaning as to what the event will do. Just because the third number is a 0 doesn't mean that it will always affect attachment 0.
It's very important that you understand this because there are events that also have similar numbers and don't have anything to do with attachments.
Other than that what you said is correct
It's very important that you understand this because there are events that also have similar numbers and don't have anything to do with attachments.
Other than that what you said is correct
That's the option string i was talking about.
Like i said, the event number is just a number, you don't encode any special information in it. The game runs code for a particular event, but it doesn't change what it does based on the numbers in it. Valve may have decided on this numbering convention for their events, but it doesn't mean that all events will follow it.
If you need to show muzzle flashes, use the events for them. If you need a spark effect, use its event, and if you need to play a sound, use the event for it. Don't assume that all events that end in a particular number will do the same thing.
See this enum for which events are commonly used: https://github.com/SamVanheer/HLEnhanced/blob/master/game/shared/ScriptEvent.h#L21
If you need to show muzzle flashes, use the events for them. If you need a spark effect, use its event, and if you need to play a sound, use the event for it. Don't assume that all events that end in a particular number will do the same thing.
See this enum for which events are commonly used: https://github.com/SamVanheer/HLEnhanced/blob/master/game/shared/ScriptEvent.h#L21
The event number is just that, a number. You don't encode information in it.
Events have the event id and an options string. The attachment is decided by the event id.
See this for the code that takes the event and creates the muzzleflash: https://github.com/ValveSoftware/halflife/blob/master/cl_dll/entity.cpp#L348
Events have the event id and an options string. The attachment is decided by the event id.
See this for the code that takes the event and creates the muzzleflash: https://github.com/ValveSoftware/halflife/blob/master/cl_dll/entity.cpp#L348
Muzzle flashes are displayed using events 5001 (attachment 0), 5011 (attachment 1), 5021 (attachment 2), 5031 (attachment 3).
The muzzleflash to use is determined by the event options. 0 uses muzzleflash1.spr, 1 uses muzzleflash2.spr, 2 uses muzzleflash3.spr.
The option value is moduled twice: first by 10 and then by 3, in effect constraining the value to [ -2, 2 ]. It can be negative because performing modulo on negative values produces negative values. So make sure you never use negative values there.
The scale of the sprite is encoded in the option as well. The scale is value / 10 * 0.1, so a value of 10 uses muzzleflash1.spr:
10 % 10 = 0
0 % 3 = 0
scale = 10 / 10 = 1
A value of 11 would be scale 1, muzzleflash2.spr:
11 % 10 = 1
1 % 3 = 1
11 / 10 = 1
So as a rule of thumb:
Scale * 10 + muzzleflash
So if you want a scale of 3, muzzleflash2.spr:
3 * 10 + 1 = 31
31 % 10 = 1
1 % 3 = 1
31 / 10 = 3
Scale can only be a whole number because it's converted to an integer, see R_MuzzleFlash for the function that is used. You should also be able to find the code that handles the events and passes them into R_MuzzleFlash in entity.cpp, function HUD_StudioEvent.
The muzzleflash to use is determined by the event options. 0 uses muzzleflash1.spr, 1 uses muzzleflash2.spr, 2 uses muzzleflash3.spr.
The option value is moduled twice: first by 10 and then by 3, in effect constraining the value to [ -2, 2 ]. It can be negative because performing modulo on negative values produces negative values. So make sure you never use negative values there.
The scale of the sprite is encoded in the option as well. The scale is value / 10 * 0.1, so a value of 10 uses muzzleflash1.spr:
10 % 10 = 0
0 % 3 = 0
scale = 10 / 10 = 1
A value of 11 would be scale 1, muzzleflash2.spr:
11 % 10 = 1
1 % 3 = 1
11 / 10 = 1
So as a rule of thumb:
Scale * 10 + muzzleflash
So if you want a scale of 3, muzzleflash2.spr:
3 * 10 + 1 = 31
31 % 10 = 1
1 % 3 = 1
31 / 10 = 3
Scale can only be a whole number because it's converted to an integer, see R_MuzzleFlash for the function that is used. You should also be able to find the code that handles the events and passes them into R_MuzzleFlash in entity.cpp, function HUD_StudioEvent.