Store Page
Garry's Mod
All Discussions Screenshots Artwork Broadcasts Videos Workshop News Guides Reviews

Garry's Mod

Store Page
Garry's Mod >  Workshop > 小スライム's Workshop > Replicator Melons Rereplicated > Discussions
Replicator Melons Rereplicated
Description Discussions8 Comments84 Change Notes
sharktemplar Jul 27, 2019 @ 7:47am
1.0 Suggested New Content/Recommended Changes
I split my feedback report into 2 sections. Bugs, and my thoughts on how existing stuff could be made even better. Obviously I don't want you to feel like I'm pushing more stuff on you and demanding you do it or anything. Please completely ignore, or genuinely consider any, all, or none of these options, entirely at your leisure/discretion. What you've made so far is fantastic, these are just a list of things I think could benefit from either a small change, or the introduction of a new option entirely to boost usability. I'll give as much detail as I can to explain my reasoning in case you're interested in one of these in the future, should rereplicated get lots of momentum and downloads. I made these extensive in detail, feel free to just skip over reading one if the tagline concept doesn't interest you or you disagree that it could benefit from a change.

1) Additional spawning options. Melon Nests?

Have the melon menu in Admin > Utilities have some special spawning options, such as spawning a replicator melon in a random location on the map, spawning a small configurable cluster of melons in a random location on the map, and more interestingly, spawning a "nest" on the map. I put the word nest in quotes because it could simply be a little transparent (but toggle-hideable) prop that represents a spawning location where melons spawn from if the total number in the map goes down, or perhaps simply through a set timer that only shuts off when max melons is reached. Or you could make it more interesting and have it be a custom model that legitimately looks like a giant melon webbed on to a surface where melons will spawn from. You could even integrate nest protection behavior into the melons, so that when their nest takes damage, they immediately forfeit their current pursuit and change targets to whatever attacked the nest, even if said nest attacker is way out of target-search range? A small movement force boost could be nice as well to help the melons rush back to the nest location slightly faster than whatever is the current default pursuit speed.

2) Option to customize/disable blood decals.

It's certainly better than wood yes, however it would be a lovely little addition to let players change the surface properties of a replicator melon to other things besides flesh, as well as change what decals (if any) are created upon a melon taking damage. Antlion blood as a good example, since the current blood decals only really make someone think of blood and not melon guts as they've seen those hl2 blood decals so many times by now.

3) 'Hop' feature included in forget-attempt cycles to avoid unnecessary target-forgetting.

Replicator Melons can often get stuck on very silly obstacles, such as a single prop, or even just a curb on a road. This is especially true if Melon movement force is too low, then the melon has no hope of ever getting over it without the help of other melons to provide a group speed buff. Adding a little "hop" feature that pushes the melon slightly upwards (proportional to current movement force settings of course) can help bypass this. To try and maximize the amount of times a melon can get successfully unstuck from this, it could be made that for each forget attempt, a "hop" takes place, and the more forget attempts the melon is told to undergo, the more extravagant the hop gets. If for get attempts are set to 5 for example, there would be 5 total hops pushing the melon briefly upwards, each hop stronger than the last, until finally that target is disregarded and categorized as unreachable for the time being.

4) Every option in the menu should have at least an ultra-basic single-sentence description.

For example, the "Assimilate Extraneous" option might not be clear to certain people who did not read the convar wiki post you made, and don't realize it includes any and all other entities which do not fit into the category of player, npc, or prop. A small description like "Entities that are not player, prop, or npc." would be helpful to the less verbose user.
https://steamcommunity.com/sharedfiles/filedetails/?id=1816719854
Also, in this screenshot, it cuts off what a certain option actually does, which may confuse players in their understanding of what it does. "Wander direction ch..." and "Maximum wander sp..." are not descriptive enough before they cut off. Even if it were a full sentence, "Wander direction change time" may not be suitable enough either, as not all players know that ticks are tied to their framerate in singleplayer and may just blindly assume it represents in-game seconds instead. Something like "How many ticks pass until a melon picks a new direction to wander." is more educational. Melon bite cooldown is also misleading without a description, as it leads the player to believe it represents seconds rather than ticks. Perhaps a small hint in the menu somewhere that net_graph 1 in console can show you the tickrate of the server? Something to help layman melon-pocalypse players to better gauge what exactly they are tweaking.

5) Max Leader Melons configuration!

An option to choose how many leader melons can exist at a time would be very helpful, not only in conjunction with several other mechanics such as melons no-colliding with each other after a certain group size (which is only specific to that group's leader melon, and not simply all melons in a close vicinity), but it would also pave the way for more functionality in some of the below listed recommendations as well that I will explain.
Should all leader melon slots currently be taken, a melon without a swarm will no longer go into wander mode when no target is found, but in place of wander mode, target the nearest leader melon and pursue it in the same manner as it would pursue a real target so the melon can join the swarm instead of being a loner leader melon with no purpose or swarm of its own (which is a recurring thing I've noticed, so this can double as a resolution to that.)

6) Melon Tracker 3000!

This could simply be an additional box of info provided in the replicator melon options menu, or it could be an actual device the player holds (a swep) that provides configurable amounts of information about the current melon-pocalypse, such as:
How many Replicator Melons currently exist on the map.
How many Replicator Melon swarms currently exist on the map.
How many leader melons currently exist on the map.
How many melon nests (if implemented) currently exist on the map.
The size and buffed detection range/speed (measured in a multiplicative number as per the functionality of rmelon_group_force) of the largest Replicator Melon swarm currently on the map.

Hell you could even get fancy with it if you perhaps collaborated with others that had swep development experience, or if you had the know-how to do it yourself, and add a literal distance-tracking system, where Replicator Melons appear as dots on a small radar-sweeping screen with configurable boop sounds to give the melon-pocalypse player dynamic anxiety based on how close Replicator Melons are and in what numbers. Akin to the xenomorph detector from Alien: Isolation which got a swep port over to gmod a few years back.

7) Ring-around-the-rosy counter-measure built into melon pursuit a.i.

Due to the nature of how melons pursue a target, a player can simply run, or even just walk in small to medium circles and be 100% safe from melons of varying speeds or sizes. It's hard to get out of, but can provide a player an unlimited window to shoot the melon and kill it. For servers that may incorporate this as a fun little server event, this oversight could be easily resolved in a couple ways:
You could make it so melons have a speed-boost in a very specific direction to try and cut off the player as they do one of their circles should the condition be met that a target is within extremely close proximity for an extended period of time.
OR, more cheaply, you can simply have the melons pursuing a specific target have their Movement force steadily increased more and more if they remain within extremely close proximity to a target for X amount of ticks/seconds. The ring-around-the-rosy technique to avoid being assimilated becomes staggeringly more difficult to pull off when the melons are given a speed boost, so if the melons can be cleanly coded to recognize they might be in a ring-around-the-rosy loop, they can have their movement force raised all the way up to the max of 500 (though it would never need to go that high) until the current target is destroyed/no longer a target (via target command changes or something), at which point the Replicator Melons bump their movement force back down to the default that it should be at for whatever their swarm size currently is.

8) Cool sound customization update for the future?

It would be very nifty/hilarious/terrifying/fun if the player could add custom personality to their melon-pocalypse by setting specific sounds for melons based on certain melon actions. A custom-selected sound (or perhaps just selected from a roster of default sounds if that's easier) could play when a melon:
Is idle and wandering
Takes damage
Successfully bites a target
Successfully assimilates/kills a target
Is actively pursuing a target

You could incorporate the built-in sound shenanigans with the source engine that gives you access to things like pitch-shifting (which also just changes speed of the sound as it's played), goofy sound filters, volume, and max audible distance as well. All configurable in the menu.
If you do go this route though, be sure not to run into the nasty issue of MAX_CHANNELS errors that can flood the console (with developer 1 enabled) when too many sounds are tried at once. If too many sounds (or even an attempt to play a sound, regardless of if the sound successfully played or not) can prohibit other sources of sound from functioning properly, and so you would want to add in a configurable cap of how many melons are allowed to have a voice at any given time in the map, lest other sounds be forfeit like footsteps or npc noises or even soundscape sounds from the current map. I learned this the hard way from source engine mapping.

9) Forget-target options description is too vague.

I know from the convar wiki you made that the "Forget time" option is how many recache cycles a melon will consider a forgotten target to be an invalid target for, and after this period it is a newly available target again, however the description in the menu is quite vague on this. It simply says it "will forget the target" and doesn't explain this at all, leading the layman user to presume it's perhaps how many in-game seconds or ticks between a forget attempt to the next forget attempt, or maybe the time in seconds the melon must be stuck before it begins the forget attempts at all. I suggest changing the description to read a little more like "When a melon has not moved further than the stuck distance after X attempts, it will not pursue the target until X melon recache cycles have passed"

(Continued below)
Last edited by sharktemplar; Jul 27, 2019 @ 7:48am
< >
Showing 1-15 of 17 comments
sharktemplar Jul 27, 2019 @ 7:47am 
(Continued from above)
10) Clump Melon Concept.

A nice and efficient way to prolong a melon-pocalypse's enjoyment factor is obviously by adding more melons, but the more you add, the closer you get to a cap where absolutely nothing can stop the swarm. It's simply too large, too fast, and most importantly, too laggy to enjoy. Incorporating a sort-of step-up principle to this could make melon-pocalypses far more interesting and allow for melons to consume and grow in far larger represented numbers without actually impacting performance that badly. My proposal is this:
A leader melon, should its swarm become large enough (according to a configurable variable), it will literally grow in size, consuming a few melons from its swarm in the process. This ties in with my previous recommendation of specifying how many leader melons can exist at a time, because only a leader melon is capable of clump-growth, meaning you also have control of how many big boi melons can exist at a time as well. You could also stack this mechanic, so that clump-leaders can conjoin with other clump-leaders and 2 swarms can combine, triggered by when a swarm grows big enough and also has a leader melon of clump-stage 3 for instance. Rather than go to clump-stage 4, it seeks out an equal or lesser clump-stage leader melon for conjoining into the next stage. A clump-stage leader melon who is shot and 'killed' will not in fact die, but simply break into (a configurable amount of) normal sized melons upon death, or perhaps spawn a regular sized melon after taking a % of damage and shrinking in a % of size proportional to how much health was lost. You could do it dynamically so it has many stages, each representing a single melon the leader has clumped with, or more cleanly so there's only 3 stages but the leader eats (and discharges when damaged) several melons all at once to reach/lose a clump size stage.

This ultimately allows for swarms to be technically larger and more dangerous directly proportional to their size without actually increasing melon prop counts and weighing further down on performance.

This would need a few additional options to ensure it conjoined with other mechanics though, such as max melons.
If the maximum amount of replicator melons is currently reached, all replicator melons can be told (via a variable toggled on or off) to cease hunting immediately and group towards a hungry leader, who will then attempt to consume some of his swarm (how many melons of said swarm would be based on a configurable variable) and grow in size, maintaining the swarm buffs, but lowering the swarm prop count just a touch. If the max melons limit is reached but there are still not enough melons in the swarm for the leader to consume any (according to the set variable), then the swarm will simply continue as normal, hunting as a giant cloud of fruity death and no growth will ever occur. This will allow for the option to make replicator melons automatically group up into as strong of a form as they can once max melons has been reached and try to maximize their power rather than having a bunch of stragglers all over the map. This also doubles as a means to try and make a melon-pocalypse more prop-efficient, as when max melons is reached, all stragglers will seek out the hungry leader (if the option is enabled) rather than simply hunt on their own as their kill would not result in a newly assimilated melon.

You would of course also need options pertaining to how much (if any) buffed stats a leader melon receives from growing, such as if their speed should be increased or decreased and by how much per stage, how much health they now have per stage, how much more bite damage they do per stage, whether or not the regular-sized remaining melons of the swarm abide by the leader melon's new speed, or abandon the clump leader and go off to seek their own prey and start their own swarm, and at what clump-stage they choose to do this and in what percentage of the swarm, yadda yadda, all the good stuff.

You could take this yet another step further and have the final stage of a clump-leader be that the clump leader plants down to the nearest surface, wall floor or ceiling, and becomes a nest (should you implement nests) and will now begin slowly spawning replicator melons, of which all melons part of that original swarm will now treat as their home nest, meaning they would rush back to it should it suffer a certain % of damage to its health, just like melon behavior from melons that came from a spawned-in nest as well.
Quite intricate in its entirety, I know. But I could legitimately see a really fun new garrysmode gamemode spawning out of this, should people end up adoring the addon, which motivates you to add more to it over time.

11) Special-conditions target-acquisition options!

This is a nice little addition that is essentially a more clarified and configurable version of the concept mentioned earlier of melons immediately changing targets to whatever is damaging their nest, regardless of its range.
An option to allow a swarm of melons to change targets based on conditions such as if a melon from that swarm is attacked/killed, the culprit of the attack is the new target of that swarm even if it's farther away than the search range could find on its own. This allows for fun melon-sniping missions through cityscapes where you find a melon, snipe it, and suddenly you discover it was not a straggler but part of a larger swarm it was semi-separated from, and the whole swarm comes flooding out of nearby alleys heading towards you.
You can add other special target-acquisition conditions such as extreme close proximity. Often times a melon will refuse to switch targets even if another valid target is considerably closer. You could have an option that allows players to set extreme-proximity target changing, meaning any player/prop/npc (configurable as to which) that is within several feet of a melon, that melon may even choose to abandon the swarm for a brief moment and roll a few feet over to the free assimilation target.

You can also add options that can provide small buffs to the melons for X amount of seconds/ticks/melon recaches which occur as a special-condition target-acquisition is met, such as a temporary movement force boost for that specific swarm. This means melon swarms are configurably more dangerous if you choose to engage them first rather than them simply finding you as normal.

12) Swarm size-specific options.

This option would enable swarms to have different degrees of an existing default option based on their swarm size that wasn't just movement force. For instance, an option to make a swarm have a lower bite cooldown based on how large it is would result in a swarm of melons being disproportionately more ravenous than a small handful of them. Or, an option where movement force can be adjusted proportional to that swarm's specific size. You might think I'm just stupid as melons already move considerably faster the larger their swarm is, but what I'm talking about is having a means to configure how big that swarm must be before a buff is applied as well as that buff being able to be a debuff (negative number) instead is what I would like added, and the reason is because it could be set so that a swarm smaller than, say, 6 melons will flee from you via a negative movement force setting, but only for those melons, as they are not large enough numbers yet to engage you. This results in really fun gameplay instances where you fight off a swarm rolling towards you, and when you kill enough of it, it scatters and flees to go try and regain its numbers. Or, in an opposite direction, you could let the player set it so that when a swarm is down to just 3 melons, those last 3 melons have an all-or-nothing buff where they get an extra boost of speed and health and bite damage because they are part of a swarm which is <=3 melons. This would let the player configure whether they wanted swarms to be more dangerous in large numbers, or more dangerous in smaller numbers, which opens up lots of fun new possibilities that extend further than simply a hardset boost which can be disabled that is triggered by the amount of melons in the swarm.

A "swarm X boost per melon?" toggle conjoined with a "by how much per melon?" slider, with X being for movement force, health, bite damage, search range, and maybe even priority (so that small swarms prioritize safe targets like npcs and props, and large swarms prioritize players) would go a loooong way in my opinion.

13) Target-type-specific 'Only bite target' option.

A small one. I just think it would be nice if the melons could be set to bite anything they touched (that had health to lose) or be set to only bite the target they were pursuing, similar to the assimilation toggle where something can be assimilated even if it's not targeted by the melons. A player that can be bit without being targeted could make for some fun instances of players needing to traverse an environment being thrashed by replicator melons, but the consequence of touching them isn't instant death as it would be now with the instant assimilation toggle.

14) Edit: Oops disregard, completely forgot "Melon group range" was already an option. This was asking for group swarm buffs to be configurable by radius from the leader, which is already true with the existing option slider.

15) Option to determine duration of new melon leader adoption.

As it stands, if the leader is killed, another leader is chosen shortly after (or instantly for all I was able to tell). An option to let the player choose how long it takes for a melon who has lost their leader recently to be able to adopt a new leader and receive any swarm buffs from it would be nice. It could help avoid situations where aiming for the leader (especially if the clump melon concept is adopted) would be virtually pointless because a new leader would be instantly chosen and the buffs would be granted back within half a second, resulting in no real value from successfully down-sizing/killing the leader melon. However, given how you may have coded the means in which a melon decides its group and receives said buffs from said group swarm, this would need a quirk added to it, so that a melon who has strayed too far from its leader can come back within range and receive those buffs immediately again, but the leader dying outright results in the melon needing a cooldown period before it can adopt a new leader to follow, even if one is present very close by.

16) Toggle off impact particle effects for optimization.

Not sure if it's even possible to do anything about, but swarms of melons that rub up against things (which often happens as they bounce around or press into walls) results in lots of dust impact particle effects, and when there's a big swarm, there's lots of particle effects. If the player is close by to these particle effects it can tank their performance, such as if they are in a building and the melons fly up against the window on the other side. This is a very fun thing to experience, a small staple to replicator melon if you ask me, so it sucks that when a swarm tries but fails to reach you in a large enough size, it attacks your fps instead as a result of these melon prop impact particle effects. If there is any way to add in an option to toggle it off, it would be a huge bonus for optimization.

17) Options save profiles! (Edit: Have been added. Entry omitted.)

That's all I have for now. I'll make new comments to this thread if I get any other ideas I think might be particularly beneficial to the addon or interesting to you, again all completely under the assumption you would want to work further on it anyway. You've done some really great work here and I'm very appreciative so feel free to ignore literally 100% of this. Well done, and thank you for rebooting Replicator Melon!
Last edited by sharktemplar; Jul 31, 2019 @ 11:46pm
#1
小スライム  [developer] Jul 28, 2019 @ 12:15am 
I see you've added #17 and it was already on the planned features list, if I can manage it. It would certainly make testing far easier lol
#2
sharktemplar Jul 28, 2019 @ 12:34am 
Originally posted by nikki:
I see you've added #17 and it was already on the planned features list, if I can manage it. It would certainly make testing far easier lol
Yeah looking back I kinda wish I'd organized these from easiest/most valuable to hardest/least impactful. Some are obviously quite useful in relation to how much work they would take versus others.
#3
Zuletzt bearbeitet von REMO Jul 30, 2019 @ 3:33pm 
permenent convars:

when you change a canvar and go to another map and or game the settings you set up stay that way
#4
小スライム  [developer] Jul 30, 2019 @ 3:36pm 
Originally posted by REMO:
permenent convars:

when you change a canvar and go to another map and or game the settings you set up stay that way
already planned
#5
TobyCat Jul 31, 2019 @ 5:32am 
"reset settings to default" Button?

Because messing with the settings is fun but sometimes i want it to be fixed.
Last edited by TobyCat; Jul 31, 2019 @ 5:32am
#6
小スライム  [developer] Jul 31, 2019 @ 11:35pm 
# 17 Implemented.

Originally posted by REMO:
permenent convars:

when you change a canvar and go to another map and or game the settings you set up stay that way


Originally posted by TobyCat:
"reset settings to default" Button?

Because messing with the settings is fun but sometimes i want it to be fixed.

You may utilize the new preset system to accomplish both of these. Just added it :csdsmile:
#7
小スライム  [developer] Aug 4, 2019 @ 8:47pm 
I've added a way to randomly spawn a melon on the map. It uses NavMeshes to determine position, so the map will need to have them generated. There's a console command to do that if need be.
#8
sharktemplar Aug 5, 2019 @ 4:33am 
Originally posted by nikki:
I've added a way to randomly spawn a melon on the map. It uses NavMeshes to determine position, so the map will need to have them generated. There's a console command to do that if need be.
awesome, could you make it also opt for ai_nodes? Lots of maps use nodes instead of nav meshes for things like vj base npcs, and said nodes only exist where an npc can most definitely travel to or spawn at. That would increase the amount of maps the function works on without needing to generate a nav mesh and restart the map.
#9
小スライム  [developer] Aug 5, 2019 @ 11:50am 
I could only find functions relating to the position of navmesh nodes, no idea about ai nodes
#10
sharktemplar Aug 5, 2019 @ 12:25pm 
Originally posted by nikki:
I could only find functions relating to the position of navmesh nodes, no idea about ai nodes
Well I know that the Zombie Invasion+ addon uses ai_nodes to decide where an npc can be placed. Perhaps if you have the means you could peak into that code, maybe see if there's a nifty trick you didn't know about?
#11
sharktemplar Aug 6, 2019 @ 3:01pm 
Originally posted by nikki:
I've added a way to randomly spawn a melon on the map. It uses NavMeshes to determine position, so the map will need to have them generated. There's a console command to do that if need be.
actually I can't even find it, where exactly is this feature to random-spawn a melon?
#12
小スライム  [developer] Aug 8, 2019 @ 7:00pm 
Originally posted by sharktemplar:
Originally posted by nikki:
where exactly is this feature to random-spawn a melon?

It's in the same menu as the melon settings, underneath cleanup.
#13
sharktemplar Aug 8, 2019 @ 8:19pm 
Originally posted by nikki:
It's in the same menu as the melon settings, underneath cleanup.
https://steamcommunity.com/sharedfiles/filedetails/?id=1829237792
https://thumbs.gfycat.com/UntimelyComposedKingsnake-size_restricted.gif
'cuz I can't find it. No matter how many anti-♥♥♥♥♥♥ pills I swallow and look through the whole menu again I just don't see it, lol.
#14
小スライム  [developer] Aug 9, 2019 @ 1:09pm 
👀 what in the world
#15
< >
Showing 1-15 of 17 comments
Per page: 1530 50