List what you want to see that map making wiki turn into

[enetheru]

imo it can be moved over, I have been reading the pages as they were being made and seems quite good.

Only pages that are not so good are imo:
http://springrts.com/wiki/Mapdev:Tutorial_Simple
http://springrts.com/wiki/Mapdev:features (yes i see it is just outline)
because they are a bit too much about blueprint and featureplacer thing.

Instead of .smd file one can now use .lua but does not mean in beginner map there must be all these extra files and options like inverting heightmap, snow etc.
I think all that is needed is mapinfo.lua with very few entries, less confusing than blueprint with all its extras.

I think that may be an issue with the blueprint itself, simplifying it and providing clear information on how to extend it with map options I think would be the best solution.

perhaps by commenting out the map options etc.. what do you think?

Similiar with the features:
There was this featuremap bitmap thing but since the inventation of Spring.CreateFeature you can make scripts to put features on the map.
"FeaturePlacer" is one such script, but not only one:
All features on a map are listed in the set.lua and http://springrts.com/wiki/Mapdev:set.lua
is something specifique to FeaturePlacer.
Some mods/maps use it, some use their own thing, there is no "spring wide" standard.

I have no information available to me other than using the pixels on an image method, care to link me to some information? I find the directory structure for feature placer a little convoluted and wouldn't mind a simpler solution.

[Forboding Angel]

Feature placer allows you to place features on a map and then output those features names and their positions which you then copy and paste into set.lua That's it.

I'm not sure how you can find it's directory structure confusing when it has none.

set.lua is the standard.

[enetheru]

I'm not sure how you can find it's directory structure confusing when it has none.

the location and name:
./mapconfig/featureplacer/set.lua

The placement under mapconfig and featureplacer are the confusing parts, and by confusing I mean that it seems like it could be simpler. Like say ./features.lua or ./features/set.lua or ./mapconfig/featureset.lua

the added directory for featureplacer has the connotation that its for a specific tool, which i guess is true..

regardless, none of this really matters, i'm quite happy with the fact that it works, and is useful. I dont know enough about scripts yet to have a strong opinion.so i really should just avoid discussing it. but alas i'm hyped up on coffee atm and its fun YAY!!

[Forboding Angel]

Featureplacer was around before blueprint. Featureplacer had that structure so that you could have different feature sets based upon map conditions. For example, if snowy, you could have a snow feature set, or if no water, a certain featureset, or if foggy... etc etc etc

Blueprint by default supports only one set of features, but it was featureplacer that established that standard, and blueprint incorporated it.

In other news, I have separated featureplacer into it's own module. I'll have the svn up a bit later on. Gotta bug det to set it up on rapid for me.

[Forboding Angel]

https://code.google.com/p/feature-placer/

[knorke]

I have no information available to me other than using the pixels on an image method, care to link me to some information?

well basically it always comes down to calling Spring.CreateFeature (featurename, coordinates) in some way.
For that it does not nessecarily need FeaturePlacer. Every modder/mapper can make it own spawn script thing and some have done/do.
If you want something simple, one way is just to make a simple one-liner script. For example see the map duke nukem: http://zero-k.info/Maps/Detail/24233
If you just want some statue in middle of map, that is the easiest way to do it.

Another map that uses Lua but not FeaturePlacer to spawn stuff:
http://springfiles.com/spring/spring-maps/wakka-wakka
There are more examples but you get the idea..

One might also want to think if you want the spawn script, its configfiles and the actual features in the map or in the mod.
Depends on what one has planned etc, there are many ways to do it.

set.lua is the standard.

Maybe in your mod.

[FLOZi]

Imo 'standards' should always be explicitly labelled as de jure or de facto, with a link to the wikipedia article.

e.g.
http://springrts.com/wiki/Resources.lua#Automatic

[Anarchid]

I would totally love the enetheru blender-workflow in dat wiki.

[Funkencool]

Maybe in your mod.

I do believe feature placer is all in the map and depends not at all on the mod. So if you consider the blueprint the standard ssmf map archive (which it should since nothing else is, right?) then yes it is also standard.

I do get your point, and I believe beherith has his own feature spawner written up for his maps; but something should be standard and blueprint is the best option. Not to say that other options shouldn't be described somewhere in the wiki. But that's all lua magic that a beginning mapper most likely doesn't want to touch. Why write their own feature spawner script when there is a blueprint with everything laid out already PLUS a mod made specifically for placing features in that format.

[enetheru]

I would totally love the enetheru blender-workflow in dat wiki.

yeah I was going to put it under the howto, or on a separate page for tools, just wasn't sure how to include I yet so I haven't. Glad you like it though :D

[enetheru]

well basically it always comes down to calling Spring.CreateFeature (featurename, coordinates) in some way.

Thanks, this is exactly the information I needed :)

I think I need to make some more maps before I continue writing too much wiki stuff, as it will effect positively the quality of information. time to complete charlie in the hills that I've been working on.

[Forboding Angel]

Beherith's feature spawner, is feeding the set.lua that featureplacer outputs into the compiler, so that the feature names and positions are hard coded into the smf.

It still uses featureplacer, it still uses set.lua, and it's bad because it cannot be changed without re-compiling. Me and behe have had some PMs on the subject, and he agreed that noobs should be taught to do it the right way, but he uses that because it's just the way he does it. That that is fine. But don't go teaching noobs to compile feature lists directly into the smf.

set.lua is the standard.

Maybe in your mod.

See, here's where you fuck up. FP has nothing to do with Evo. In fact, if you were to read the code, you would find that it completely supplants evo when fp mode is activated. I have now abstracted it from evo and made it it's own thing.

Smoth told me almost a year ago that he would do it, and at this point I feel that it has been long enough that I can do it and not need to feel like I'm doing a dick move or anything.

Requiring evo was never part of the plan, it just sort of happened that way because it was already set up in evo and gundam went tits up. That and everyone else was too lazy to bother with it.

[knorke]

set.lua is the standard.

Maybe in your mod.

See, here's where you fuck up. FP has nothing to do with Evo.

I change my wording:
Maybe it is standard in your mod/maps/work.
Same difference...

But don't go teaching noobs to compile feature lists directly into the smf.

That is out of the question and I never did that?
See the examples I linked..

Why write their own feature spawner script

Because it is not that complicated actually.
See the dukenukem map:
Spring.CreateFeature ("duke_statue", mapWidth/2, mapHeight/2)
That is all it takes to put the statue onto the map.
If you can use FeaturePlacer you can make such "scary Lua magic"

Some games (Conflict Terra, Spring Tanks) have slightly different ways of spawning stuff because why not!
P.U.R.E. (some now dead mod) had something similiar to FeaturePlacer, iirc it was called "World Builder."
gajop is another guy making such editor: http://www.youtube.com/watch?v=aG3n5DtoaL8

So there can be many such feature placers, none is more standard than any other.

Anyway, if you want to make a map without .smd all you need is a mapinfo.lua with this:

Code: Select all

local mapinfo = {
   name        = "MyMap",
   shortname   = "",
   description = "",
   author      = "",
   version     = "",
   modtype     = 3, --// 1=primary, 0=hidden, 3=map
,

All the other files and thing in blueprint are optional for snow, fog and such things...

tl;dr
I think it is somewhat important to keep difference about what is engine and what is mod or map specifique.

[Funkencool]

The blueprints there, why not use it. Some people including smoth already went through the trouble of writing a feature spawner. If someone was so inclined to write there own that info should be in the wiki, but not in a basic walkthrough.

FP is two parts the place and the spawner. Any placer including the ones you listed can be used.

The spawner in the blueprint reads set.lua .

local setcfg = {
unitlist = {
},
buildinglist = {
},
objectlist = {
{ name = 'geovent', x = 800, z = 4050, rot = "0" },
},
}
return setcfg

It's as easy as adding that line to set.lua, which can be output from one of the many feature placers. And if its only one feature and you don't use a feature place its still easier than writing a gadget.

If you expect a beginner to be able to write basic lua, they should be more then capable of deleting unnecessary lua in the blueprint anyway.

[Forboding Angel]

Knorke, you act like blueprint is unnecessary due to the fact that it allows for fog,rain,snow,etc. You do realize that those are just addins right? And that they don't actually have any affect on blueprint at all. Hell, in my maps, I remove them.

Blueprint allows for map values to be set in lua, so there is never any need to recompile. It also allows for normal maps, parallax maps, specular maps, and detail texture splatting.

Adding the lua mex spot gadget that google frog wrote allows you to place mex spots with lua as well.

[knorke]

Knorke, you act like blueprint is unnecessary due to the fact that it allows for fog,rain,snow,etc. You do realize that those are just addins right?

Yes, that is what I have been saying.
For tutorial it is better to include as little "optional addins" as possible.
FP is optional, too. Saying things specifique to some addin "is the default" is just wrong, which was my point originally. No idea what there is to talk about.

[enetheru]

Knorke, you act like blueprint is unnecessary due to the fact that it allows for fog,rain,snow,etc. You do realize that those are just addins right?

Yes, that is what I have been saying.
For tutorial it is better to include as little "optional addins" as possible.
FP is optional, too. Saying things specifique to some addin "is the default" is just wrong, which was my point originally. No idea what there is to talk about.

there isn't anything to talk about unless:
* someone is willing to put in the leg work to change the blueprint so it doesnt specifically include the featureplacer scripts
* feature placer,toolbox, etc etc agree on a format and location of a set.lua like file
* someone updates the wiki documentation to reflect this.

blueprint is the best way to get people started with a good map, it can sure use tweaking, and i would totally encourage that.

I also think that the fact that blueprint includes these addins is a good thing, it shows a working example of what's possible, but i also think they should be commented out.. only way i would like the addins to be removed is if there was clear documentation on how to add them if you like.. and that doesn't exist yet(hint).

i would like the blueprint to be so amazingly feature complete(but commented out) that you download it, uncomment the addins you like(snow,sand,rain,etc,etc) extend it with copy pasta from wiki documents. etc..

because text doesn't cost much, you can have hundreds of scripts, thousands of lines of lua and it impacts minimally on file size..all nicely written and easy to understand.. it becomes both an example and tutorial all of its own..

Time for bed. yawn

[Forboding Angel]

If you don't want them, simply delete the gadgets. It's not rocket science.