Forum posts

I think there are some hard-coded instances of monster_scientist in the code - maybe you need to add monster_cleansuit_scientist to those places too?

usual MDL compiler can't create MDL-files over 4Mb

Really? What part of it sets that limit?

Are there any errors in the console? My guess is HPB Bot waypoint files are incompatible with the bot you're using.

Haven't touched it in a while but I did start work on a mod for Zeno Clash.
I'm not much of a mapper but I did get a bit of a Roman town going.I intend to finish it one day.

How do they not navigate properly?

The Xbox engine uses mostly the same formats as the PC version but textures are different and as far as I know there is no tool to convert to a .xtf file.
Also, the gameplay is built into a monolithic binary with the engine I think so you probably can't change the code.

Had a quick look at studiomdl and maybe $sequencegroupsize set to some high number? Not sure.

The game_player_equip might be what you want - not sure if it's in Counter-Strike but it is in Half-Life.

BSP_tool: http://hpb-bot.bots-united.com/bsp_tool.html

There is an open source tool on botman's sites that generates waypoints for a given .bsp file - that may be of use.

I was calling UTIL_SetOrigin but that didn't help.
Playing around with it some more and it still seemed to happen... sometimes. I don't think anything is resetting stuff as it mostly works.
More experimenting required.

Looks like MarineBot is based on HPB Bot so I imagine you use similar console commands to place waypoints.
Binding those commands to keys will probably help.

Playing around in Sandpit:

Is agrobot open source? Bot #10 is for integrating into existing mods I thought so if you want to create you own bot you'll need to base it off something like HPB Bot (or Sandbot which I created and which is a bit more up-to-date and has everything in one package: http:/sandbot.bots-united.com).

Making waypoints is the same in most bot frameworks, though botman created an auto-waypointing tool which you could modify. I don't know if the results are perfect so some modification may be required but it probably takes a lot of the hard work out of it.

bits_MEMORY_PROVOKED is only used to determine whether to attack the player or not for the islave.
In CTalkMonster::IRelationship bits_MEMORY_PROVOKED is used to determine whether to attack the player or not.

If you want a friendly monster to attack you if attacked do something similar to CTalkMonster::IRelationship (and set bits_MEMORY_PROVOKED in TakeDamange too of course).

I'm getting a CBaseEntity using FindEntityForward then doing pForward->pev->origin.x += 1; or pForward->pev->angles.x += 1; or whatever. If I do pForward->pev->animtime += 1; right after that I see the entity move without any jitter but it looks like the updates get queued i.e. if I start updating a new field it changes the previous field first one more time.
If the entity inherits from CBaseAnimating it needs the pev->animtime hack but if I inherit from CBaseMonster then the calls to StudioFrameAdvance make it work.

I've got a class that inherits from CBaseAnimating and it seems like changes to pev->origin and pev->angles don't cause any changes to the rendered model (but traces do seem to respect the new position).
If I inherit from CBaseMonster the problem goes away - I've narrowed the cause down to CBaseAnimating :: StudioFrameAdvance (which gets called as part of CBaseMonster's main think method). Specifically, the line pev->animtime = gpGlobals->time; seems to cause the rendered model to update. Doing this manually seems to produce jittery results that reverse themselves after a second or so. pev->animtime += 1; seems to sync the changes without any jitter, although changing another attribute causes a delayed change of the previous attribute before updating the new attribute.

Anyway, I've wasted a lot of an afternoon trying to figure out what the problem was. If there's a better solution (one that doesn't cause a delayed change when changing a new attribute) I'd be interested. Any ideas why changing the animation time is needed too? Changing these attributes on sprite-based entities works fine I think.

Ah yep, didn't think about x/y-origin fields - thanks.

@potatis_invalid does your tool reverse the order of the pixel rows as well as setting the direction bit? I tried just setting the direction bit (which apparently makes it an invalid .tga according to the spec) and Windows shows it as upside down.

Oh nice potatis_invalid - I might just try flipping that bit and hope that that works.

Have you made any other modifications?
Does including other header files in the same directory work?

Ah, that'd be it - I use a value from CMD_ARGV which will get tidied up.
I guess I can cache the strings to stop running out of memory.

Maybe, though I didn't think all the different game icons were embedded.
I think it's Steam magic but I don't know.

I'm not setting it at all - something in CBaseEntity seems to do that and it looks okay when it is spawned, and I think I tried setting it with MAKE_STRING but that didn't work either.

I see that some entities have it set manually with MAKE_STRING though.

Alright thank you both - I was convinced it had to be the engine because I couldn't believe that both paint.net and Windows would both be wrong.
But I don't get how games through Steam don't have this problem.

Okay this is a bit of strange one. I'm programmatically creating monster_houndeye entities with CBaseEntity::Create
After they are created I ALERT their pev->classname values and can see monster_houndeye
In the houndeye's SonicAttack method, all entities in a sphere around the houndeye are looped over. In this loop the pev->classname of neighbouring houndeyes is garbage so the houndeyes end up killing each other and themselves.

Somewhere the pev->classname is getting messed up. Any ideas?
If the houndeye is just in the map it doesn't seem to have this problem.

More work on the next version of Sandpit:In going through and finding sprites to put on it I found at least two sprites that shipped with Half-Life that had visible green backgrounds (I guess they weren't compiled right or something).

You can grab it out of the .zip at (https://www.moddb.com/mods/sandpit/downloads/sandpit-v401).
I've since tried playing around with it locally but still get the same result.

I dug through my client.dll and I suspect that steam_api.dll may be the culprit. It's there but possibly DllMain returns false for pirated copies which causes LoadLibrary to fail.

I think the .ico is only used for desktop shortcuts.

Re the Valve Developer wiki - I think I updated that page (probably a decade or so ago) and it worked back then but Steam has received more than a few updates since then.
I've been trying to copy what Half-Life itself has but I suspect games/mods have an icon on the Steam backend that gets used for the Steam My Games list.
I tried updating paint.net but had no luck, and as far as I can see my .tga has the same settings as Half-Life's icons, and the Windows preview shows the correct orientation.

Just checked and it looks like static linking the Visual C++ runtime already happens by default for client.dll (or at least it does in my mod that I updated from the Visual C++ 6 project files).

Calling gEngfuncs.pTriAPI->FogParams (with the first parameter between 0.0 and 1.0 from memory) works for me.

I thought a big part of Half-Life was the modding - Natural Selection 2 tried to follow that path with their SDK but I don't know, I guess the modding scene has changed since 1998.

Which bot are you using? HPB Bot has some console commands like waypoint add and waypoint save

yep i know the fog is broken, thats why im finding someone payd to fix it along other issues

Fog is easy to fix - if you look at the latest SDK code there's an extra fog function in the TriangleAPI that needs to be called.

The can't find monster looks like a missing entity: https://github.com/ValveSoftware/halflife/blob/master/dlls/scripted.cpp#L486
You'll have to do some searching to figure out what the other one is.

Still pretty excited for Black Mesa which shouldn't be far away now hopefully.

Other than that not much - ACE Team (the makers of Zeno Clash) say they'll probably be announcing three projects this year so I'm interested to see what they will be.

Probably wouldn't be too hard to fix whatever is causing the issues - looks like missing animations or something like that.

Not sure what's outputting them but maybe they're unsuppressible errors? Maybe the engine will always warn you regardless of what developer is set to.

It's a shame that dependencies are so hard.

I guess statically linking to the Visual C++ runtime is okay solution for most use cases? I assume that's what this error is most of the time.

What is the message?

All the TE_ effects are hard-coded in the engine.

Ah thanks - I thought about Cmd_Argc and Cmd_Argv after I posted but I wasn't sure if they'd have the right data in them (I guess they have to).
And yeah I was thinking store the original and only pass off to it if some condition was met, otherwise just print an error or something.

const.h says TE_TELEPORT only takes three coord arguments - maybe use another SVC message type that has a width parameter.

cl_enginefunc_t provides GetFirstCmdFunctionHandle, GetNextCmdFunctionHandle and GetCmdFunctionName for playing with the engine's list of console commands, though it looks like the definitions aren't quite right - they should probably be this (some documentation from prsearle):

typedef void (*xcommand_t) (void);    // Pointer to console command handler

typedef struct cmd_function_s {
    struct cmd_function_s *next;    // Next console command structure
    const char *name;                // Console command as typed at console (e.g. "stopsound")
    xcommand_t  function;            // Pointer to function called when command is entered
    const char *description;        // Command description ???
    qboolean    pure;                // ???
} cmd_function_t;

...

typedef cmd_function_t*                (*pfnEngSrc_GetFirstCmdFunctionHandle_t)();
typedef cmd_function_t*                (*pfnEngSrc_GetNextCmdFunctionHandle_t)(cmd_function_t* cmdhandle);
typedef const char *                (*pfnEngSrc_GetCmdFunctionName_t)(cmd_function_t* cmdhandle);

So it looks like it's possible to modify or remove entries in the engine's command list (though maybe we're not meant to given that the definitions in the SDK aren't usable). My question is how modifying the function attribute of cmd_function_t would work - it doesn't seem to take any arguments and from a quick look at Quake's code it looks like the passed arguments are stored in a global char* pointer which the client code probably doesn't have access to. Seems like there isn't a way to usefully override a console command based on the arguments that get passed?

edit: is multi-line code formatting possible?

Seems like an okay place for it but if it's not working probably add some logging to see what's going on.

Ah yep, all the things in efx_api_t that take a colour number too, and all the Quake-style particles I guess.
Thanks.

So it looks like blood colours actually come from palette.lmp and BLOOD_COLOR_RED/BLOOD_COLOR_YELLOW/BLOOD_COLOR_GREEN are palette indices?
Has anyone played around with palette.lmp? Is it used for anything more than blood colour?

By the time I'd got most of the way through the article I'd completely forgotten about vis.
Anyway, I remember reading https://github.com/x6herbius/afterburner-engine/wiki/Nightfire-BSP-Format which seems to be a moderately accessible document which describes the vis lump among other things (it's for 007 Nightfire but it's close enough probably).

As for the bots, I'd go with a personality approach (something like int m_iPersonality, or even better, an enum) and each bot gets a random personality at spawn. And then depending on their personality, they can fire slower, faster, and even prefer weapons.

Agree.