Tab-zoom/supcom view

Das Bruce · Post by **Das Bruce** » 17 Jun 2006, 08:11

What we really need now is the ability to replace units with little icons, and there was something else I but I forgot, anyway. Agree?

Zoombie · Post by **Zoombie** » 17 Jun 2006, 08:23

Agree! Squares for buildings, circles for land units, lines for air units, triangles for navel units and empty squares for navel buildings.

Das Bruce · Post by **Das Bruce** » 17 Jun 2006, 08:40

Zoombie wrote:Agree! Squares for buildings, circles for land units, lines for air units, triangles for navel units and empty squares for navel buildings.

NO NO NO NO NO. MOD DEFINED!

FireCrack · Post by **FireCrack** » 17 Jun 2006, 08:46

Zoombie wrote:Agree! Squares for buildings, circles for land units, lines for air units, triangles for navel units and empty squares for navel buildings.

You dont need diferentiation between land and navy, you can tell the diference by virtue of it being on the sea or not...

smoth · Post by **smoth** » 17 Jun 2006, 08:57

some minimaps are deceiving.

FizWizz · Post by **FizWizz** » 17 Jun 2006, 08:59

Zoombie, quiet. Leave it to people who know what they're talking about. mod-defined ftw, it shouldn't need to be any more complicated than "MapIcon=whatever.bmp;" in the unit file.

Das Bruce · Post by **Das Bruce** » 17 Jun 2006, 09:17

FizWizz wrote:Zoombie, quiet. Leave it to people who know what they're talking about. mod-defined ftw, it shouldn't need to be any more complicated than "MapIcon=whatever.bmp;" in the unit file.

Actually it'd probably be alot easier to stick in / change if it was in its own file. And TGA not BMP, we'll probably need transparencies.

Decimator · Post by **Decimator** » 17 Jun 2006, 14:52

Indeed, and let the modder decide at what zoom level to switch to the icon. That way small units can be made to switch to icons sooner than large units.

Caydr · Post by **Caydr** » 17 Jun 2006, 16:06

TGA < DDS

And it should hopefully be defined in some manner that doesn't involve going through 380 unit files and giving them a pic definition.

There should be a way to define it based on a unit's category. Maybe in a gamedata\uniticons.tdf:

notair=landunit.dds;
vtol=airunit.dds;
notland=waterunit.dds;
commander=commander.dds;

...and so on. Would be much easier to do and would integrate nicely with all existing mods. Also, since JC has a vendetta against new unit tags, this would mean there wouldn't have to be any.

Lord JoNil · Post by **Lord JoNil** » 17 Jun 2006, 16:26

But shouldn├óÔé¼Ôäót certain units like the krogoth have their own image?

Theotherguy · Post by **Theotherguy** » 17 Jun 2006, 16:40

yes. You could do it like homeworld 2, where extremely big units are always visible with a square around them or something and everything else becomes icons.

AF · Post by AF » 17 Jun 2006, 17:37

It should work based on a set of rules, that use a set of 4 or 5 symbols, for which they cna be overriden, and then you cna ahve unit specific tags for exceptions to those rules

colorblind · Post by **colorblind** » 17 Jun 2006, 20:02

Caydr wrote:(...) Maybe in a gamedata\uniticons.tdf:

notair=landunit.dds;
vtol=airunit.dds;
notland=waterunit.dds;
commander=commander.dds;

...and so on. (...)

It could be done like that, but it wouldn't be very flexible. For gamedata\uniticons.tdf: I'm thinking more in the direction of something like

Code: Select all

[UNITICONS]
{
	RelativeBitmapPath=../icons/;
	NumCategories=6;

	[DEFAULT]
	{
		Bitmap=default.dds;
		AdjustToFootprint=0;
		Rotate=1;
	}

	[COMMANDER]
	{
		Bitmap=commander.dds;
		AdjustToFootprint=0;
		Rotate=0;
	}

	[BUILDINGS]
	{
		Bitmap=buildings.dds;
		AdjustToFootprint=1;
		Rotate=0;
	}


	[LAND]
	{
		Bitmap=land.dds;
		AdjustToFootprint=1;
		Rotate=0;
	}

	[AIR]
	{
		Bitmap=air.dds;
		AdjustToFootprint=0;
		Rotate=1;
	}

	[SEA]
	{
		Bitmap=sea.dds;
		AdjustToFootprint=0;
		Rotate=0;
	}

}

AdjustToFootprint would adjust the icon size to the size of the footprint (but perhaps something like AdjustToUnitRadius would be better). Rotate would indicate whether or not the icons should be rotated in the direction of the unit (which is usefull if you have e.g. triangles for airplanes).

You would then need to add a new unit tag to every unit if you don't want it to have the default icon.

But perhaps there are better ways to indicate the icon type for every unit, e.g. via the classes in moveinfo.tdf.

Licho · Post by **Licho** » 17 Jun 2006, 20:59

Yeah, I was planning to make it, but my job has cought me again

Not enough time right now..

Pxtl · Post by **Pxtl** » 17 Jun 2006, 21:17

Caydr wrote:TGA < DDS

And it should hopefully be defined in some manner that doesn't involve going through 380 unit files and giving them a pic definition.

There should be a way to define it based on a unit's category. Maybe in a gamedata\uniticons.tdf:

notair=landunit.dds;
vtol=airunit.dds;
notland=waterunit.dds;
commander=commander.dds;

...and so on. Would be much easier to do and would integrate nicely with all existing mods. Also, since JC has a vendetta against new unit tags, this would mean there wouldn't have to be any.

Really, that needs to be generalized for EVERYTHING. Personally, I think an import/header macro language or something would be ideal. Any tag should be able to be applied to a category or a group of units instead of defined per-tdf file. A c-style #include directive would make doing group-wide changes simple.

My point is: everything should go by per-unit tags, and then include a structure for making per-unit tags easily applied to groups of units. Otherwise you get silly distinctions where you want somethings to be applied to units and others to be applied to groups, when the distinction is artificial.

kujeger · Post by **kujeger** » 17 Jun 2006, 23:31

Having the icon determined by type, overrided by subtype, overrided by subsubtype and so on, with the final autohrity being the unit itself sounds like a good way to do it.

smoth · Post by **smoth** » 18 Jun 2006, 00:09

bruce 32 bit bmp files have an alpha channel.

LOrDo · Post by **LOrDo** » 18 Jun 2006, 21:17

Are we trying to rip off supcom in any way possible? If we keep building parralel to what its doing, people will leave spring when supcom comes out, because it will be just like it but worse. Lets try and get some original ideas eh folks? Not like we arent getting original ideas already but well...lets stay clear of the cheap ripoffs.

Guessmyname · Post by **Guessmyname** » 18 Jun 2006, 21:42

He right! We should move away from SupCom entirely! SupCom is an RTS! We can't be an RTS! That would be copying! Oh noes!

If it's a good idea you're putting yourself at a deliberate disadvantage by not using it yourself.

Exemples:

Ancient Man: hmm. They seem to be rubbing two sticks together to make heat with which to cook their meat. That is a good idea. However, I will not do the same because that would be copying!

Ancient Man later dies from a bacteria in his raw meat that wouldn't have been present if said meat had been cooked

Drone_Fragger · Post by **Drone_Fragger** » 18 Jun 2006, 22:50

Guessmyname wrote:He right! We should move away from SupCom entirely! SupCom is an RTS! We can't be an RTS! That would be copying! Oh noes!

If it's a good idea you're putting yourself at a deliberate disadvantage by not using it yourself.

Exemples:

Ancient Man: hmm. They seem to be rubbing two sticks together to make heat with which to cook their meat. That is a good idea. However, I will not do the same because that would be copying!

Ancient Man later dies from a bacteria in his raw meat that wouldn't have been present if said meat had been cooked

You phail. That was awful. In reality they'd kill eachother, then steal the fire and claim they invented it. It happens all the time in life. Albert einstien, Thomas Edison, the list goes on.

Spring RTS Engine

Tab-zoom/supcom view

Tab-zoom/supcom view