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

[enetheru]

We have this nice 3d editor to make maps, although the gui is a little to ProFriendly. Time to bundle it with the engine, this has to be there when you download the engine. The editor goes along with every official engine too. So screw the "This is not a game- and has to be lightwight-attitude".

i think it could fall under the category of a developers kit, i would love to make a "game" that does all of that, but i don't yet have the skillset.

Anything to lower the barrier of entry.

[FLOZi]

ToolBox is intended as just such a thing.

Just a shame I have no time to work on it and haven't talked to Car (wubb joo ) in ages. Still gajop is basing his scenario editor on it iirc?

[gajop]

I'm sorta working on it, but I'm kinda too busy right now to do any real work on it. I've mostly been working on merging Toolbox chili with the official one and I've still not done even the initial merge completely...

But hey, it's possible to do most of map editing stuff in-game, already. Here's an example of what I've done concerning map editing stuff: feature adding/moving/rotating/deleting (copy/cut/paste), map height increase/decrease, and it's all supported by a multi level undo/redo mechanism. (Lag is due to recording/nepomuk), my disk sucks :)
http://www.youtube.com/watch?v=loN6wgc_2oY


Now there are a couple of things that are a kind of a problem and a time sink:
1) Editing the texture map. I've tried to do it, and it took me too much time so I gave up on it for now. Pako did something with it, which works more or less but even that was slightly limited iirc.
2) No way to list OS files in lua, so I can't really save a file (normally) to a directory atm. If I use VFS for listing files, I can't save it to a proper path because VFS path != OS path. Can do it blindly but that just sucks.
3) Figure out a decent way to save map information (height map & texture map & any other map (normal map?)).
4) Start toolbox from a GUI for a specific map, change the map size.

[enetheru]

That shit is amazing.

where can i download and test it?
does it have a roadmap, any organised development behind it?

I'm going to be focusing on the wiki still, but when its done this is what i want to work on next, I love tools..

[gajop]

That shit is amazing.

where can i download and test it?

https://github.com/gajop/Toolbox
see the toolbox thread on how to use it.
http://springrts.com/phpbb/viewtopic.ph ... it=toolbox
(The official toolbox doesn't hold any of the stuff I have here, so use my github link)

does it have a roadmap, any organised development behind it?

Nope, I'm the sole developer, and what's worse it's currently in a messy state so I can't accept any commits until I sort that out, eventually.
Also my local repo is 6 commits ahead of what's there so it's probably not stable.
If you want to help, please sort out issue #2, or work on #1 (even if you do it outside of toolbox and/or without chili, I'll try to look into it and see how it could be integrated).

My current (hopefully this year!) goals are to finish merging chili and clean up the project (move files around, split/merge & other maintenance stuff).

[Funkencool]

Yea that's really awesome stuff gajop. Personally I like the way I currently do stuff (mapping wise), but that's the kind of stuff that can only very much help the spring project as a whole.

As far as the wiki goes;
I've been doing my last couple maps almost entirely in GIMP, apart from the final heightmap. For that I use Wilbur since GIMP doesn't currently support 16bit greyscale (but very very soon...) and so they look a little more natural. Unfortunately Wilbur is only for windows. Still everything I do besides compiling can be done directly in GIMP; so, I plan on writing up a guide and maybe even a video going through how I do it. Anyway if that's something you're looking for, to be in the wiki, let me know and I'll try put a little more haste into it.

[enetheru]

Yea that's really awesome stuff gajop. Personally I like the way I currently do stuff (mapping wise), but that's the kind of stuff that can only very much help the spring project as a whole.

As far as the wiki goes;
I've been doing my last couple maps almost entirely in GIMP, apart from the final heightmap. For that I use Wilbur since GIMP doesn't currently support 16bit greyscale (but very very soon...) and so they look a little more natural. Unfortunately Wilbur is only for windows. Still everything I do besides compiling can be done directly in GIMP; so, I plan on writing up a guide and maybe even a video going through how I do it. Anyway if that's something you're looking for, to be in the wiki, let me know and I'll try put a little more haste into it.

haste isn't necessary
If you want to put together some docs on how to use GIMP thats great,!!

can i suggest(and it is just suggestion, do it anyway you feel comfortable) is to make it as atomic as possible, ie short tutorials explaining very specific parts of map making. this will allow us to link to relevant sections in the main pages. ie Mapdev:height has a link to GIMP:height

And I would avoid anything generic and not specifically related to spring, as it would seem a waste of energy.

If you find yourself writing general tips on how to paint a particular thing that could relate to any app then it should be included in the main page for that thing rather than an application specific page.

add these categories to the bottom of each page:
[[Category:GIMP]]
[[Category:Mapdev]]
[[Category:Development]]
and perhaps name them like "GIMP:whatever"

[enetheru]

http://springrts.com/wiki/Mapdev:Main

So if anyone is keen enough, I would appreciate someone to read over the beginners tutorials I've just chucked together. and point out any glaring mistakes or inconsistencies.

Keep in mind they are still primarily, rough drafts, I'm getting closer to finishing blocking out the main content.

[FireStorm_]

It's been very long since I made a spring map so I might be wrong about some things, but here goes:

the Metal Map part could mention that a higher colour intensity is a higher metal value in game.

Also "Metal" (even having mineral resources mined) is mod/game specific. That info could be added since initially it was mentioned it shouldn't be game specific if possible.

Stage 2 is missing skybox stuff (or perhaps that is stage 3)

Lastly: I recall my maps having only a single Detail .png file added in the \maps folder, and that was all. It seems strange to me it described a more extensive to do it. I think a beginners tutorial could also mention the simplest way to do stuff.

In any case, I think it looks great.
nice work.

[enetheru]

It's been very long since I made a spring map so I might be wrong about some things, but here goes:

the Metal Map part could mention that a higher colour intensity is a higher metal value in game.

Also "Metal" (even having mineral resources mined) is mod/game specific. That info could be added since initially it was mentioned it shouldn't be game specific if possible.

excellent thanks. I will add more detail to that part and make it clearer.

Stage 2 is missing skybox stuff (or perhaps that is stage 3)

ive never gotten sky boxes to work under Linux. Little help anyone?

Lastly: I recall my maps having only a single Detail .png file added in the \maps folder, and that was all. It seems strange to me it described a more extensive to do it. I think a beginners tutorial could also mention the simplest way to do stuff.

the blue print takes care of the simple detail map already. This shows how to do ssmf splatting. This info will however be in the tech docs. But thinking about it again encouraging mappers to think about low end hardware is a good idea.

In any case, I think it looks great.
nice work.

i really appreciate the feedback

[knorke]

So if anyone is keen enough, I would appreciate someone to read over the beginners tutorials I've just chucked together. and point out any glaring mistakes or inconsistencies.

well the idea of wiki is that nobody has to comment on an wikipage in forum and then somebody else edits the wiki. Instead everybody can directly edit the wiki.

But right now there are like 3 versions for every page by different people and none is really done.
For example for the mapdev startpage there is the orginal version, Forbs, and yours...the wheel gets re-invented too often.
People say something along the lines of "I did not want to check all the old unfinished stuff, there is so much wrong. It was easier to start from scratch."
And then they make the same mistakes and create something that a few months later others will consider broken unfinished stuff.

Your work on mapdev wiki is probally the best so far but due to above problem you will might stay the single author and when you stop working on it, it dies.

[enetheru]

Hey i understand your view. However i plan on systematically deleting all old docs after migrating the info from them. :) not without making sure the original authors can see that the information is still there and its been assimilated.

Thats something i could already use help with. Its just people arent big on writing docs. So it does end up being one person... I'm fully ok for other people to start editing.

[smoth]

deleting pages and starting new ones deletes history. I would prefer to keep history where possible because things change and I need to know when a feature was dropped or added to keep up.

[enetheru]

People say something along the lines of "I did not want to check all the old unfinished stuff, there is so much wrong. It was easier to start from scratch."
And then they make the same mistakes and create something that a few months later others will consider broken unfinished stuff.

I just wanted to address this, I don't think most people think like that.

For instance, in my case it was a number of factors

• What if I don't get very far, I don't replace what is there with junk.
• This is a fairly extensive shift in structure, not just adding to existing pages.
• I don't want to get shouted down for changing the main page without first showing something valuable

Its very difficult to go through all the old material and improve, when so much is out of date, or unfinished. I am going over them to get every tiny fact to put into the new structure.

Your work on mapdev wiki is probally the best so far but due to above problem you will might stay the single author and when you stop working on it, it dies.

I'm hoping that this new structure will encourage other people to contribute information. Since its not a disruption to add or change anything..

I think the main factor for people not working on the wiki is that when someone gets enthused to work on it there are a bunch of people who shout down the efforts. because the things wrong with the wiki are that its structure does not encourage change, or additions..

I'm hoping that people will add more information to the technical pages as they learn things. that old information will be moved to historical reference, that new tutorials will be added to the howto section, that common problems will be added to the relevant section.. that people feel more comfortable improving on what's there because its made in such a way that it encourages it.

oh and thanks :D I try my best!

deleting pages and starting new ones deletes history. I would prefer to keep history where possible because things change and I need to know when a feature was dropped or added to keep up.

I realise that not all games built on spring use the latest version, I would like input on how best to indicate which version a feature was added, and I agree that historical information should be kept.

[FLOZi]

{{new|version}}

And I fully support all of this wonderful work. Starting from scratch is the best way to deal with the wiki imo.

[smoth]

Flozi: why is it good to lose history?

[FLOZi]

It's not, but the whole 'Don't start from scratch, iterate' argument has been brought out before and got us nowhere.

You can start from scratch and then just paste over the completed page at the end if you want to save history.

However good documentation should keep (a certain amount of) info about previous versions but make clear it is deprecated... Trawling through wiki edits to find that is not the ideal way to present it anyway so imho the point is fairly moot.


I agree with enetheru that a consistent and logical structure will help others to contribute. e.g. Beherith, Picasso and Kloot have all contributed to my defs pages, and having the templates set up etc just makes life much easier to pitch in, rather than the omnishambles "if you know something, anything, just throw it on the wiki with a nonsensical page name no-one will ever find / remember"

[enetheru]

deleting pages and starting new ones deletes history. I would prefer to keep history where possible because things change and I need to know when a feature was dropped or added to keep up.

Please give me some more details as to what you need so I can find the best way to make sure its there.

[smoth]

essentially, stuff for maps have not changed much over the years, there was my map option shit and jk's blueprint. Neither of which is archived. I just get concerned when people delete wiki pages because I may not think of anything significant but once something is gone.. So it is just a caution thing. Map development has been one of the MOST neglected things in the wiki. So I don't really feel there is much lost beyond being able to go "oh yeah, that guy wrote this" at this point IMO.

i was really more interested in the question from a perspective of general wiki policy which is why I was not very adamant about the deleting thing.

[enetheru]

Fair enough, cheers for clarifying. I'm trying my best to make sure information is not lost.