@maudlin27 true... good idea

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

@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

@sheikah After hours of tinkering... Success! function GetTruncatedNumber02(num, dp) local pwr = math.pow(10, dp) num = math.floor(num * pwr) WARN(' pwr: ', pwr,' num', num,' num / pwr: ', num / pwr) local result = num / pwr local fmtStr = string.format('%%0.%sf',dp) number = string.format(fmtStr, result) return number end Results Math Truncate: 18.3671875 Decimals given, 1, 2, 3 Decimal: 1 pwr: 10 num 183 num / pwr: 18.299999237061 Output one after string filter: 18.3 Decimal: 2 pwr: 100 num 1836 num / pwr: 18.360000610352 Output two after string filter: 18.36 Decimal: 3 pwr: 1000 num 18367 num / pwr: 18.367000579834 Output three after string filter: 18.367 Ended up combining a few methods to get this result. Not sure how it would behave with negative values but thats for tomorrow. (tired) Resin

Made some improvements to the Terrain Camo. It now has a phase out effect before the units takes on the mesh of the nearby trees.

Ok correction.... Performing self:GetNavigator():AbortMove() before the Warp, not afterwards is whats required. Not seen it fail yet but I may need to script in a function to remove it from under the ground, should it get stuck.

@jip Originally i was using... self.CloakEntity = self:ForkThread(CreateCloakedEntity) Uploaded V8 and it will include this unit... URA0206 Cybran Vampire

@resin_smoker said in Economy problem: Or rather I flaw in the game design that has persisted for years. Such that the game can't handle a unit with two economy draws. You're right - it was known from the start too. Extractors have the same problem, and it is why this code exists even in the Steam distribution.

Figured it out... Looks like something wasn't liking my use of BeamExhaustEffectsBag to store the emitters used for the afterburner effects. Dropping the Bag for locals, solved the issue completely.

@resin_smoker The ones I'm aware of for weapons are :GetCurrentTarget() - returns the unit, if there is a unit being targeted :GetCurrentTargetPos() - returns the target, i.e. for ground attack targets (I've not tested to see all the cases in which this triggers, e.g. if it will return a value for a unit target's position) :WeaponHasTarget() - I've not used this one myself but I'd noted it down for reference when I was looking at how to get weapon target information with weapons being cycled through with something like: for iWeapon, oWeapon in oUnit.WeaponInstances do if oWeapon.GetCurrentTarget then local oCurTarget = oWeapon:GetCurrentTarget() if oCurTarget then ‘Have a target for the weapon end end end You can also use the Navigator object to get the current target position of a unit, e.g.: oUnit:GetNavigator():GetCurrentTargetPos() - This isn’t just a move order target – e.g. if the unit is building something, it returns the target of that building I found it unreliable, and made a note when I tested that with attack-move orders although I’ve not tested it extensively to confirm, it appeared that giving an attack-move order to a unit that caused that unit to then stop and attack a target, would result in the navigator position being that unit’s position. There's also a :GetGoalPos() function (which I think is based off the navigator as well) You can also use oUnit:GetFocusUnit() (which works e.g. in the case of a building a unit, I've not checked if it also works in the case of an attack order) Another one is oUnit:GetGuardedUnit() I've not tested this one but presume it works with the guard order. My rough notes on these and other commands are in section 5 of the AI development guide (linked to from the FAF wiki https://wiki.faforever.com/en/Development/AI/AI-Modding) although I don't think they'll add much more than what's here, other than you can look at e.g. unit.lua in the FAF Git as various comments have been added documenting functions available for units (and similarly with other files) which might provide further alternatives. You could also look into oUnit:GetCommandQueue() and analysing this - there might be documentation on this in the FAF repo as from memory some of the devs were able to figure out how to interpret the results of this (but it's not something I needed to look into beyond checking if a unit's command queue was empty as for my AI I track the orders given to each AI unit anyway which I rely on)

@jip Sweet, thank you!

@noble_ice 4DFAF or just look up the mod by author name Resin_Smoker or resin. Choose the mod date thats most recent, 24 June 2024.

The reason I was asking is because ideally, when you're done with your current goals, it would turn into something such as this: https://github.com/FAForever/fa-total-mayhem Specifically the license here is what matters. It does not have to be MIT, but at least permissive enough to allow the community to (help) maintain the mod when you decide to move on again. At the moment we have some struggles with various well known mod packs - we can't make certain game changes because it would break them. And as we are unable to contact the authors we can also not get the permission and/or a license to setup a Github repository and maintain them. As a result we did not make those game changes. We're lucky that you got back here and started contributing again with your mod. We have much trouble contacting the original authors simply because all we usually have is a nickname and there's no way to verify that a person with a similar nickname is the original author. Which makes it all difficult

@Jip Thanks m8! Here's the progress on the unit in question: https://youtu.be/nk8EvZLw7JE Units transition from Air to Land (and back) should appear fairly seamless. Only thing I've not been able to do is have the unit auto-selected, if it was previously selected before the transformation. DMS had a few handy functions for this that I've not been able to figure out thus far. Side note: I've been playing around with the idea (again) of having the Flying-walker just be an air unit. Then just manipulating the flight parameters to fake it walking. While I know this is possible, i do recall there being the issue where the air unit would tumble over the ground from playing bumper cars with the terrain. While also being able to scale shear cliffs in a very unorthodox fashion. Simply put, the pathing for air units is pretty much direct, while the land / sea units have to "think" their way around obstacles. This was fun back in the day when we were 1st messing around with the hologram units, while attempting to come up with ways to limit the overhead from the unit pathing.

It's working...

Uploaded the files to the Client for those that would like to see how it works. [image: 1718624220715-f8cf0d3d-b6c6-4d18-9da4-0a4a7ee0e877-image.png]

Added a copy of this unit to the FAF server unit the name "4D-FAF (4th-Dimension for FAF), UEF & Seraphim Units".