Motion Scanner mock up

[KingKire]

Summary:
Possible reintroduction of the motion scanner

Benefits :
- Lore buff
- Allows marines to find last alien locations
- New equipment
- allows marines to get a general gist of alien size.

Details:
Piggybacking off the Squad Leader pinpointer discussion, we could use the "Ping" code idea to help reintroduce the motion scanner.
To put it shortly, instead of having the server calculate where every mob is every second, which puts huge strains on the server, have the player call out a "Ping" command when he wants to check the motion scanner. This ping command marks out all mobs within about 30ish tiles of the player and puts those locations on a small UI map. This command can only be executed once every 15 seconds by a scanner, to prevent lag.

Although this wont allow up to the second updates, it does serve CM SS13 well enough to be a useful tool to be added back into the marine equipment.

mOTION SCANNER copy.jpg

The thought process is:
-A: Cooldown bar: tells you the time before you can issue a ping again (can be hidden, or text chat alert only)
-B: Ping Button: clicking this link "pings" the motion scanner and issues the ping command.
-C: Grid marks: the "UI" for the scanner is cut up into a mini grid, which is a small grid map of the players area. scince SS13 is a grid based game, this divides up nicely to make a smaller UI map.
-D: Range markers: the range of the motion scanner should be large enough to be useful, yet short enough to not be overbearing. The players direction can be used to focus the map, same as when looking down a scope and having the view be set off-center.
-E: Markers: locations of living mobs, these are only updated everytime the player issues the "ping" command. These can have a deviation of +/-(X) where the farther the mob, the less accurate of the position/ number of the mob in question. Finding a mob within 7m's is really accurate, 21m's is off by several squares or such. maybe sometimes even failing to mark down the mob.

- possible notes is that maybe a stalking alien doesnt show up on the detector but thats balance issues. This here is the framework though for a possible reintro of an old mechanic.

- The fact that the motion sensor takes up a nice chunk of the players view is a good way to keep it balanced also.

[YungCuz]

This is good for finding those few xenos that hide. PLus muh immersions. +1

[Swagile]

Its fine if it shows even stalking aliens if its balanced around the fact that there is only a handful of them and ordering more costs a crap ton of points.

So you can't just sprinkle the FOB with this; it would have to be used tactically in the back lines / entrances of the caves.

[Eenkogneeto]

I would say to give squad leaders this, Because when combined with their existing binoculars It could help a lot giving your squad info. But I believe these are typically fairly hard to code without causing lag, and I don't feel they would be worth the impact it could have on the server. If a coder says its possible to do without lag using your idea, or one of their own, +1, otherwise... I have to say -1.

[Snypehunter007]

I seem to remember that it was removed due to the massive lag it generated...

[mullvad]

I seem to remember that it was removed due to the massive lag it generated...

Have you ever read the suggestion? He posts a possible solution that would alleviate the lag that was previously seen with the previous system, whilst i don't fully agree on this suggestion i do think that having a working motion scanner would be much much better than having none.

+1

[Snypehunter007]

Have you ever read the suggestion? He posts a possible solution that would alleviate the lag that was previously seen with the previous system, whilst i don't fully agree on this suggestion i do think that having a working motion scanner would be much much better than having none.

+1

I just restated the reason why it was removed eventually, this has been pulled forth for dev input.

[forwardslashN]

We're considering our options. There is a way to do a pretty close to lore motion detector with minimal lag, but I have too many things to do already.

[DeadLantern]

We're considering our options. There is a way to do a pretty close to lore motion detector with minimal lag, but I have too many things to do already.

Still do it.

+1

[Rocco Ward]

I'm going to toss some code-bits out here. I think this idea is doable without a crazy amount of lag as long as you make it basic feature-wise. First off, if this scanner is gonna be used constantly and updated every few seconds, we need a for loop that is OPTIMIZED TO GO MACH 5! To do this we need to narrow down our lists that we will be sorting through!

Our variables in this equation are the following:

• Number of motion trackers
• Number of mobs
• Distance from mob to motion tracker
• Speed of the mobs (optional)
• Mob size (optional)

To get our bare-bones list let's focus on the first two variables. We want the trackers to loop through a list of mobs to determine if the mob is valid. There shouldn't be a need to generate a new list for each individual tracker. That would a be a big waste of time, instead have all the trackers reference the same list when scanning.

As for mobs, while theoretically you COULD scan for monkeys, NPCs, and marines, in practice this is a horrible idea. That is a hell of a lot of mobs to loop through that would make repeated calls to the proc slow and time consuming. Keep it simple and only loop through xenos. (it's the difference between a list of 10-20 xenos, vs +100 all mobs)

So now we have our two lists, motion trackers and xenos. Right now our code would look something like this:

Code: Select all

//Note this is psuedocode... I'm not proficient with DM

//these vars are outside the tick loop
var/motion_trackers = list()  //whenever someone grabs a motion_tracker and turns it on, add it to this list
var/default_delay = 5     
var/detection_distance = 10
var/detection_momentum = 5

//need a for loop using the global iterator set to the default_delay
	var/tracked_xenos = getxenos()
	
	for (X in tracked_xenos)
		for (T in motion_trackers) 
			if (X.getPos() - T.getPos() >= detection_distance) //we need to get the absolute value distance between xeno and tracker
				if (X.getMomentum() >= detection_momentum) // this check is optional
				  //do something!  Emit a beeping sound?!  Idk 

As far as motion goes, you can reuse the code from a crusher momentum var and enable it on all xenos. That way when an xeno is below a certain momentum it isn't detected.

[forwardslashN]

It'll be looked into. No promises though. Resolved.