New map format

[PauloMorfeo]

... thats just a silly thing to say about a project in development.

I supose you are refering to what i said the other dude said... Yes, it is rather silly. But still, those guys opinions could be very valuable (i hope, of course).

...
Actually I can't mod for Spring because the unit format is too different and none of my units work. NONE!! The bulldozer blew itslef up, the Bridodon skipped some part of the script, like the endless while in the aiming and that made the menu very hard to use, and then just did unexplainable things like rising in the air, the Space Slug and the RobotechUnit weren't even appearing in the buildmenu, etc...
...

Well, i was thinking that you could go to that forum, lost in time and memory to me, where probably there are at least some old TA modder veterans, and tell them that the team is going to add these new features and formats and asking them to come here and give they're opinion on what would be the most important aditions a new format could have...

[Buggi]

Well SJ updated the CVS with new fixes including information on the new format. Interesting stuff.

-Buggi

[PauloMorfeo]

In the mean time, i remembered this... (don't know if it has already been discussed)

It would be nice if the map maker could determine start locations for teams. Like defining that start position 1 and 2, belong to team 2.1 (2, meaning teams of 2) and that pos 3 and 4 belong to team 2.2 . Also, that start pos 1, 2 and 3, belong to team 3.1 (3, meaning teams of 3) and pos 4 belongs to team 3.2 (In this case, it would be playing a team of 3 vs 1).

So we could just start with random positions even when playing teams. Choosing in game, is a very messy and legthy process. (also, people can take advantage of choosing in game...)

[Warlord Zsinj]

The commander warp function from the TA Demo Recorder fixed this issue, but I suppose a more intuitive system like the one you suggested is less open to abuse.

[SJ]

If the lobby just inputed the team numbers in a bit more deterministic way than currently you could use the knowledge of the start positions like in TA with fixed order. Im not sure if we really need to define which start pos goes to which team. It would be better that the lobby could just show numbers in the minimap for where the different start positions are.

[Gabba]

Well, I'd like to have a map of "radar" and "los" dead zones. So basically you can make sections of your map (such as forests) halt radar detection.
As I have suggested earlier, I think that units in forests should also be allowed free cloaking (irrelevant of their ability to do so) in forest areas (and potentially other areas like swamps, etc) when they have been stationary for a certain amount of time. Such a map over the usual bitmap would allow the player to determine zones where units are allowed to cloak, such as forests, etc.

-------------

Another potential suggestion, although somewhat linked to my previous one, is that you could allow Spring to recognise a very basic mapgrid language, rather than preset grids. Then players would be able to use basic inputs to tell Spring what their different heightmap levels do. Perhaps it is a bit hopeful, but it would give map makers enormous flexibility in terms of what they can do.
For example, the same system could be used for players to input weather areas, so that snowstorms will only happen in snow areas, and so on.
Also, players could input areas that adjust unit speed values, so that unit's go full speed (or boosted speed?) on roads, while slower speeds offroad, and much slower taking swamp routes, etc.
Basically, it opens up a number of options, without the SY's having to personally input the ability to do so in Spring. The map maker would just have to create a new 'heightmap' or 'adjustmentmap' (whatever), and then write a short sample of very basic code which the map section of spring recognises and runs.

You have my total support for these ideas WZ. Basically we'd like map makers to be able to:

1/ Add whatever bitmap he wants at map-compiling time, and define in a separate file what it does. Allow these 'adjustmentmaps' to have any effect you can think of on units or features. Maybe to start with allowing them to affect unit speed (roads/mud), health (lava/acid) or stealth/cloak status. Good coders can do the work of adding more effects later if the framework is there.

2/ Allow features to have effects on units (or other features) as well, in a certain radius/in the squares they occupy. A sample effect (which would make WZ happy) would be features affecting cloaking.

[PauloMorfeo]

I remembered a new feature that could be usefull to have in the map description.

The ability for the map maker to define minimal camera height.

In Azure Rampart, there is a big gap between the fortress floor and the water. I supose that zwzsg wanted to make it like that anyway to prevent some things like people going boats or craters getting filled with water.

The problem is that the camera bounces alot. When we are on top of the fortress, the camera height is relative to the fortress, when over water, the height is relative to the water and drops...

Maybe in the map, there could be the possibility to define that the camera should never go below a certain height. Or that the height to which it refers should be always the same x.

[Warlord Zsinj]

Gabba, I believe this was pretty much implemented, except that now we need to actually go out and code the weather effects, terrain effects, radar dead zones and ambush/camoflage zones.

[b1ind]

I was wondering if an additional layer could be added as a sort of movement cost overlay. Say a map maker wanted to have paved roads on their map, it would be neat to have it so that units benefitted from the more suitable terrain. Anyway, this would be a pretty unimportant change.

[Buggi]

I was wondering if an additional layer could be added as a sort of movement cost overlay. Say a map maker wanted to have paved roads on their map, it would be neat to have it so that units benefitted from the more suitable terrain. Anyway, this would be a pretty unimportant change.

This is possible.

I am unsure whether the pathfinding system takes it into account, however.

-Buggi

[Gnomre]

In the NMF you have this crap in the .SMD file:

Code: Select all

[TERRAINTYPE0]			//which terrain type goes where on the map is determined by the typemap
	{
		name=Snow;		//human visible identifier of the terrain type
		hardness=0.75;		//multiplier of the global maphardness value (default value=1)
		tankmovespeed=0.8;	//multiplier of tank units speed after slope mods etc has been applied (default value=1)
		kbotmovespeed=1.1;	//multiplier of kbot units speed after slope mods etc has been applied (default value=1)
		hovermovespeed=1.3;	//multiplier of hover units speed after slope mods etc has been applied (default value=1)
		shipmovespeed=1;	//multiplier of ship units speed after slope mods etc has been applied (default value=1)
	}
	[TERRAINTYPE1]			//which terrain type goes where on the map is determined by the typemap
	{
		name=Rock;		//human visible identifier of the terrain type
		hardness=2;		//multiplier of the global maphardness value (default value=1)
		tankmovespeed=1.2;	//multiplier of tank units speed after slope mods etc has been applied (default value=1)
		kbotmovespeed=1;	//multiplier of kbot units speed after slope mods etc has been applied (default value=1)
		hovermovespeed=1;	//multiplier of hover units speed after slope mods etc has been applied (default value=1)
		shipmovespeed=1;	//multiplier of ship units speed after slope mods etc has been applied (default value=1)
	}

I've used it on Hoth, it works pretty well

[b1ind]

Wow, that is certainly pretty spiffy.

[Warlord Zsinj]

Why on earth would hovercraft be benefited by terrain in order to go more quickly? Surely the most important part of hovercraft is that they are practically impervious to terrain?

[Gnomre]

It's just there because it can be. Easier to include them all in one go rather than waiting for someone to complain to add it in, don't you think?

[PauloMorfeo]

Why on earth would hovercraft be benefited by terrain in order to go more quickly? Surely the most important part of hovercraft is that they are practically impervious to terrain?

Think of hovercrafts moving in a forest and of hovercrafts moving on top of a slipery and smooth surface of snow, ice or water. Do you think hovercrafts will move the same speed?

[Min3mat]

as long as there are no trees in their path the answer should be yes, the only thing that should stop hovers should be a 45 degree or greater slope

[Dragon45]

This is a godsend for a potential space mod that wants to implement planets.

...

No, im not going to do it, so dont ask

Although come to think of it, I do have the units still on me HD, so if anyone wants to make a Terragen space map with planets and make one of the terrainmaps for the planets hamper all hovercraft movement completely... hmm....


Yeah, just contact me, i mbusy doing absolutely nothing >_>

[Warlord Zsinj]

Well, Gnome provides the best answer, I suppose.

The reason why hovercrafts should travel more slowly in forest regions isn't via some sort of modifier (which is starcraft thinking), it should be because there are actual trees in the way which block the hovercraft from travelling (which is TA thinking).

[zwzsg]

I don't see what's wrong in Hovercraft having a terrain speed modifier too. If it really annoys you that much, fine, keep it to 1.

I'm pretty sure hovercrafts don't move at the same speed over smooth ice and over a scree. To me it makes sense that some terrain can affect the speed of the hovercraft.

[AF]

Hovercrafts dont touch the ground therefore the only friction they have is air resistance.

However they are affected whent he ground is irregular, steep angles and wide deep cracks can mess with the orientation, hence why hovercraft are so much more difficult to control.

So really unless terrain is specifically built with antihovercraft devices, there's no reaon for anything other than a 0 or 1.