Advanced Intel (Work in Progress)

Resin_Smoker

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.

Resin_Smoker

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 ?

Resin_Smoker

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

Resin_Smoker

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.

Resin_Smoker

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

Ctrl-K

So familiar bro, so familiar...

Resin_Smoker

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

snoog

Haven't had a chance to test it yet but I still want to

Evildrew

My understanding is that you are creating kind of a lighthouse-like rotating vision feature. I think you have proven it is doable I just am not that enthusiastic about it and don’t see how it’s fits supcom. It’s something I am familiar with from commandos or the men of war series where eye sight focus makes a lot of sense. Maybe others like it though so just giving my opinion, not discouraging you in anyway. I am just thinking people will say it’s great because your implementation is flawless but then they will complain that their unit’s vision was off while their opponent's vision was on their unit at a key point and that would be contrary to the skill expression dogma…
Anyway the sonar idea you outlined I thought was really valuable.
I also have some ideas I was thinking about implementing that would be great but it’s like asking people who live in a circular loop to try something outside their perception. Lots of people just don’t care what you do until it’s in fashion.

Jip

@resin_smoker said in Advanced Intel (Work in Progress):

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

FAForever is slow, unrelated whether you (eventually) receive feedback or not.

I was also interested to see how you do this. And it's nice to see you use the IntelComponent. It appears you overwrite the definition however, what type of places did you hook / would you like to have access to in a mod?

Ran a game. Spawned in 150 scouts. Apparently scouts with the adjusted intel are fairly expensive. For example the memory usage jump when spawning in the 150 scouts:

DEBUG: Session time: 00:01:01	Game time: 00:00:29	Heap: 288.0M / 250.3M
DEBUG: Session time: 00:01:11	Game time: 00:00:39	Heap: 320.0M / 292.4M

And the sim time is between 6 to 8 ms (on a 7950x3d cpu), where as usually that is below 1ms for this number of scouts. Visually there's also this issue:

The fractured black lines. It's because of how the engine works - vision is additive and the little black lines represent the places where it switches from 255 instances back to 0 since they are bytes on the GPU. This can always happen, but with additional vision entities it will happen much more often.

You can of course reduce the number of entities to reduce these problems. In general I think it is interesting. But if you like games that do not slow down then I'd be very careful - it adds a lot of overhead regardless of what you do. Personally I also think that it adds complexity to the game that it doesn't need to. Or, as Evildrew phrases it:

@evildrew said in Advanced Intel (Work in Progress):

I am just thinking people will say it’s great because your implementation is flawless but then they will complain that their unit’s vision was off while their opponent's vision was on their unit at a key point and that would be contrary to the skill expression dogma…

Having your units rotated properly to manage your vision is, in my humble opinion, not what Supreme Commander was made for. Its complexity lies in the number of units. Not in individual units (except for maybe experimental units) being complicated to manage.

That people then complain because their Snoop got bumped in by another (allied) unit and therefore starts to rotate is not the players fault , the engine should instead try to preserve the rotation. But it does not do that at the moment. The same applies to units that walk in formation, there's is no guarantee that the unit ends up at the intended location. And there's no guarantee that it has a specific orientation. The game was simply not designed for it. And with this type of setup you force the player to fight the engine. That is fine, but it's natural that players can like the concept but not the implementation.

And feature wise: air-based scouts should probably lose the cone when they land and re-gain the cone when they taking off. Just like they now have reduced vision when landed.

Resin_Smoker

@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.

maudlin27

A variation which I suspect would mitigate some of the concerns would be to only apply this to radar and sonar structures, and then limit the radar and sonar in other units to not exceed that of a mobile land scout. You could probably also buff the radar structure range a bit to compensate.

That way you still get the more realistic style intel without much of the overhead.

Resin_Smoker

@maudlin27 true... good idea