Admer456 said:BTW you should've created a new thread instead of bumping this one.It's just that my question was semi-related to this post, and I found it dumb creating a new one this short.
Forum posts
I'm so sorry for bumping the thread with this unrelated question: does it really matter changing 'unseen' textures with trigger/sky despite these faces not drawing outside the playable area? That is unless you make a walkable/accessible area where the face(s) would now draw but you'd like it not to be.
The Mad Carrot said:You can include definitions from one fgd file into another by adding the line ''@include "filename.fgd" (no quotes) as is explained here: https://developer.valvesoftware.com/wiki/FGD but I'm certain this applies to goldsource fgd files as well though I'm not 100% sure.That's for Source games only. This is why mod-based GoldSrc FGDs are simple forks of the original Half-Life file, rather than just have a base file of entities shared between said mods and then dedicated ones to complete the list of entities.
LOZ98 said:I figured it out (I guess) I modified the default Half-Life fgd by adding my monster to it instead of adding a separate fgd file. works fine now, It's probably not a perfect solution but it'll do for now.Sounds like a specified base wasn't defined in the FGD - just one of them being incomplete or if failing to be read will not show the entity in the list. In your case, it was either "Monster" or "Sequence", or even both. Quick example of how it should be:
//Note how I only added the bases required for your entity, as well as the bases required by said bases themselves. In short, a base that is then used by an entity or another base must've been defined previously.
// BaseClasses
//
@BaseClass = Angles
[
angles(string) : "Pitch Yaw Roll (Y Z X)" : "0 0 0"
]
@BaseClass = RenderFxChoices
[
renderfx(choices) : "Render FX" : 0 =
[
0 : "Normal"
1 : "Slow Pulse"
2 : "Fast Pulse"
3 : "Slow Wide Pulse"
4 : "Fast Wide Pulse"
9 : "Slow Strobe"
10 : "Fast Strobe"
11 : "Faster Strobe"
12 : "Slow Flicker"
13 : "Fast Flicker"
5 : "Slow Fade Away"
6 : "Fast Fade Away"
7 : "Slow Become Solid"
8 : "Fast Become Solid"
14 : "Constant Glow"
15 : "Distort"
16 : "Hologram (Distort + fade)"
]
]
@BaseClass base(RenderFxChoices) = RenderFields
[
rendermode(choices) : "Render Mode" : 0 =
[
0 : "Normal"
1 : "Color"
2 : "Texture"
3 : "Glow"
4 : "Solid"
5 : "Additive"
]
renderamt(integer) : "FX Amount (1 - 255)"
rendercolor(color255) : "FX Color (R G B)" : "0 0 0"
]
@BaseClass = Target
[
target(target_destination) : "Target"
]
@BaseClass = Targetname
[
targetname(target_source) : "Name"
]
@BaseClass base(Target, Targetname, RenderFields, Angles) color(0 200 200) = Monster
[
TriggerTarget(String) : "TriggerTarget"
TriggerCondition(Choices) : "Trigger Condition" : 0 =
[
0 : "No Trigger"
1 : "See Player, Mad at Player"
2 : "Take Damage"
3 : "50% Health Remaining"
4 : "Death"
7 : "Hear World"
8 : "Hear Player"
9 : "Hear Combat"
10 : "See Player Unconditional"
11 : "See Player, Not In Combat"
]
spawnflags(Flags) =
[
1 : "WaitTillSeen" : 0
2 : "Gag" : 0
4 : "MonsterClip" : 0
16 : "Prisoner" : 0
128 : "WaitForScript" : 0
256 : "Pre-Disaster" : 0
512 : "Fade Corpse" : 0
]
]
//
// Entities
//
@PointClass base(Monster, Sequence) size(-16 -16 0, 16 16 72) studio("models/npcs/pit_drone.mdl") = monster_pitdrone : "monster_pitdrone" []
Posted 5 years ago2019-09-29 13:02:52 UTC
in FGD editing - 'string' or 'integer' for numerical values? Post #343181
in FGD editing - 'string' or 'integer' for numerical values? Post #343181
Admer456 said:Quite simple:Thank you!
If it's a whole number, then integer. Candidates: 0, 1, 2, 3 etc.
If it's a real number (such as a delay in seconds), then string. Candidates: 0.1, 0.2, 2.0, 0.2948 etc.
String is rather used for alphanumerical values, but since there's apparently no floating point type in FGDs, we improvise.
Admer456 said:If you don't provide a value for a keyvalue, then that keyvalue won't be written into the .map file.One thing that I noticed (and was going to include it in the thread but left that one out) is that, when it's an integer and a value isn't entered into the FGD, it will be "0" in Hammer (rather than an empty field, even if it's still defaulted to "0" in-game).
As such, it's gonna default to 0 in-game.
Given your information, I guess I shouldn't be messing with properties in case they're intended to support decimals, but the "framerate" keyvalue sure made me wonder as to why one is a String (env_sprite) and the other is an Integer (cycler_sprite).
Posted 5 years ago2019-09-28 22:06:13 UTC
in FGD editing - 'string' or 'integer' for numerical values? Post #343176
in FGD editing - 'string' or 'integer' for numerical values? Post #343176
Ever since learning how certain FGD elements work, I've been working on my own version of it based on the original/full Half-Life file, last updated for Hammer 3.5
Thus, I've seen and learnt a lot pretty quickly, but there's one thing I can't really figure out: should numerical keyvalues be Strings or Integers, especially the ones defaulted to "0"?
The confusion mainly comes from two (identical?) keyvalues with different properties; one is a "_minlight(string)" and the other is a "_minlight(integer)", the latter displaying "_minlight" as the text to display in Hammer and "0" as the value, even if not originally specified (the former doesn't have a value, but I guess it's still defaulted to "0"). Then, there are others like "framerate" and "delay".
Thus, I've seen and learnt a lot pretty quickly, but there's one thing I can't really figure out: should numerical keyvalues be Strings or Integers, especially the ones defaulted to "0"?
The confusion mainly comes from two (identical?) keyvalues with different properties; one is a "_minlight(string)" and the other is a "_minlight(integer)", the latter displaying "_minlight" as the text to display in Hammer and "0" as the value, even if not originally specified (the former doesn't have a value, but I guess it's still defaulted to "0"). Then, there are others like "framerate" and "delay".
Posted 5 years ago2019-09-02 23:00:47 UTC
in Previewing models in the official (obsolete) Hammer? Post #343095
in Previewing models in the official (obsolete) Hammer? Post #343095
Dr. Orange said:It is made by Valve, but it isn't officially supported as it was only released as a beta. I believe it was only ever released on the old VERC website, which has been defunct for years, which is why it can't be found "officially" anywhere anymore.Thanks a bunch!
- Reference for future readers:
- Latest proper archive of Hammer 3.5 at the now-dead Valve ERC website: http://web.archive.org/web/20080420133241/http://collective.valve-erc.com/index.php?go=hammer_beta
- TWHL reupload: https://twhl.info/wiki/page/VERC%3A_Hammer_Beta
Posted 5 years ago2019-09-02 18:54:13 UTC
in Previewing models in the official (obsolete) Hammer? Post #343092
in Previewing models in the official (obsolete) Hammer? Post #343092
Admer456 said:In the FGD entity definition, add studio().Alright, thank you.
@PointClass base(Target) studio() = env_something
Not sure if you gotta make the following change as well, but:
model(string) : "Model" should he changed to:
model(studio) : "Model"
Note: this is just an example, there is no env_something.
Hammer 3.4 doesn't support models, if I recall correctly. 3.5.2 beta does, however.
I also took a look at an exemplary FGD and noticed that some of them also have 'Sequence' for studios with models - are those for models with animations?
Bruce said:VHE 3.5 (the last official by Valve) supports it, and needs something in the .fgd like Admer mentionedI'm no expert, but it makes me wonder if 3.5 is actually a Valve product as it can't be found anywhere 'officially'.
The Mad Carrot said:Right.Is there something like an official hosting for Hammer 3.5?
In case you don't have Hammer 3.5 and the fgd file, here you go:
Hammer 3.5 (executable only)
Hammer 3.5 fgd file
Counter-Strike expert fgd file for Hammer 3.5
Posted 5 years ago2019-08-31 21:34:41 UTC
in Previewing models in the official (obsolete) Hammer? Post #343088
in Previewing models in the official (obsolete) Hammer? Post #343088
I've never been a fan of community Hammers such as Sledge or J.A.C.K., so I'm using Half-Life SDK's one with a tweaked halflife-cs.fgd that I made. However, one of the things I never found out is the ability to enable model previews on entities such as cycler_sprite, and I don't know if it's related to the FGD or Hammer itself. If the former, what should be done? The only workaround for me right now is play with the entity until achieving the desired position in the map, which is somewhat time-consuming.
Posted 5 years ago2018-12-12 18:46:38 UTC
in Is it possible to join a brush entity onto another? Post #341442
in Is it possible to join a brush entity onto another? Post #341442
Jessie said:As Urby said, it's in the mod Spirit of Half-Life. In that it's just another attribute on a given entity. It's a fairly basic function, and doesn't work particularly well with anything more than the most simple movement.Never heard of that mod so by "Spirit of Half-Life" I initially understood it as a very old or obsolete function, or something like that. Thanks for clearing it out!
Bruce said:You could do it by having a second train with identical movement and you would use either an animated texture with additive rendering or the X Y Z rotation option. Another hack would be to add a custom keyvalue "model" with "models/heli.mdl" or soYet another great idea I didn't think of (the 'secondary brush entity' trick). Thanks a lot!
Posted 5 years ago2018-12-11 22:09:03 UTC
in Is it possible to join a brush entity onto another? Post #341430
in Is it possible to join a brush entity onto another? Post #341430
UrbaNebula said:I'm afraid that this would not be possible with the standard Goldsource engine. Spirit of Half-Life allows you to set a "Moves with" value which is a very primitive form of parenting. The only example I have seen of a helicopter in Goldsource made use of an animated rotor texture.Perhaps I'll be trying to use an animated texture but it already sounds like a lot of work besides making textures with transparency. But still, where can I find the "moves with" value?
Posted 5 years ago2018-12-11 21:16:33 UTC
in Is it possible to join a brush entity onto another? Post #341428
in Is it possible to join a brush entity onto another? Post #341428
I would like to make a map with, let's say, func_tracktrain helicopters with spinning rotor blades. In the Source engine, this procedure is known as "parenting" (attaching), but since the GoldSrc one doesn't support it, I'd like to know if there's anything that comes close to the feature.
The helicopter won't be an idling one so it's not just a func_rotating entity that has to be placed above the base brushwork. I remember seeing a ZM video long ago where players were on a moving one, but I can't recall seeing rotor blades. I also hope it wasn't Counter-Strike: Source (which I'm certain).
The helicopter won't be an idling one so it's not just a func_rotating entity that has to be placed above the base brushwork. I remember seeing a ZM video long ago where players were on a moving one, but I can't recall seeing rotor blades. I also hope it wasn't Counter-Strike: Source (which I'm certain).
potatis_invalid said:A laser with multiple same-name targets is a common method: https://twhl.info/wiki/page/Tutorial%3A_Random_entity_triggeringThanks a lot! Will see if I can replicate it all properly.
In Source, there's an entity named "logic_case" which can be used to fire random 'outputs' with its "PickRandom" input. I'm wondering if the GoldSrc engine has such an entity or a workaround to produce similar effects. Thank you!
torekk said:Use another entity called multi_manager with it's "multithreaded" flag ticked and which basically calls itself, two env_renders, one which "shows" the entity, and one that "hides" it. E.g. if you have want to toggle an env_sprite, set the env_sprite's rendermode to "Glow" and the amount to e.g. "255", then for the env_render that shows it copy those values and for the one that hides it change the amount to "0".I kinda figured it out already that I need two different entities, one to Show and the other to Hide, but thanks again for the clarification and the env_render entity.
. . .
One thing to let you know about: a multi_manager can't be "activated" again until all its targets have been fired. Ticking the "multithreaded" flag will make the entity retriggerable any time, but it depends on the function/complexity of that entity that may or Not crash your map. I don't think the flag should be ticked unless really necessary.
torekk said:env_renderThank you for answering, but can it do both Show and Hide? My intention is to continuously make an entity flicker, and I'd like to know if that's possible and a brief explanation on how to do it, because I never heard of / worked with that entity.
Is there a way to do such thing in GoldSrc?
In Source, for example, there are "Outputs" and "Inputs". To certain entities, such as prop_dynamic and func_brush, you can set "Disable" to 'hide', and "Enable" to 'show', and even do so all the times you want.
In GoldSrc, the only "similar" (if at all) thing I ever did was making use of a func_breakable entity that would reappear on round restart.
In Source, for example, there are "Outputs" and "Inputs". To certain entities, such as prop_dynamic and func_brush, you can set "Disable" to 'hide', and "Enable" to 'show', and even do so all the times you want.
In GoldSrc, the only "similar" (if at all) thing I ever did was making use of a func_breakable entity that would reappear on round restart.
Posted 6 years ago2018-07-21 16:42:54 UTC
in Decreasing a texture's scale drastically increases the map's filesize and compiling time. Post #340221
in Decreasing a texture's scale drastically increases the map's filesize and compiling time. Post #340221
Bruce said:Texture scale and lightmap scale are locked together permanently in HL1. It is impossible to change. Your solution is to combine small and big scale textures for less important and more noticeable surfaces accordingly. Although scale of 1 is fine for most occasions if the texture is well made. Always make sure to export textures from Photoshop in 8-bit .bmp rather than .jpg to avoid quality loss.Thanks for the info - I was going to ask about other Hammer applications such as J.A.C.K., because I saw a few samples of it some time ago and it looked like it had some advanced features, and wanted to know whether it supports the modification of lightmap scales.
I use GIMP as the image-manipulating software, and when it comes to creating textures for the GoldSrc engine, I export textures to a 24-bit .BMP image, R8 G8 B8 (the other options are 16 and 32 bits).
The thing is, to use a scale of "1" in Hammer, the custom texture should be decreased from 128x128 to 32x32, which already sounds bizarre. I still did it before posting this thread, though, and it's actually where I noticed the textures being blurry/pixelated, very bad-looking. Currently doing balance by downscaling them to 64x64, and then downscaling to ".5" in Hammer to achieve the smallest-possible filesize while keeping the desired texture quality.
Posted 6 years ago2018-07-19 19:31:54 UTC
in Decreasing a texture's scale drastically increases the map's filesize and compiling time. Post #340201
in Decreasing a texture's scale drastically increases the map's filesize and compiling time. Post #340201
Admer456 said:You could technically use a very low-res texture and use an original-res detail texture. It's a trick used to achieve lower lightmap counts as well as less wpolys, but it may decrease the framerate, only slightly.Not sure what you refer to with "detail". All I want is downscale a texture that looks large at 100%, but doing so will result in a bigger filesize. The texture is a 128x128 file, and downscaling the file (not the texture in Hammer) to 32x32, which is the way it should actually look like, will make it look blurry/pixelated because it's such a small resolution. The "best" resolution in this case would be 64x64, which still forces me to also downscale the textures in Hammer to ".5", continuing to generate bigger filesizes but half the previous ones.
Posted 6 years ago2018-07-19 19:31:53 UTC
in Decreasing a texture's scale drastically increases the map's filesize and compiling time. Post #340200
in Decreasing a texture's scale drastically increases the map's filesize and compiling time. Post #340200
Admer456 said:You could technically use a very low-res texture and use an original-res detail texture. It's a trick used to achieve lower lightmap counts as well as less wpolys, but it may decrease the framerate, only slightly.Not sure what you refer to with "detail". All I want is downscale a texture that looks large at 100%, but doing so will result in a bigger filesize. The texture is a 128x128 file, and downscaling the file (not the texture in Hammer) to 32x32, which is the way it should actually look like, will make it look blurry/pixelated because it's such a small resolution. The "best" resolution in this case would be 64x64, which still forces me to also downscale the textures in Hammer to ".5", continuing to generate bigger filesizes but half the previous ones.
Posted 6 years ago2018-07-19 16:05:47 UTC
in Decreasing a texture's scale drastically increases the map's filesize and compiling time. Post #340194
in Decreasing a texture's scale drastically increases the map's filesize and compiling time. Post #340194
Experimenting with a test map of mine, it turns out that the lightmap scale still won't change. I created 4 large blocks that will shadow the next. They go from scale "1" to ".13" and said shadows are less diffuse. Not sure what exactly the command is for, but it definitely decreases the compiling time.
Posted 6 years ago2018-07-19 12:59:00 UTC
in Decreasing a texture's scale drastically increases the map's filesize and compiling time. Post #340192
in Decreasing a texture's scale drastically increases the map's filesize and compiling time. Post #340192
Windawz said:-notexscale 1I simply used "-notexscale" (without the Value because it's not necessary, according to the parameters), and although it decreases the compiling time, the filesize remains the same (oversized).
Posted 6 years ago2018-07-19 10:30:58 UTC
in Decreasing a texture's scale drastically increases the map's filesize and compiling time. Post #340187
in Decreasing a texture's scale drastically increases the map's filesize and compiling time. Post #340187
Windawz said:If you add the -notexscale 1 parameter to VRAD in your compile settings, texture scale will no longer affect lightmap resolution. This option applies to all brush faces in your map. This also means that the lightmap scale on faces with upscaled textures will be reset to normal as well.I shouldn't be asking this because I use Vluzacn's ZHLT modification, but still: is that a command only for non-Valve compilers?
Thanks a bunch for the info! Will check it out and let you know.
Posted 6 years ago2018-07-18 16:55:12 UTC
in Decreasing a texture's scale drastically increases the map's filesize and compiling time. Post #340181
in Decreasing a texture's scale drastically increases the map's filesize and compiling time. Post #340181
Solokiller said:That has to do with lightmap scale, which is tied to texture scale in GoldSource. You'll have to scale the actual textures to avoid that.The thing is, the textures I'm using/downscaling are actually custom textures. This is what's going on:
The texture(s) at 100% are just too large, and to make them look properly I have to downscale them to ".25", which makes my small map be almost 3MB of size, as well as it taking 13 minutes to complete compiling. I then edited the textures, downscaling them half their size (but I still need to, additionally, downscale their appearance in Hammer, although this time to just ".5") because I can't make them even smaller as they'll appear blurry due to small texture resolution. Although it significantly decreased the final filesize of the map and the compiling time, it's still not a good solution as I need to embed the custom .WAD file, which weighs 330 kB = 1MB of a map.
Posted 6 years ago2018-07-18 15:46:11 UTC
in Decreasing a texture's scale drastically increases the map's filesize and compiling time. Post #340179
in Decreasing a texture's scale drastically increases the map's filesize and compiling time. Post #340179
I'm currently working on a map which will contain custom textures. These textures actually appear bigger than I expected, so I halved their scaling. However, I noticed that it also doubles the map's compiling time and its final size is thrice as big.
Rolling every texture to "Scale 1" fixes the problem. In Source, rescaling textures seems not to affect anything, while in GoldSrc it does. Is there any solution to this?
Thanks in advance!
Rolling every texture to "Scale 1" fixes the problem. In Source, rescaling textures seems not to affect anything, while in GoldSrc it does. Is there any solution to this?
Thanks in advance!
Admer456 said:linkThanks a bunch!
There's some info in there. I hope it helps.
Hello. I've been looking for an article that specifies the dimensions used by the GoldSrc engine, or at least for the classic Counter-Strike in case they vary. An article like this one for Source, but for GoldSrc. Any suggestions?
Thanks in advance!
Thanks in advance!
Posted 6 years ago2018-06-27 14:54:54 UTC
in Skybox solids behaving weird when compiled with default compilers? Post #340021
in Skybox solids behaving weird when compiled with default compilers? Post #340021
Solokiller said:The skybox does not have any clipnodes generated for it when using old compilers. Newer ones will generate them by default, but that can be disabled with -noskyclip. This thread has a bit more information: https://forums.svencoop.com/showthread.php/38059-ARCHIVE-Custom-ZHLT-by-vluzacn?p=478658&viewfull=1#post478658Thanks for the info!
Posted 6 years ago2018-06-27 13:22:25 UTC
in Skybox solids behaving weird when compiled with default compilers? Post #340019
in Skybox solids behaving weird when compiled with default compilers? Post #340019
So there was a thing I noticed about a month ago, and it's that you can kind of leave the playable area of the map by just bumping into the skybox brushes/solids. I initially thought it was a bug I probably caused at some point, but I later compared it to another map I made months ago and it was all fine. I then switched to Vluzacn's HL Compilers (I actually have been using them since my first CS map, but only because I needed to embed a custom .WAD file), re-compiled the map and it got fixed. I never bothered exploring it again because for now VZHLT does the job all fine (even if the compiling process takes a bit longer to complete).
Now, using a test map, I compiled the same version using different compilers: the ones that come up with Half-Life SDK (on Steam) and Vluzacn's compilers, and the skybox solids are indeed semi-solid. You can go through them and even fall into the underground deeper than intended, but there's a point where you just get stuck.
If either the .RMF or .BSP is needed, here's the link to a folder containing both: https://drive.google.com/open?id=1eqa95JeciYwklcXTOLxavBzjubZMDWy9
The map was compiled using the "Expert" mode, although no additional parameters were used.
As a sidenote, this would perhaps explain that one collision bug on cs_assault where you can get inside a traincar.
Now, using a test map, I compiled the same version using different compilers: the ones that come up with Half-Life SDK (on Steam) and Vluzacn's compilers, and the skybox solids are indeed semi-solid. You can go through them and even fall into the underground deeper than intended, but there's a point where you just get stuck.
If either the .RMF or .BSP is needed, here's the link to a folder containing both: https://drive.google.com/open?id=1eqa95JeciYwklcXTOLxavBzjubZMDWy9
The map was compiled using the "Expert" mode, although no additional parameters were used.
As a sidenote, this would perhaps explain that one collision bug on cs_assault where you can get inside a traincar.
MOCOLONI said:Yep, rolling back to the entities I initially used seems to have fixed the whole issue. multi_managers actually restart the cycle just fine, and there are no side-effects unlike when using regular Train entities (such as dying during a Train's trajectory will immediately teleport that Train to its destination on the next round, without firing targets specified on its final path_track).MistaX88 said:Now, it's very possible that you'll have to modify how the whole loop works because of how the trains are behaving. It won't be because the old loop wasn't working; it will be because func_trains are janky in CS and for some reason will only get triggered by a perfectly working loop on it's first cycle.Would rolling back to func_tracktrains help at something, if at all? I know Trains and Tracktrains are different entities but I just need either as a counterpart to Source's func_movelinear entity.
Not sure if that's what you meant by "Trains have a weird function in CS" as you didn't state whether it was for func_trains or func_tracktrains.
Anyway, thank you all for the info provided!
MistaX88 said:Now, it's very possible that you'll have to modify how the whole loop works because of how the trains are behaving. It won't be because the old loop wasn't working; it will be because func_trains are janky in CS and for some reason will only get triggered by a perfectly working loop on it's first cycle.Would rolling back to func_tracktrains help at something, if at all? I know Trains and Tracktrains are different entities but I just need either as a counterpart to Source's func_movelinear entity.
It's not a func_door right now and it's never going to be due to it not going back to its spot instantly (it's just "closes/opens" at the round start, which is something I want to prevent players from seeing).
MOCOLONI said:Unless I'm doing something wrong, it doesn't seem to fix the problem; it still acts like it's yet another multi_manager, taking 16 seconds instead of 4 to re-activate the first one.Jessie said:What about having the trains trigger trigger_relays with a delay? I can’t test this at the moment, just throwing it out there.I yet have to test that.
MistaX88 said:On that example map, make 4 func breakables, name them train1, train2, train3, and train4. Set them all to "trigger only".I know they'll keep (randomly) breaking the already-broken breakable brushes; that's why I told Jessie in an above post to die at some point after activating the loop, so that all the Trains (except the one moving between rounds) would get on the ground, ready to be re-triggered again and see how wrong the looping goes.
I just did this, and what it showed that was the multi_managers keep looping. If a func_breakable is triggered again even after it already broke, it will make a sound and spawn gibs (and explode if you have that set) again. So it will go off every single time a multi_manager fires it, even if it is now a bunch of empty space.
Jessie said:What about having the trains trigger trigger_relays with a delay? I can’t test this at the moment, just throwing it out there.I yet have to test that. On a QuakeWiki article it's being stated that this entity is partially useless as entities can loop each other, but I guess a trigger_relay won't hurt as looping multi_managers using themselves is actually a problem for me right now.
Jessie said:Firstly, just for clarification (I don't know if it actually affects anything, but pays to know), which game is this supposed to be for? Half-Life, HL Deathmatch, Counter-Strike, etc.?The map is for Counter-Strike.
Secondly, what is the loop supposed to do? Maybe you cut it out of the file you uploaded, but retriggering those trains doesn't do anything.
The test map wasn't actually made for TWHL and was only a toned-down version of the original map, which has 60 Trains and the same way of looping the 4 multi_targets. Nothing has been cut out of the .rmf I uploaded.
As in the main/original map, the Trains are supposed to rise up and break the surface/ceiling above them (I actually think these were unnecessary for the testing as I only needed to see the Trains' progress). Since the main map has 60 Trains, with 4 minutes for the multi_managers to elevate them all, I assume the round will always restart before that happens, so all the Trains will get back to ground on new rounds. However, when the last multi_manager reaches the final target and re-activates the very first multi_manager as supposed, it takes 4 more minutes to actually do so, pretty much like in the .rmf above (although it only takes 16 seconds in there, pretty much as the regular process' timelapse).
Like I said, respawning before the last Train reaches its destination and trying to re-activate the first multi_manager with the button seems to do the last multi_manager's job just fine.
Jessie said:The quick test map I threw together (now that I'm not in bed going to sleep) doesn't seem to have any problem with looping multi_managers. Nothing special going on.Here it is: https://drive.google.com/open?id=1_q9jpe9medPFf6roeFQpwzWYd181Lfgs
If you're still having trouble, maybe post your test .rmf.
In the .rmf you'll find a button, 4 func_trains & 2 path_tracks for each, as well as 4 related multi_managers. Each will first activate their Train, followed by the activation of the next multi_manager and etc. The last multi_manager does it all but is supposed to re-activate the first one, which it does but 4x times slower than intended.
There's also a trigger_once brush behind the info_player_start entity (it was moved Behind for testing purposes, but it's still functional [although it no longer "auto" activated upon spawning]).
When in-game, press the red button to start the cycle. Because the Trains only go up, consider dying at some point after the activation and before the fourth Train reaches its end-of-path, so all Trains will once again be on ground and you'll be able to see it takes 16 seconds to re-activate the first multi_manager instead of just 4.
However, if you press the button after respawning and before the fourth Train completes its trajectory, the first multi_manager will be re-activated in 4 seconds, as supposed.
MistaX88 said:Ah, I misunderstood the details and didn't see your 2nd post.Thank you for that tutorial, but I find it kinda complex to understand. I currently think I found a "fix" to the problem, especially for the needs in my map. If it all ends up working fine without side effects, I'll post the solution here, or at least how it works on my map since it's not a regular one.
I was always under the impression that a multi_manager loop couldn't target itself. There is an old tutorial about multi_manager looping. https://twhl.info/wiki/page/Tutorial:_Multi_manager_Looping_Made_Easy
MistaX88 said:Train entities are weird in counter-strike. Something about the way they reset isn't quite right and I can't figure it out.It's not the Train/Tracktrain entities, it's the multi_managers that don't "restart" properly.
Windawz said:Tracktrains may be the problem. I've already seen one person complaining that a path_track wouldn't fire its target when passed by a tracktrain. Try replacing tracktrains with usual trains, as well as path_tracks with path_corners.I replaced Tracktrains with Trains recently, as Tracktrains seemed to be an entity for even more features that I didn't actually need; all I wanted was a moving platform that would instantly go to its initial spot after a round restart, so a func_door wasn't suitable.
Tracktrains can still fire targets by addint the target to a path_track's "Fire on dead end"; a regular Train will do the thing with "Fire On Pass".
These are no longer a problem. What I'm focusing on now is trying to make a multi_manager not get glitched on an autoloop situation.
Jessie said:Well, a couple of things. Firstly, if the setup isn't too complex, consider compiling the four multi_managers into one ...Actually, there's a reason these managers aren't just one: I'm working on a map that has 60 func_tracktrains, 15 in each multi_manager and a 16th target that will fire the next multi_manager. The issue was found in that same map, so I recently made a small "test" map with only one target and one multi_manager ('the next') to see if the problem persists, which does. In the test map it's just 4 tracktrains, but the problem is still in there, as if the managers had some kind of a "Delay before resetting" (but they still use the time it takes for the whole process to end).
Right now, I'm using a trigger_once to start the process. I then used a trigger_multiple with a delay of what it takes to somehow try reactivating the first multi_manager, but it still won't work.
I'll try using a button to manually try reactivating it, and will edit this post with the result.
EDIT: Yep, there's definitely something preventing any multi_manager to be retriggered after the cycle has been completed. You can however re-trigger the first (or any multi_target in the cycle) before it completes; in my case it was the first one, but it only activated the tracktrain right after the cycle completed, like it's supposed to be the regular way.
Hi. I'm trying to create a loop/cycle between all the multi_managers I have in a map. Each one of them targets a func_tracktrain that takes 2.5 seconds to reach the end of its path, with an additional 1,5 seconds of wait until the next func_tracktrain gets targeted, making it a value of "4" seconds as the 'second target' in the multi_manager. The last target on each will fire the next one, with the last multi_manager firing the first one. However, instead of resetting the whole process, it seems that right after it apparently reaches the last target and fires the first multi_manager, it would instead only take the overall time of the whole process without doing anything, before actually getting reset.
In case the info is complex:
mutlimanagername1
I already tried multithreading the first one, and later all of them, but nothing seems to work.
Let me know if you need the .rmf or .bsp to see what I'm talking about.
In case the info is complex:
mutlimanagername1
- targetname1 0
- multimanagername2 4
- targetname2 0
- multimanagername3 4
- targetname3 0
- multimanagername4 4
- targetname4 0
- multimanagername1 4
I already tried multithreading the first one, and later all of them, but nothing seems to work.
Let me know if you need the .rmf or .bsp to see what I'm talking about.
Posted 6 years ago2018-06-12 22:49:37 UTC
in Certain entities/functions not resetting their conditions. Post #339904
in Certain entities/functions not resetting their conditions. Post #339904
MistaX88 said:Alternatively, it wouldn't be that difficult to replace one of the 16 entities in a multi_manager with another multi_manager, and then have that new multi_manager trigger the other entity. You can have a branching tree of multi_managers.That's what I referred to with "creating a sub-multimanager", but instead of the 16th target being a multimanager, I thought of sub- one being the first, firing the "extra" target and then the multi_manager full of targets.
Posted 6 years ago2018-06-12 21:07:22 UTC
in Certain entities/functions not resetting their conditions. Post #339899
in Certain entities/functions not resetting their conditions. Post #339899
Kinda unrelated, but would giving a different entity type the name of another entity allow the multi_manager actually fire more than 16 targets? I mean, let's suppose one of the targets is called "target1", and it's a func_door brush entity - would a func_breakable of the same name break at the same time the func_door is being triggered?
There's just one new thing I'd like to get done, and my multi_manager entities all need their current 16 targets to be fired. I could perhaps create a sub-entity that does the new, extra job and Then fires one of the multi_managers, but I think that's both a dirty and unnecessary workaround.
There's just one new thing I'd like to get done, and my multi_manager entities all need their current 16 targets to be fired. I could perhaps create a sub-entity that does the new, extra job and Then fires one of the multi_managers, but I think that's both a dirty and unnecessary workaround.
MOCOLONI said:In fact my upcoming map for a community uses breakable brushes and tracktrains guided by 4 multi_managers (the idea is using them to reach the Breakables and break them, as there isn't a logic_case counterpart [or is there one?]), and got to know that both these entities get restored on round restart. I also got to know that it only fires the last 16 targets (or basically 'just 16 targets') ...
Posted 6 years ago2018-06-10 22:38:57 UTC
in Certain entities/functions not resetting their conditions. Post #339876
in Certain entities/functions not resetting their conditions. Post #339876
MistaX88 said:If you're mapping for CS, forget everything you know about Source entities. Unfortunately, there are severe limitations. Goldsrc doesn't have the input/output system of Source and not many entities reset from round to round. It's just something you have to work around.Appreciate your reply a lot, especially for letting me know that a multithreaded multi_manager can cause problems.
func_door is your friend.
func_door resets every round. ...
I should've added some more note such as that I've mapped "enough" in GoldSrc at this point to be aware most things you posted, but it's still a welcome reply as I would probably have never used a Door specifically to fire targets (although I discovered so by accident almost a year ago, but I'm certain I would not've kept that in mind).
In fact my upcoming map for a community uses breakable brushes and tracktrains guided by 4 multi_managers (the idea is using them to reach the Breakables and break them, as there isn't a logic_case counterpart [or is there one?]), and got to know that both these entities get restored on round restart. I also got to know that it only fires the last 16 targets (or basically 'just 16 targets') - I thought ticking the "multithreaded" flag would fix it, but nothing seemed to change (except a bigger filesize and longer compile times), but didn't experience any crashes (I guess it only happens on multiplayer servers).
Posted 6 years ago2018-06-08 20:16:09 UTC
in Certain entities/functions not resetting their conditions. Post #339835
in Certain entities/functions not resetting their conditions. Post #339835
Loulimi said:I know very little about the way rounds work in CS entity-speaking. However, what is it you don't understand about multi manager? I didn't get what your problem is.The multi_manager entity was just an example. If you know how Source mapping works, let's suppose that its counterpart, the logic_relay entity, fires targets with some delays; a round restart would also reset the logic_relay, but in GoldSrc/multi_manager's case, it doesn't happen and everything continues with the job until finishing.
In case you're still not sure what I'm talking about: a trigger_once is supposed to be used once, but not 'forever' like it does in the GoldSrc engine - in the Source one, the entity can be used again once the round restarts, while in GoldSrc it doesn't.
Posted 6 years ago2018-06-08 17:47:58 UTC
in Certain entities/functions not resetting their conditions. Post #339833
in Certain entities/functions not resetting their conditions. Post #339833
Hello. First of all I'd like to add that I'm relatively "new" to mapping for the GoldSrc Engine games. By new I mean I actually made (or 'have been making') a few maps for Counter-Strike, but unlike my 6-year mapping experience in Source games, I know nothing but the basics in GoldSrc, so perhaps this thread's point is already a thing to many people that know far more than I do.
It seems that entities like trigger_once seem not to get restarted after a round restart. They work fine once used, but not anymore until the map as a whole is reloaded. A multi_manager won't also stop firing all its targets and instead will keep doing so until reaching the last one.
Is this a known bug/feature? If at all, are there any 'proper' workarounds than just using other entities (and sometimes lots of other stuff) just to replicate the broken ones' function?
It seems that entities like trigger_once seem not to get restarted after a round restart. They work fine once used, but not anymore until the map as a whole is reloaded. A multi_manager won't also stop firing all its targets and instead will keep doing so until reaching the last one.
Is this a known bug/feature? If at all, are there any 'proper' workarounds than just using other entities (and sometimes lots of other stuff) just to replicate the broken ones' function?