Rampant

by Veden

Improves the enemies tactics by using potential fields (pheromones) allowing probing of defenses, retreats, reinforcements, counterattacking, breaching, raids, rallying death cry, and player hunting. Uses blockable biter projectiles. Adds new Enemies which can be disabled in mod settings. Difficulty setting in mod options menu.

Content
6 months ago
0.13 - 1.1
112K
Enemies

b Mod conflict

1 year, 9 months ago
(updated 1 year, 9 months ago)

Me again, sorry....

In the mod I'm developing, I've found a conflict with yours concerning collision_mask layers with your projectiles. In ProjectileUtils.lua, line 28, you have a fallback static assignment of {"layer-13"}. Can I ask that you change this instead to require the collision-mask-util file, and then use their get_first_unused_layer() function? Or if it's not even needed/used, then remove? (The only other places I see in your code referencing "layer-13" directly are commented out sections in data-updates.lua concerning the robots.) Assuming, of course, that having something there doesn't serve some other purpose.

While it doesn't appear to cause any direct issues in game, it does result in my code in control stage erroneously pulling your projectiles while it's trying to search for entity prototypes my mod affects. If projectiles and their current positions are saved in a save game, then I can see this leading to some odd results on load when my mod is first introduced or during config changed checks. :P

Edit: Sorry, should specify the caveat that this, of course, only happens if my mod happens to get "layer-13" as well (as it's using get_first_unused_layer(), and so it'll depend on other mods and load order).

1 year, 9 months ago

Thanks for the report. I think layer-13 was left over from something long ago and will be removed in the next version.

1 year, 1 month ago
(updated 1 year, 1 month ago)

Just wanted to poke this again. :) I burned myself out when developing said mod, so I never released it, but I'm back working on it again and it's pretty close to being done.

Edit: Ah, something else I've just noticed (because I normally have new enemies disabled), it appears that you may be calling LuaEntity::destroy() and LuaSurface::create_entity() in some places to replace vanilla spawners and worms with your new enemies without using and setting the respective raise_destroy and raise_built properties to true. This is resulting in my new mod not knowing when the old spawners and worms are removed (leaving some stuff behind) or when the new ones are created (so it can't place some additional stuff around them).

I also have one more request to make as well to support this new mod, but as I'm not actually done finalizing a couple of things with it, I'm going to hold off requesting that for now.

1 year, 1 month ago

The layer-13 thing has already been removed on the Dev branch.
I will need to double check the raise flags don't cause other issues otherwise I will add them.

1 year, 1 month ago

Thanks, Veden!

1 year, 15 days ago
(updated 1 year, 15 days ago)

Hi Veden, so I finally released that mod I was mentioning: Restrictions on Artificial Tiles

It's not able to pick up some of your new biter nests and worms, though, and even if it could, I'm not sure if you'd want my default values assigned to them or not.

In a nut shell, the concept of my mod is to make it so some tiles, which I refer to as "artificial" tiles (like concrete), cannot be placed where some entities are (like trees, cliffs, biter nests/worms) and vice versa, with some exceptions. In the case of biter nests/worms, when spawned on artificial tiles, they have a chance at "failing".

I have a couple of functions you can call from your mod in the data stage to register your biter nests and worms with mine:
RestrictionsOnArtificialTiles.Register_worm(worm, fail_factor)
RestrictionsOnArtificialTiles.Register_spawner(spawner, fail_factor)

fail_factor is a number of type double and is a coefficient used in combination with the average walking_speed_modifier of any tiles the biter nest/worm is on to determine the chance at failing: (avg - 1) + ((avg - 1) * fail_factor)

Allowed values are from -1 (least chance at failing across all tiles) to an unrestricted positive number (10 guarantees spawn failure with an average walking_speed_modifier of a little under 1.1 or greater).

You can pick which ever values you think are most appropriate for your biter nests/worms. For reference, these are the values I'm assigning to vanilla:
small worms: fail_factor of 1
medium worms: fail_factor of 2/3
big worms: fail_factor of 1/3
behemoth worms: fail_factor of 0
nests: fail_factor of 0.5

Anyway, I'm going to stop writing here. I hope what I've written makes sense and isn't confusing. :/ I've put more details on the mod portal page for my mod if interested, including a table at the bottom for various fail_factor and average walking_speed_modifier values. Assuming, of course, that it doesn't make things more confusing. XD

New response