⚠️ SearchlightAssault ⚠️


Adds a game map and searchlights which sweep for foes at great range, alerting you while directing adjacent turrets to snipe spotted foes. Designed to dovetail with the early-mid game, searchlights provide: - Circuit network interfaces for search & detection I/O - Incentive to automate lamp & combinator production in the early game - New tactics to assault biter bases without leap-frogging turrets!

Content
3 days ago
1.1 - 2.0
12.4K
Combat

i Limit the field of Search

2 years ago

Rather than have the light search in a circle, could you have it scan in a cone in front to allow for a more focused search?

2 years ago

I've thinking about how to implement this.
Some people would want different scan patterns, so maybe I'd implement this as players selecting a cone-width from, say, 15 degrees to 360 degrees by sending a circuit signal with whatever size they want? I might wait for more feedback.

For now, players can connect the searchlight to a circuit network and send the X, Y coordinates using combinators to output whatever pattern they like on a timer. (eg; https://wiki.factorio.com/Tutorial:Combinator_tutorial#Basic_clocks)

2 years ago
(updated 2 years ago)

Another player suggested this, so I'm posting here just to keep the discussion organized:

What I'd like to see is something like this:
- when given either X or Y but not both: make it still sweep on the unset axis.
That way we can make it sweep left&right or up&down on a set distance with a simple constant combinator sending either X or Y.

a setting to lock only positive or negative on X and Y separatly (for example y=-1 => only negative Y)
With this we can make it search only 180° ( X=1, Y unset) or lock it 90° sections (e.g. X=1, Y-1).
Again, a simple constant combinator sending X/Y with -1 or 1.

https://mods.factorio.com/mod/SearchlightAssault/discussion/61bc1c4906bd61078aad09ce

2 years ago

I think SiegeMaster's suggestion is a bit better, giving settings to make a cone makes it more flexible than my suggestion and with the right implementation can cover my cases as well.

So far we have X and Y to set the exact position of the searchlight, as well as returning found targets to the circuit network with the help of A and W.
What exactly is the difference of W and A? as far as I c an tell it does the same, set the variable to 1 when it spots something.

I'd like to stay on the Signal-Input as settings route, it allows for a more complex setup if needed by anyone, so my suggest stays on this route.
I suggest to add 4 more variables (names and letter can of course be adjusted):

  • Radius R: reduces the search field from 360° to R°, making it cone shaped in front of the searchlight direction.
  • Rotation Z: rotates the cone around the Axis centered on the searchlight itself, allowing you to rotate the searchlights search-cone to a specified direction.
  • Minimum M and Maximum N: minimum and maximum distance the search light search area.

Any unset signals should make it default back to its regular behaviour on that variable, for example only setting R simply limits its search area to a cone in front of it, minimum distance and max distance untouched. (rotating the turret via R key could allow for a simple 90° switch)
I imagine a target-cone like the flamethrower, but dynamicly changeable via the variables. It would be fantastic if was possible to show the green target area like the flamethrower does. All these settings could be easily setup by a single constant combinator, easy to setup and feed into multiple searchlights all around the base. With the default rotation of the searchlight (R-Key) you could feed the same signal to multiple searchlights around the base without changing the signal at all. (Westwall searchlights are rotated 180° via R key compared to the eastwall searchlights, both use the same signals)

Maybe implementing custom signals, like the Logistic Train Network mod, would be useful at this point, allowing all these variables to be used base-wide again.

2 years ago
(updated 2 years ago)

W is for 'Warn' which is set to 1 when a spotlight suspects a foe, but has not confirmed it.
A is for 'Alarm' which is set to 1 when a spotlight is tracking a confirmed foe.

Maybe the distinction in my implementation is too subtle, so I might remove Warn and stick with just Alarm.
(It is very tricky to expand the Warn state to cover when a spotlight is chasing a foe but hasn't reached its 'check if foe spotted' stage)

2 years ago

thank you for the clarification. I never noticed the W signal showing up, it always switched directly to alarm state. In a roleplaying perspective it makes sense to have it (those "huh, whats that" scenes in all games), in a PvP scenario it would also be interesting to have spotlights chasing you until they actually manage to get you into the light fully. If you can manage to improve that it would give your mod a some flavor instead of a mechanical 1/0 kill switch only.

I like the searchlights behaviour of scanning the area for the same reason I like these drones (https://mods.factorio.com/mod/Updated_Construction_Drones/discussion), they beep and boop when driving around, are a little derpy on their pathfinding. They have a personality, making them more interesting than a simple "start game with construction robots mod".

2 years ago
(updated 2 years ago)

I just released version 1.1.0
This is a first pass at implementing cone-like target specification.
It also uses custom virtual signals, and may require rework of existing combinator signals.

Unfortunately, since I'm having trouble getting blueprints to preserve orientation, I decided to just have the rotation factor default to '0'.
You can still rotate a searchlight by hand, but if you send a rotation signal, the signal will override everything.

In the next release, I'm planning to display some kind of graphic effect to show an outline of the search-area as it changes.

If you don't see it in game yet, you can grab it manually here:
https://mods.factorio.com/mod/SearchlightAssault/downloads

2 years ago

thank you for the update. I've played a bit with your new signals and the new range/ammo settings.
Setting up turrets via constant combinator and these new signals is a joy now. it makes the searchlights much quicker to setup and makes them a much more efficient and customizable addition to the defense lines, it really added a lot to the mod.

One of the searchlights still used the old signals for some reason, but didnt cause any errors or weird behaviours, a simple pickup and redeploy fixed that.
Is O and P intended to stay as regular signals or will you convert those later as well?
I also noticed that the signal interface box is not operable, in Editor-Mode I can open it though.
Is it possible to make it operable by default and use that to set its settings without the need for external circuit connections? (and double its signal slots to fit all signals needed) It would remove the need for a constant combinator, making the setup a little more compact and self-contained.

And it still allows for complex designs if players want to. I tried a setup like this and it worked pretty well:
If one searchlight detects a target all searchlights in that region gather in that region for the next 30s, then return back to their original search region.
Each turret has a constant combinator assigning it its position. when an enemy is spotted (alarmsignal) each searchlight adds X to their existing search direction for the next 30s. (and a slight increase to its min-range)
X = (myTurretNumber-AlarmturretNumber) * 10. Neightbors will only move 10°, the next ones will 20° etc. , max 60°
By not using X&Y they retain their searching behaviour and it actually look like 5 guards searching the area like on those prison break movies, its really funny to see xD

2 years ago
(updated 2 years ago)

Yes, the old signals remain until the searchlight is rebuilt. Hopefully that isn't too big a problem, I haven't figured out to make a migration file to address that.

O & P are still intended to stay for now. When I have more time I want to make more custom signals, but those are low priority for now.

The signal interface box is not supposed to be operable, but the editor is supposed to be all-powerful so I'm leaving that as is. Messing around with it may cause strange behavior since the code is expecting certain signals to be in certain slots, but if a player's in editor mode they're probably knowledgeable enough to handle things. As long as players can still connect wires to the interface it shouldn't matter too much if the interface is inoperable.

It could be possible in a future update to make the interface more flexible, so players can use it as you describe. It's just a little annoying to get blueprints to preserve information like that, since I have to do a lot of funny stuff to make the interface build itself when the searchlight is built. So, it might be a long time.

Your setup to have all the lights gather up like that is so cool! I haven't had the time to do anything 'reactive' like that, it's really neat to hear that someone has discovered a potential use like that. It'd be awesome if you could share the blueprint string so I can check it out =D
If you like, you could even make a thread so everyone can share blueprint designs with each other.

2 years ago

I agree I removed the mod since it was only working half the time and it was using up very high resources compared to other mods. If it had a 90 degree and a 180 degree variant then it would be much more optimal.

2 years ago

The setup with the gathering lights had a few problems in corner cases where they didn't reset back to their normal behaviour, or straight up refused to change their behaviour.
I dont know if its a problem with my circuit math, but it seemed that flickering the signal (rapid on/off) worked best when they ignored resets or new settings.
Maybe it has to do with update speed/intervals, where your mod checks for new settings. It does not seem to respond well to quick or automatic changes. It sometimes took a whole minute for them to change their behaviour when changed via circuit math (decider combinator), while direct constant combinator input never showed a delay like that.

I instead linked the "enemy found" coordinates to a AAI Vehicle group, with a bit of combinator magic to make them a little spread out to cover more ground to defend. That worked fine so far, and recalling them to parking spots for refuel and rearm after some time passed.

@SannicK
The first version was missing degree input like that. This has been updated and can be set with a rotation and angle signal now via simple constant combinator connected to the lights. This feature really changed the mod alot. I didn't take a look at UPS impact, but with the mid-game-ish bases I tested I did not notice several dozen searchlights per warfront.

2 years ago

That's interesting Quaitgor, if you send me your setup I'd be happy to take a look and see if I can optimize things a little when I get the time.

Sadly, I'm off vacation so progress is slower these days.

2 years ago

I've just released version 2.0.0, which allows setting searchlight signals directly via a GUI, among many other features

The new version should start to appear in the mod portal shortly.
If you don't see it in-game you can download it manually here: https://mods.factorio.com/mod/SearchlightAssault/downloads

New response