Posts made by Resin_Smoker

@maudlin27 true... good idea

@Jip

The goal of this mod was to make intel directional vs a sphere, thereby making it less powerful as a result. Currently, as the game stands, intel is incredibly overpowered. Now, if reduced coverage means that players feel the need to manage their intel units to have better coverage, then that's up to them. This was the intended idea, after all.

Using the existing Intel was required as doing otherwise, would of introduced a whole laundry list of issues further on. Over writing the existing lua was also required as the way it's currently setup doesn't lend itself to being easily mod'd without it.

The memory and sim speed are things that can't be helped as this is directly related to the creation of entities and how the intel radius is being scaled for each one added. (Pearls on a chain) The only alternative I can think of for radar would be to use a single entity and a slider. Then, rapidly move the entity away from the parent while increasing its intel radius. This would allow for fewer entities but make the coverage provided a bit spotty. Simply because the intel fog would creep in between slider passes. Rotation of the radar with a slider wouldn't be possible as this would create even bigger gaps.

Edit: Projectiles could easily be used in place of the entities, with the added benefit being that terrain would block radar. The projectiles would simply encounter the terrain, have an on collision check, and be removed from play.

Furthermore, rotators, as they are be handled, are uncontrolled or rather undefined assets. Many of these are either set up under local variables or have some arbitrary global name attached to them. Which makes it very difficult to externally see if a unit already has a rotator in play for a given bone.

The air-scouts losing the cone on landing was planned. After all, this was just a test to see if it were possible. Though I'm not believing this is worth further development considering the lack of interest. Someone is welcome to pick it and run with it if they think they can do better.

@nuggets If the mod uses ANY sim side code then it is termed as a SIM mod. Maybe there was an exception for this mod due to its acceptance and popularity.

@nuggets Cause explosions are all sim side mate.

@ctrl-k Don't be coy.
, if you have something to say, spit it out.

So no feed back... Glad I didn't start the 2nd half of this mod.

Discovered today that entities like the radar entities I'm using can be connected together and then offset from each other, Kind of like pearls on a string. They can not however be rotated without the use of real unit as something is missing from a blank entity that the CreateRotator needs. Played around with attempting to add Sync_Meta to a blank entity. Was able to add it without the game freaking out. However in doing so, the entity was not longer able to be attached to anything.

Projectiles were next on my list of candidates but unfortunately attaching them appears to be problematic if they have any velocity set within their bp. While this can be nullified easily, they're not able to rotate via CreateRotator. Though I know some of the missiles do spin, which suggests that this is being handled by the game engine.

Helper_unit is next on my list to try... I know it will 100% work with CreateRotator but I'm concerned that using helpers in this way with intel could create unit cap issues at some point.

Uploaded a quick and dirty video: https://youtu.be/smLBx5wSLBc

Made a some significant changes to aid in performance as well as to make the radar behave better. Most of the previous issues have been addressed. Though I am still looking for a way to detect if a unit has a spinner of not via some scripted method. (CreateRotator)

File: Update 7-16-2024 Advanced_Intel.zip

Please note that in the above file, test-mode is active. So rather than seeing Radar, you get vision in the shape that the radar would of been. This makes it easier to see what the radar is doing within the game world as normally you can't otherwise see it.

Keep in mind that the file posted is not a public release but does allow people to try it out and provide feedback. Beyond that, I'll start looking at adding the sonar component to this soon.

Question: Was also pondering EMCON or emissions control. With the idea being that if someone is transmitting a signal into space, that others can see you. Effectively meaning, that if your radar is active, the enemy knows where its coming from, but not necessarily what its coming from. How would people feel about something like this, assuming its possible ?

Today I was able to sort out the issues noted earlier and clean up the script some too, making it much easier to read. Only issue to sort out is that some units have spinner antennas and all have non-standardized naming. Using the existing spinner as the radars point of origin /rotation requires that I figure out how to locate them in a simple, stream-lined way.

Side note: I've also created a "test-mode" so that the radar cone can visually be seen by the player, as normally you'd not know it was there until you had a radar ping.

Edit: The CreateRotator is a real mess. Some of these rotators are defined as locals and then added to the trash within the units script. Not sure how I can go about detecting the rotators to prevent from creating another one on top of a pre-existing one.

@snoog cool beans... apart from the flush glitch it should behave alright. Be aware the small radar units have a vision radius that's almost as large as the radar range. Meaning the scouts will appear to have a smaller range, but they don't. It's just a narrow beam, that may not see another unit in passing if the beam doesn't cross it.

So I've made quite a bit of progress on this mod.

File removed as an update has been made available further down the page.

Which allows radar based intel to extend from the unit in the shape of a cone. For Radar structures this cone rotates around its highest point. (All of this 100% works with no errors) This mod applies to all units in play.

That being said, for units where you can toggle the radar on / off, the intel for the enemy units is permanent. Its as if the intel hasn't been cleared out (Flushed) between the time the radar was removed and later when its reactivated. Not really sure what's causing this but I'm hoping that some sharp eyed individual can spot it and possibly clue me it as to what's going on.

Edit: I may have left some of the script dialog active, so your likely to see things in the log like "WARN" and so on. I use this to see how the script flows to better understand the mechanics of the intel system. To disable those look for local myDebug = true within defaultcomponents.lua and set as many as you find to false.

Resin

Pulling my head from my arse usually helps.

Bad script...

for k, v in self.RadarConeEntitiesTable do		
   self:EnableIntel({self.RadarConeEntitiesTable[k]})
end

Should be...

for k, v in self.RadarConeEntitiesTable do
   v:EnableIntel('Radar')
end

Recently I've been working on importing the intel cone scripts into defaultcomponents.lua

InitializeRadarCone = function(self)
	if myDebug then WARN('InitializeRadarCone') end
	
        -- Int the entities table
	self.RadarConeEntitiesTable = {}
		
	-- Set up local variables from spec
	local bp = self:GetBlueprint()
	local bone = nil
	local radius = bp.Intel.RadarRadius
	local rotate = false
	local start = true
	if myDebug then WARN('	bone: ', bone,'	radius: ', radius,'	rotate: ', rotate,'	start: ', start) end
	if radius > 0 then
		if myDebug then WARN('radius > 0') end
		local counter = 1
		local loopFlag = true
		while not self:BeenDestroyed() and counter <= radius and loopFlag do
			if myDebug then WARN('LOOP') end
			-- Create a radar arc thats approx 45 degrees and is roughly the radius needed
			local angle = math.ceil(counter / 3.14)
			if counter + angle < radius then
				if myDebug then WARN('	Counter + angle < radius') end
				-- Attach the entity to parent
				local radEnt = import('/lua/sim/Entity.lua').Entity({Owner = self,})
				if myDebug then WARN('	entity created') end
				radEnt:AttachBoneTo( -1, self, bone or 0 )
				if myDebug then WARN('	entity attached') end
				table.insert(self.RadarConeEntitiesTable, radEnt)
				if myDebug then WARN('	entity inserted into tbl: ', table.getn(self.RadarConeEntitiesTable)) end
				self.Trash:Add(radEnt)
				if myDebug then WARN('	entity added to trash') end
				--	Offset the entities so they create a cone from the parent
				radEnt:SetParentOffset(Vector(0,0, counter))
				if myDebug then WARN('	entity offset') end
				-- Set who can view the entities intel
				radEnt:SetVizToFocusPlayer('Always')
				radEnt:SetVizToAllies('Always')
				radEnt:SetVizToNeutrals('Never')
				radEnt:SetVizToEnemies('Never')
				if myDebug then WARN('	focus set') end
				-- Initalize intel
				radEnt:InitIntel(self:GetArmy(), 'Radar', angle)
				if myDebug then WARN('	intel initialized') end
	        else
	        	loopFlag = false
	        	if myDebug then WARN('	flipping flag to end loop early') end
	        end
	        if loopFlag then
				counter = counter + 1
				if myDebug then WARN('	counter increased') end
			end
	    end
		if myDebug then WARN('	end loop') end
		if start then
			if myDebug then WARN('	starting on') end			
			--	Initialize and enable intel types
			self:EnableRadarCone()
        end
	    if bone and rotate then
			if myDebug then WARN('	rotating') end
	    	-- Rotate the radar cone if a bone is provided
	    	self.Trash:Add(CreateRotator(self.Owner, self.Bone, 'y', nil, 0, 999, 36))
	    end

	end
end,

EnableRadarCone = function(self)
	if myDebug then WARN('EnableRadarCone') end	
	if not self.RadarConeActive and table.getn(self.RadarConeEntitiesTable) > 0  then
		if myDebug then WARN('	Radar cone not active, turning them on') end
   		for k, v in self.RadarConeEntitiesTable do		
			self:EnableIntel({self.RadarConeEntitiesTable[k]})
		end
		self.RadarConeActive = true
	end
end,

DisableRadarCone = function(self)
	if myDebug then WARN('DisableRadarCone') end
	if self.RadarConeActive and table.getn(self.RadarConeEntitiesTable) > 0 then
		if myDebug then WARN('	Radar cone active, turning them off') end		
   		for k, v in self.RadarConeEntitiesTable do		
			self:DisableIntel({self.RadarConeEntitiesTable[k]})
		end
		self.RadarConeActive = false
	end
end,

But keep running into the issue where it says its expecting a string instead of a table. Which makes no sense when the data in the "RadarConeEntitiesTable" , are just other tables of entities I've just created.

Error Log...

WARNING: Error running OnStopBeingBuilt script in Entity uel0101 at 15ec6c08: string expected but got table
         stack traceback:
         	[C]: in function `EnableIntel'
         	...faforever\gamedata\lua.nx2\lua\defaultcomponents.lua(1057): in function `EnableRadarCone'
         	...faforever\gamedata\lua.nx2\lua\defaultcomponents.lua(1041): in function `InitializeRadarCone'
         	...faforever\gamedata\lua.nx2\lua\defaultcomponents.lua(1189): in function `EnableUnitIntel'
         	...faforever\gamedata\lua.nx2\lua\defaultcomponents.lua(959): in function `OnStopBeingBuilt'
         	...gramdata\faforever\gamedata\lua.nx2\lua\sim\unit.lua(2329): in function <...gramdata\faforever\gamedata\lua.nx2\lua\sim\unit.lua:2316>
         	...orever\gamedata\lua.nx2\lua\sim\units\mobileunit.lua(123): in function <...orever\gamedata\lua.nx2\lua\sim\units\mobileunit.lua:122>
         	...data\lua.nx2\lua\sim\units\uef\tconstructionunit.lua(43): in function <...data\lua.nx2\lua\sim\units\uef\tconstructionunit.lua:42>

Which is pointing to...

EnableRadarCone = function(self)
	if myDebug then WARN('EnableRadarCone') end	
	if not self.RadarConeActive and table.getn(self.RadarConeEntitiesTable) > 0  then
		if myDebug then WARN('	Radar cone not active, turning them on') end
   		for k, v in self.RadarConeEntitiesTable do		
			self:EnableIntel({self.RadarConeEntitiesTable[k]})
		end
		self.RadarConeActive = true
	end
end,

Something in the For-Do is not liking the table or how its being presented here. Gone through about a dozen variations of this with the exact same error each time. The table i know for a fact is populated with my entity data, as i can run table.getn and see the exact number of entities within it.

Anyone see something I'm missing before i drink myself to death ?

Cheers!

Resin

Got the shield info to display, but dam it displays for everything, when it should only display when the drone-shield is active. the problem is becoming a circular one.... I need info from the sim to activate or deactivate an ability but i can't. Not without using a sim.sync.

Notice that the unit is showing a shield stat, without it having a shield on it...

Sure I can pass the data to the units blueprint, but there isn't any way that i can figure to tell the UI that the shield is active or not.

Question: Isn't the shield data already in Sync somewhere ?

Half way there! Here is the Blueprint.lua script to merge the data that i needed...

##########################################################################################
## --Add drone shield max health into unit bp so UI can use it
##########################################################################################

function Custom_Drone_MaxHealth_Blueprint(bp)
	if not bp then return end
	local id = bp.BlueprintId
	local bpDefense = original_blueprints.defense[id]
	
	-- Check to see if the gUnit has a Cloak, BuildRate or Economy, if so return false
	if bp.Intel.Cloak or bp.Defense.Shield.ShieldMaxHealth > 0 or bp.Enhancements.Shield or bp.Economy.MaintenanceConsumptionPerSecondEnergy then
		return false				
	end
	
	-- Unit Categories to exclude
	local excludedCats = {
		-- Primary unit retrictions, basicly anything that build, upgrades or makes ammo
		'COMMAND','SUBCOMMANDER','ENGINEER','OMNI','FACTORY','ECONOMIC','SILO',
		-- Custom unit restrictions
		'DRONE','MINE','PHASING','TRANSFORMABLE',
		-- Misc unit restrictions
		'POD','SATELLITE','UNTARGETABLE','SHIELD','WALL','PROJECTILE','OPERATION','CIVILIAN','INSIGNIFICANTUNIT','UNSELECTABLE','BENIGN','PROP',
	}
	local cats = bp.Categories
	for k, v in excludedCats do
		if table.find(cats, v) then
			return false
		end
	end

	-- Calc the drone shield max health based on the unit cat
	local droneShieldHealth = bp.Defense.MaxHealth
	if table.find(bp.Categories ,'EXPERIMENTAL') then
		droneShieldHealth = 10000
	elseif table.find(bp.Categories ,'TECH3') then
		droneShieldHealth = droneShieldHealth * 0.3
	elseif table.find(bp.Categories ,'TECH2') then
		droneShieldHealth = droneShieldHealth * 0.5
	else
		droneShieldHealth = droneShieldHealth * 0.75
	end
	
	WARN('Custom_Drone_MaxHealth_Blueprint for unit ID: ', bp.General.UnitName or 'no unit name found')
	
	local unitBp = table.deepcopy(bp.Defense)
	if unitBp then
		unitBp.Merge = true
		unitBp.DroneShieldMaxHealth = droneShieldHealth
		bp.Defense = unitBp		
	end		
end

Repr of a units "self"... Look for the "Defense" and then "DroneShieldMaxHealth"...

WARNING:  - Defense: table: 11FB39D8
WARNING:  -    AirThreatLevel: 0
WARNING:  -    ArmorType: Normal
WARNING:  -    DroneShieldMaxHealth: 235.5
WARNING:  -    EconomyThreatLevel: 0
WARNING:  -    Health: 314
WARNING:  -    MaxHealth: 314
WARNING:  -    Merge: true
WARNING:  -    PersonalShieldThreat: 0
WARNING:  -    RegenRate: 0
WARNING:  -    Shield: table: 11FB36B8
WARNING:  -       RegenAssistMult: 1
WARNING:  -       ShieldSize: 0
WARNING:  -    SubThreatLevel: 0
WARNING:  -    SurfaceThreatLevel: 13
WARNING:  -    UnknownWeaponThreat: 0
WARNING:  - Description: Heavy Tank
WARNING:  - DesiredShooterCap: 3

@jip I'm down with that... I only need the shields:GetMaxHealth() to be passed to be able to update the UI. Otherwise, the drone custom p-shield, would never be able to display without hijacking the SIM in some game breaking way.

Edit: Just rubbed two neurons together and made coherent thought.

Some smart guy, could during the game startup, use blueprint.lua to go through the units that would be drone shield capable. Then assign, what the max shield value would be as a hard value. This is effect would allow me to pass the MaxShieldHealth into the blueprint to be later used by the UI !

@evildrew don't need that many projects as each projectile would have a piece of the intel pie.

So for 360 coverage, the cheap and easy way would be to 8 projectiles, each taking a 45 degree swath. (8×45=360) Keep in mind that as the projectiles travel away from the parent unit, you'd see large gaps within the sonar coverage if the intel radius was not being increased as the projectile traveled outwards.

I've been using the following formula to spread out the radar entities, to make the nice cone...

local angle = math.ceil(counter / 3.14)

But for the sonar, it would be more like this...

local intRadius = math.ceil(distanceTraveled/ 3.14)

The intRadius would then be used to change th projectiles sonar radius. The whole thing would update every couple of game ticks, by first checking the distance traveled from the point of origin, then doing the simple formula above, before updating the sonar range.

Easy as 3.14

Resin

@blackrobe sad thing is that doing so, would break the UI ban on using SIM data. It's why UI mods are allowed in ranked matches, and why most sim-side mods are not. Being able to bridge that gap would enable rampant cheating and a huge amount of desyncs.

@evildrew I made the initial scripts for this 10 years ago, but never finished it. Now, I'm attempting to recreate it with a few new tricks I've learned ad I'm figuring out how FAF handles intel. If you didn't know, FAF rewrote a fair bit of the intel script. Though I've still yet to pull it apart to know just how I can hook-on my changes.

Anyways... The concept is very simple. Just adding an intel type to a custom projectile. Then, making it so the projectile wouldn't hit anything but land. The parent unit of the projectile, and it's army (team) own the viewing rights to the intel discovered.