Scouting overlay mod.

techmind_

Made a mod which reminds you to scout by color-coding unscouted squares and prints last time you saw what area (with 'vision', not radar) (uses the same key as 'reclaim view').
Only checks for 'scout' units for performance reasons (so any other units won't be checked) and only cares about 'move' and 'patrol' commands.
Will check only your own units so probably not that useful in team games (UI mods don't know anything about 'allied' units).
I only checked that it works correctly with 'better reclaim view', so it is a dependency.
Video: https://www.loom.com/share/44f598bc30bb4a56b07d52eda24f8b85
In the vault as 'scouting overlay'.

Dragun101

Nice job Techmind!

FunkOff

Holy crap that is pro

MazorNoob

I already hate you for this mod.

Zokora

Doctors hate him.

On a serious note, great job

Mach

is there a way to have more smaller squares for more accuracy? or would that kill performance?

also idk how code for this works, but maybe square should only consider itself "scouted" (that turns it green) if it was completely inside vision range of a scout, currently it seems to even if only a small part of it was scouted, which means there can be something inside it that wasnt scouted

I thought about doing something like this but using another "vision layer" like we already have for normal vision (the thing that puts a shadow over things you dont have vision over), which turns more red the longer you dont have vision over it (starting with completely transparent and resetting when scouted)

techmind_

@Mach said in Scouting overlay mod.:

is there a way to have more smaller squares for more accuracy? or would that kill performance?

also idk how code for this works, but maybe square should only consider itself "scouted" (that turns it green) if it was completely inside vision range of a scout, currently it seems to even if only a small part of it was scouted, which means there can be something inside it that wasnt scouted

I thought about doing something like this but using another "vision layer" like we already have for normal vision (the thing that puts a shadow over things you dont have vision over), which turns more red the longer you dont have vision over it (starting with completely transparent and resetting when scouted)

You can download a mod and change squareSize (curently 20px so around ~2 seconds of air scout fly time) to something else. I only check each ~5 seconds and i am predicting fly path of a unit (just assumes a direct line) (in next 5 seconds) to make a prediction of 'seen' squares. Yes you can probably make it smaller, but this will make it a bit more laggy. It is possible to check each 1 second and only mark 'seen' squares to make it precise , but it will becomes quite slow.

Also green squares are '30 seconds ago' threshold.

Jip

@techmind_ the textures currently don't have a resolution to the power of 2 - I'd recommend doing that. E.g., make them 256x256 instead of 200x200. If I have a texture that is 4097 the load time is increased by 10 seconds, but if it is 4096 (a power of 2) then it costs almost no time .

I don't think these small sizes will affect it, but it can't hurt either.

Edit:
Removing all the prints / logs will make it significantly faster too.

predictTimes =  math.floor(ScanTimes - 1)
destination = currentCommand.position
xDiff = destination[1] - ux
zDiff = destination[3] - uz
xDiff2 = xDiff * xDiff
zDiff2 = zDiff * zDiff
squareDiff = xDiff * xDiff + zDiff * zDiff
xSpeed = math.sqrt(uBp.Physics.MaxSpeed * uBp.Physics.MaxSpeed / squareDiff * xDiff2)
zSpeed = math.sqrt(uBp.Physics.MaxSpeed * uBp.Physics.MaxSpeed / squareDiff * zDiff2)

I understand you are trying to predict where the scouts are going but square roots are expensive and should be prevented if possible. You can compute the vector towards the target point - normalize it (that is 1 square root) and then multiply that with the time you expect it to move in that direction. That would be your predictedX/Y and reduce the number of square roots / unit by 1. Personally I'd even go for a version without a square root, but that is for another conversation .

I'm not entirely sure but it appears you keep creating / removing labels. Did you test to see whether it is faster to keep them around and hide them / move them out of vision? Allocation is generally expensive and I think you're doing it a lot by creating / removing them.

if (r.path) then
	-- CREATING? --
	if (not r.label) then
		-- last parameter in monitor pixels, need to change with zoom somehow =(
		r.label = reclaim.CreateScoutLabel(view.ReclaimGroup, r.path, squareSize)
		r.position = position
		r.labelIndex = labelIndex
		LabelPool[labelIndex] = r.label
		labelIndex = labelIndex + 1
	end

	r.onScreen = reclaim.OnScreen(view, position)
	if r.onScreen then
		onScreenSquared[onScreenSquareIndex] = r
		onScreenSquareIndex = onScreenSquareIndex + 1
		--tprint(r.position)
	else
		r.label:Hide()
	end

	labelsData[sX][sZ] = r
	else
	-- REMOVING? --
	if (LabelPool[r.labelIndex]) then
		LabelPool[r.labelIndex]:Destroy()
		LabelPool[r.labelIndex] = nil
	end
	labelsData[sX][sZ].label = nil
end

Zokora

Thanks @Jip for your input.

techmind_

@Jip said in Scouting overlay mod.:

@techmind_ the textures currently don't have a resolution to the power of 2 - I'd recommend doing that. E.g., make them 256x256 instead of 200x200. If I have a texture that is 4097 the load time is increased by 10 seconds, but if it is 4096 (a power of 2) then it costs almost no time .

I don't think these small sizes will affect it, but it can't hurt either.

Edit:
Removing all the prints / logs will make it significantly faster too.
predictTimes =  math.floor(ScanTimes - 1)
destination = currentCommand.position
xDiff = destination[1] - ux
zDiff = destination[3] - uz
xDiff2 = xDiff * xDiff
zDiff2 = zDiff * zDiff
squareDiff = xDiff * xDiff + zDiff * zDiff
xSpeed = math.sqrt(uBp.Physics.MaxSpeed * uBp.Physics.MaxSpeed / squareDiff * xDiff2)
zSpeed = math.sqrt(uBp.Physics.MaxSpeed * uBp.Physics.MaxSpeed / squareDiff * zDiff2)
I understand you are trying to predict where the scouts are going but square roots are expensive and should be prevented if possible. You can compute the vector towards the target point - normalize it (that is 1 square root) and then multiply that with the time you expect it to move in that direction. That would be your predictedX/Y and reduce the number of square roots / unit by 1. Personally I'd even go for a version without a square root, but that is for another conversation .

I'm not entirely sure but it appears you keep creating / removing labels. Did you test to see whether it is faster to keep them around and hide them / move them out of vision? Allocation is generally expensive and I think you're doing it a lot by creating / removing them.
if (r.path) then
	-- CREATING? --
	if (not r.label) then
		-- last parameter in monitor pixels, need to change with zoom somehow =(
		r.label = reclaim.CreateScoutLabel(view.ReclaimGroup, r.path, squareSize)
		r.position = position
		r.labelIndex = labelIndex
		LabelPool[labelIndex] = r.label
		labelIndex = labelIndex + 1
	end

	r.onScreen = reclaim.OnScreen(view, position)
	if r.onScreen then
		onScreenSquared[onScreenSquareIndex] = r
		onScreenSquareIndex = onScreenSquareIndex + 1
		--tprint(r.position)
	else
		r.label:Hide()
	end

	labelsData[sX][sZ] = r
	else
	-- REMOVING? --
	if (LabelPool[r.labelIndex]) then
		LabelPool[r.labelIndex]:Destroy()
		LabelPool[r.labelIndex] = nil
	end
	labelsData[sX][sZ].label = nil
end

It only removes label if square was scouted, otherwise they stay created (well that was intention, but there might be some bugs). Remove shoudl trigger then where is no 'path' variable (meaning empty texture - so it forces label deletion)..