BA on previously EvoRTS ONLY map, "General Caiaphas' Revenge"




http://springfiles.com/spring/tools/spring-features

This is an archive containing all of the features made for spring to date (500+). Games/mods can add this archive as a dependency and map authors can then use featureplacer in Gundam RTS/Evolution RTS/Other to place features. Mapconv already has support for featureplacer configs.

Adding this archive as a dependency also enables that game/mod to use maps that were previously limited to specific games. For example, many of the EvoRTS maps. (I.E. General Caiaphas' Revenge - Attached screenshot)

This also allows for map sizes to be smaller as there is no longer any need to include the textures with the map.

Additionally, maps may also call this archive as a dependency. Maps can also include the featuredef files if necessary so that reclaim and blocking values can be changed. The featuredefs included are simply fallbacks so that the features will show up, and most reclaim values are really low (like 10 energy, 10 metal, etc).

Basically, the point is that mappers can change the features up however they like with this archive.

Have fun!

If you need a tutorial on how to use featureplacer, Don't hesitate to ask me in the lobby and I'll walk you through it!

Examples of proper dependency usage:

Game calling this archive as dependency:


Map calling this archive as a dependency:



Example map using this archive: http://springfiles.com/spring/spring-ma ... s-division

This project now has it's own svn, located here: http://code.google.com/p/spring-features/

Let me know if you would like commit access.

Nice Job Angel So now will be so mutch easy to add features into maps
without needing super pixeling on photoshop, Hope someone make a tool identical of that Feature Placer, but changing height, metal and textures inmap, theres no best way to make a map being on real game

well, actually, if you USE featureplacer for your map, you can change much of that stuff just by editing a lua file. Basically the advantage is that you only have to compile the map once. You can't edit the heightmap via it, but not having to recompile it is a godsend.

imo its better to rely on the internal name, not the filename:

the depend should be something like this:
depend = {
"Spring Features 1.0",
},

Agreed. I tried that, but apparently it's name + version. I didn't realize that.

What happens when someone releases some new features?

I make a new archive with same filename and different version.

This way (and actually this is why I used filename instead of name/version) ther eis only ever one archive file. It may be different versions but it won't matter. If new map depends on newer version the lobby will dl the newer version.

A better implementation would be inclusion in the spring installer updated every spring release, or some sort of rapid implementation using an svn, but my original intent will work pretty well.

Also, seriously, when is the last time anyone released new features? 6 Months ago? I doubt any updating would need to happen for some time.

Odds are I will update it when I get around to feature placer.

Sounds good to me smoth, and if in the meantime someone comes up with a better updating solution I'm all for it.

did you grab the ones from the grts svn or you had the old stuff? because IIRC I did do a few tweaks to the harbor set.

Should have the latest of the models and textures (you might double check just for the heck of it). Defs don't really matter as they can be replaced by whatever is utilizing it.

I don't really have time to double check it

Just to ease updating perhaps if you had another pack that relies on this pack and future packs

metapack1.1 relies on pack1
metapack1.2 relies on pack1 and pack2
metapack1.3 relies on pack1 and pack2 and pack3
metapack1.4 relies on pack1 and pack2 and pack3.1 (glitch in pack 3)

then my map relies on metapack1.1 so I don't have to update my map when pack2 comes out

Yes sinbad, that is doable. It's a little messy down the line, but doable. Thing is, what I was trying to accomplish is if you had features version 1 as a dependency, then when version 2 comes out it doesn't matter which version the user has because the newer pack has all the older features as well.

None of this is perfect, and the best thing would be if they were included with the engine, but, barring that, we can make it work

the pro of using the name instead of the filename is, that it is rapid compatible (as the rapid file-name would be something like 123f34ab234d..ac3.sdp).

Yeah, but how to cause it to update? I agree with that, but yeah... how to make it update itself?

its the job of the lobby client to get the dependencies. it is usually not a good idea to make old maps use newer versions of a dependency automatically. so old versions will require old versions of the package even if there is a new one. maybe this would not be an issue in the case of this package, if you never change the old content, but if you do not do that, it also means old maps would not profit from using newer versions of this package.
i also see no problem in users having multiple versions of this package at the same time. it is about as big as the average map, of which each user has like 100+, so having to get a new feature pack every 6 months should not kill them.

^^ I hadn't thought of it like that tbh. Plus, I dunno if anyone else understands the silver lining... The simple fact is that you can overwrite any part of this archive at any time you like. In the hierarchy of shit that takes over other shit, this archive is the low point on the tree.

I also don't think that people understand how dependencies work. So lemmie explain it a bit.

Long ago before we had any sort of proper updating, we would use dependencies upon dependencies for updates. AA did this extensively and is prolly the only mod who really used the dependency system to it's full potential. See, in a supportive dependency, it provides content (like springcontent, tacontent or basecontent), however, that content can be overwritten. In this case, by the mod or the map. The map has ultimate authority (meaning whatever is in the map will override what is in the mod, and whatever is in the archive), and the mod gets secondary authority.

This means that if you don't like something that is in the archive and would like to change it, you can include your changes/updates in your mod or map and it will overwrite what is in the archive.

What this means is that the archive plays a purely supportive role and instead of getting in the way, it just paves the road for a smoother ride. It also give brand new mods a chance to do "big boy" stuff without having to do assloads of work for it.

Anyway, hopefully that explained it, and hoijui, I see your point, and tbh it makes perfect sense.

If I were to create an svn for this (so that features wouldn't need me specifically to add them to the archive -- in other words, everyone could add to it, etc) would that be a good idea?

Perhaps on a 3 month release cycle?

I won't.