MegaGlest Forum
Modding and game content creation => Maps, tilesets and scenarios => Topic started by: silnarm on 1 March 2010, 08:46:17
-
For discussion of and testing improvements to the map editor.
The 'mega-zombiepirate' map editor can be downloaded here,
https://sourceforge.net/projects/glestae/files/map_editor/1.5/map_editor.7z/download
Has,
* titi's changes to make 8 player maps,
* zombiepirate's gradient brush
* Keyboard commands (see 'cheat sheet' below)
* undo/redo
* from 1.5-beta3 includes a toolbar (with buttons on it!) thanks andy0101.
Want to make an 8 player map ?
When starting a new map, the player count defaults to 4, you also need to 'Reset Players' if you want to make an eight player map.
Cheat Sheet:
Ctrl + O : Open File
Ctrl + S : Save File
Shft + Ctrl + S : Save as
Ctrl + Z : Undo
Ctrl + Y : Redo
H : Switch to Height Brush
G : Switch to Gradient Brush
S : Switch to Surface Brush
O : Switch to Object Brush
R : Switch to Resource Brush
L : Switch to StartLocation Brush
Alt + [1-9] : Sets the Brush Radius
With Height or Gradient Brush activated,
[0-5] : Sets Brush height
Ctrl + [1-5] : Sets brush height (negative)
With Surface Brush activated,
[1-5] : Sets Surface Selected
With Object Brush active,
[1-0] : Sets Object Number (from 1-10)
- : Sets Object = 0 (erase)
With Resource Brush active,
[1-5] : Sets Resource Number
0 : Sets Resource = 0 (erase)
With Start Location Brush active,
[1-8] : Sets Start Location index.
-
A few notes about the Undo/Redo features as well. They're complete as far as terrain/object/surface/resources are concerned but player locations and resets haven't been implemented yet (though it is a quick fix so it should go in soon), player locations get recorded as a blank undo point and resets don't get recorded at all.
If you reset and try to undo, it will revert the last backup point for the object that was placed. ie. if you are editing resources and you reset and undo, your resources will come back but nothing else will unless you undo all the way back to the beginning and then redo up until the point before the reset.
If you are moving players around and then want to undo something that you did before moving players you will need to undo as many times as you moved the players.
EDIT: Quick patch to fix a rather obvious bug that I somehow never noticed. :-[
Index: source/map_editor/map.cpp
===================================================================
--- source/map_editor/map.cpp (revision 499)
+++ source/map_editor/map.cpp (working copy)
@@ -349,7 +349,7 @@
void Map::setObject(int x, int y, int object) {
cells[x][y].object = object;
- cells[x][y].resource = 0;
+ if (object != 0) cells[x][y].resource = 0;
}
void Map::changeResource(int x, int y, int resource, int radius) {
@@ -371,7 +371,7 @@
void Map::setResource(int x, int y, int resource) {
cells[x][y].resource = resource;
- cells[x][y].object = 0;
+ if (resource != 0) cells[x][y].object = 0;
}
void Map::changeStartLocation(int x, int y, int faction) {
-
Download has been updated, same link.
-
silnarm also made the megaglest3.2.4-2-beta4 editor for 8 players here included in the linux/windows binaries of this version:
https://sourceforge.net/projects/megaglest/files/
-
When, during the course of map design, should one choose to use the gradient tool and not the original brush?
Comparing the two brushes when making hills with 4 height/gradient and 5 radius setting. The differences between the two brushes are very subtle and those slight differences in tool character probably won't be noticed by people playing a game on the map - but - we have a new tool and someone will find an interesting use for it.
Everything else is just peachy.
-
I found the linux editor flickering bug, its fixed now in megaglest!!! ( But megaglest sadly has no undo redo patch included yet! )
This was the problem:
http://old.nabble.com/OpenGL,-wxWidgets-and-Ubuntu-7.10-td16047290.html
I added WX_GL_DOUBLEBUFFER to the call .....
//gl canvas
int args[] = {WX_GL_RGBA, WX_GL_DOUBLEBUFFER};
glCanvas = new GlCanvas(this,args);
// =====================================================
// class GlCanvas
// =====================================================
GlCanvas::GlCanvas(MainWindow * mainWindow, int* args):
wxGLCanvas(mainWindow, -1, wxDefaultPosition,wxDefaultSize,0,wxT("GLCanvas"),args)
{
this->mainWindow = mainWindow;
}
update:
I reuploaded megaglest3.2.4-2-beta4_i386_linux_bin.tar.bz2 which contains a fixed editor now .
( I know I shouldn't do such a change/upload without a version change, but well, I did it, its only the editor :P )
How to use it:
Look at the included readme!
Put the editor and the startscript into your glest installation.
Start the editor with the included script "start_editor".
If you get in trouble with missing openal version libs, try this:
ln -s /usr/lib/libopenal.so.1 <PathToGlestInstallation>/lib/libopenal.so.0as mentioned here: https://forum.megaglest.org/index.php?topic=4254.msg24188#msg24188
-
I just committed a few map editor undo/redo fixes to the GAE svn.
* Resets are now backed up.
* Another bug in the object/resource undo is fixed.
* Player location changes don't create a blank undo point. Player location changes are not handled by "undo" since moving the player position can't create permanent damage to the rest of the map.
I have also noticed a few issues with some undo points disappearing when undoing and redoing between different changes. So just remember the undo button is mostly stable, but, once you press it you might not be able to redo it.
When, during the course of map design, should one choose to use the gradient tool and not the original brush?
You would use the gradient tool when you're making more drastic changes in terrain and want smoother transitions between heights. ie. changing terrain from 15 to 5 in a single stroke... If you are looking for it the changes are noticeable in game. But, you are still right, most people probably wouldn't notice a difference.
-
For the colors in the menu....
Here from the official class reference of wxWidget 2.8:
wxMenuItem::SetTextColour
void SetTextColour(const wxColour& colour)
Sets the text colour associated with the menu item (Windows only).
I think we have to wait with the colors in the menus... there is a wxWidget version 2.9 but its only a development version, nothing stable :/.
So we have to wait for wxWidget 3.0 .....
-
Can I add my changes to the GAE editor too?
By this megaglest and GAE would have nearly the same source.
what i changed:
- The above mentioned linux flickering bug
- some strings in the menus, making it more easy to understand whats going on ....
- colors for the starting points.
can I check in this in 0.2.x?
Some more questions about the GAE editor code in general:
Why is map->getMaxPlayers() renamed to map->getMaxFactions() in GAE ???
Why "Factions"? in my opinion this is wrong!
If you ask me, i would change it back! Factions ( in the meaning of glest ) have nothing to do with these starting points!
what is this include good for ( in several files ):
#include "pch.h"
I only get compile errors in megaglest!?
whats the matter with this:
GAE-sytle:
Conversion::strToInt(simpleDialog.getValue("Height"))
glest/megaglest style:
strToInt(simpleDialog.getValue("Height"))
I get compile errors in megaglest whith these "Conversion::"
Why is it needed?
-
can I check in this in 0.2.x?
Yes, i think you can. It's just the map editor and zombiepirate also added some features. There's no freeze for the tools. Can you confirm also flickering of the g3d_viewer and if yes check if the same fix works there too?
what is this include good for ( in several files ):
#include "pch.h"
I only get compile errors in megaglest!?
It's the precompiled header for windows, more specific Visual Studio. Should do nothing on Linux.
whats the matter with this:
GAE-sytle:
Conversion::strToInt(simpleDialog.getValue("Height"))
glest/megaglest style:
strToInt(simpleDialog.getValue("Height"))
I get compile errors in megaglest whith these "Conversion::"
Why is it needed?
The utility functions just got grouped in a class. They are still static, just nicer accessable.
-
Yes, i think you can. It's just the map editor and zombiepirate also added some features. There's no freeze for the tools. Can you confirm also flickering of the g3d_viewer and if yes check if the same fix works there too?
I never compiled or used it, but I will look for it.
....
It's the precompiled header for windows, more specific Visual Studio. Should do nothing on Linux.
But it does something, it doesn't compile in megaglest :/
-
I just commented all includes and it works. It's not really used on linux cause of:
#ifdef USE_PCH
It's not defined in the jam buildsystem, so pch.h is completly empty (after precompiler).
-
Some more questions about the GAE editor code in general:
Why is map->getMaxPlayers() renamed to map->getMaxFactions() in GAE ???
Why "Factions"? in my opinion this is wrong!
If you ask me, i would change it back! Factions ( in the meaning of glest ) have nothing to do with these starting points!
It was changed at rev 212 for this reason...
* Renamed "players" to "factions" everywhere because of the concept (being
introduced in the network branch) that a single player may control more than
one faction.
How are "players" and "factions" used in the rest of the code in both megaglest and GAE? Consistency between the editor and game code should matter a lot more than a small difference between the megaglest and GAE editor code.
EDIT: Is it actually possible for a single player to control more than one faction?
-
* Renamed "players" to "factions" everywhere because of the concept (being
introduced in the network branch) that a single player may control more than
one faction.
But its still wrong , because a faction in the meaning of glest is one "faction" of a techtree! This has nothing to do with what the player controls or the startpoints in the editor! I still think player is the right word. Even in the glest GUI this is called Player everywhere, its never called faction!
I think "Faction" just confuses people who want to get familar with the code
-
New map editor for windows, merges the rest of the stuff from the megaglest editor + a couple of undo/redo fixes from zombiepirate. Same link.
https://sourceforge.net/projects/glestae/files/glestae_snapshots/map_editor/map_editor_win32.7z/download
It was changed at rev 212 for this reason...
I think I'm with Daniel idea on this one. Its already 'Faction' (as in 'player') throughout most of the code, faction and player are used interchangeably.
EDIT: Is it actually possible for a single player to control more than one faction?
Not currently, no.
But its still wrong , because a faction in the meaning of glest is one "faction" of a techtree!
Incorrect, what you described as Faction above is in the code 'FactionType'.
I like the idea of one player being able to control multiple factions, and multiple players being able to control one faction, or of course, multiple players being able to control multiple factions.
I'm in support of 'Player' being replaced by Faction in this sense (and as I mentioned, they are already used interchangeably). So thats how it will be, in GAE anyway ;)
-
No FactionType is not a faction, its something that can hold a faction description!
The Object Faction ( in the code ) is some kind of instance of this FactionType which also contains a Control Type ( Human or CPU ) a starting point and so on. The "Count" of these objects is game setup dependend and the maximum possible faction number is limited by the map. By this MaxFactionCount might be ok, because its the maximum Factions which can play on this map. But its still confusing for me because its called "Player" everywhere else outside the code and thats not very intuitive in my opinion. Whatever if everyone thinks its a good idea I will use it too.
-
Naming convention aside, is there another goal for the next step in development of the editor?
https://forum.megaglest.org/index.php?topic=3958.msg22840#msg22840 (https://forum.megaglest.org/index.php?topic=3958.msg22840#msg22840)
This post was the only real list of legit feature requests I found. The things that most stick out are tileset loading, 3d map rendering and a LUA editor.
-
The new megamaps (5-8 player locations) crash unpatched Glest and GAE clients. If these new maps get mixed in with standard maps people will be crashing the various Glest client builds 2.x.x to 3.2.2 when scrolling the map selection menu during new game setup.
Is it possible to use an extension for 5-8 player maps other than .gbm?
-
If a file extension rename is in order maybe the map format itself could be expanded as well to support future Megaglest/GAE features? Many of the feature requests in the old map editor topic would require a new map format. The current map file loader in Megaglest/GAE could easily be expanded to support a new format even if no new features are supported in the game itself.
-
It would be good to use the version in the map header but I don't think vanilla Glest checks it.
-
Some more changes are in, all 'nice' stuff, to make life easier.
https://sourceforge.net/projects/glestae/files/glestae_snapshots/map_editor/map_editor_win32.7z/download
map_editor 1.5 Cheat Sheet:
Ctrl + O : Open File
Ctrl + S : Save File
Shft + Ctrl + S : Save as
Ctrl + Z : Undo
Ctrl + Y : Redo
H : Switch to Height Brush
G : Switch to Gradient Brush
S : Switch to Surface Brush
O : Switch to Object Brush
R : Switch to Resource Brush
L : Switch to StartLocation Brush
Alt + [1-9] : Sets the Brush Radius
With Height or Gradient Brush activated,
[0-5] : Sets Brush height
Ctrl + [1-5] : Sets brush height (negative)
With Surface Brush activated,
[1-5] : Sets Surface Selected
With Object Brush active,
[1-0] : Sets Object Number (from 1-10)
- : Sets Object = 0 (erase)
With Resource Brush active,
[1-5] : Sets Resource Number
0 : Sets Resource = 0 (erase)
With Start Location Brush active,
[1-8] : Sets Start Location index.
I also added a status bar, which tells you what brush type, 'value' and radius is currently set.
(http://i687.photobucket.com/albums/vv231/silnarm/glest/map_ed_1_5.jpg)
Is it possible to use an extension for 5-8 player maps other than .gbm?
Good idea, a new map format would ultimately be nice, but for now I think maybe we should make the editor use .gbm8 or somesuch for maps with 5-8 player slots.
-
I thought this would be a good idea too, but normal glest crashes even if you rename a 4 player map to gbm8 :/
Due to this fact I wouldnt change anything now!
We must quickly bring stable 8 player versions and the people have to use them ;D
Nevertheless, maybe a naming convention (.gbm8) can help a bit but I think It will not have a big effect :/
( By the way, its a cool looking map, where can we download it? )
-
I thought this would be a good idea too, but normal glest crashes even if you rename a 4 player map to gbm8 :/
Discovered this soon after posting earlier :-X
the gbm still matches somehow, .mgm works fine though :) Mega Maps
Nevertheless, maybe a naming convention (.gbm8) can help a bit but I think It will not have a big effect :/
I've just about finished changing what needs changing in megaglest to handle *.mgm, with your OK, I'll commit soon and build a new beta? (and update the map_editor of course...)
( By the way, its a cool looking map, where can we download it? )
Will post you a link in another topic soon... ;)
-
oh mgm works ? thats good!
Checkin is ok, but please don't make another beta yet, this will confuse everyone! We already have big problem with the non harvesting units ( I think in windows7 only? ) and I want to verify whats that all about!
We still have no fullpackage/installer to get more feedback, thats very sad :( . Hopefully its there very soon!
-
When i tried to make player 5- the whole thing stopped working, or correctly, it did not answer
-
When i tried to make player 5- the whole thing stopped working, or correctly, it did not answer
are you saying the program froze up? or it didn't do anything?
Did you 'reset players' first?
-
im very sorry ( and embarrased :-[) reset players worked thanks
-
Three minor typo's and one new designation.
Object 8-C3, <-comma needs to be removed.
Object 9-[C4] <- is missing.
Object 10-[C4] <- is missing and the underscore under the 10 is offset.
Surface 5-Custom is renamed Ground (titi)
Nifty - props to zombiepirate, silnarm and titi !
-
I thinks thats my fault, I didn't ported the strings to GAE yet. I Think the editor you are using now is the one from GAE.
-
The GAE subversion for the map editor doesn't compile for me at r504. Errors in "main" and "program".
There are others but these are some main ones.
map_editor/main.cpp:189: error: no match for ‘operator+’ in ‘"F\000\000\000i\000\000\000l\000\000\000e\000\000\000 \000\000\000=\000\000\000 \000\000\000\000\000\000" + ((MapEditor::MainWindow*)this)->MapEditor::MainWindow::fileName’
map_editor/main.cpp: In member function ‘void MapEditor::MainWindow::onMenuEditRedo(wxCommandEvent&)’:
map_editor/main.cpp:336: error: no matching function for call to ‘MapEditor::MainWindow::onPaint(wxPaintEvent)’
map_editor/main.cpp:261: note: candidates are: void MapEditor::MainWindow::onPaint(wxPaintEvent&)
map_editor/program.h:79: error: ‘stack’ was not declared in this scope
-
macro expansion problems (at least I hope).
For windoze wxT(x) evaluates to x, which was masking some horrible mistakes I made ;)
I think I've fixed them all now... (still haven't tried on linux though)
-
No, there are some more. I'm fixing them. :)
EDIT: Should be fixed now. Shortcuts for brushs are now disabled because there were problems with the event when calling the callback. I'm atm just too stupid (i dislike references):
map_editor/main.cpp:616: error: no matching function for call to 'MapEditor::MainWindow::onMenuBrushHeight(wxCommandEvent)'
map_editor/main.cpp:489: note: candidates are: void MapEditor::MainWindow::onMenuBrushHeight(wxCommandEvent&)
We should rather post the event than call the callback directly.
-
No, there are some more. I'm fixing them. :)
EDIT: Should be fixed now. Shortcuts for brushs are now disabled because there were problems with the event when calling the callback. I'm atm just too stupid (i dislike references):
map_editor/main.cpp:616: error: no matching function for call to 'MapEditor::MainWindow::onMenuBrushHeight(wxCommandEvent)'
map_editor/main.cpp:489: note: candidates are: void MapEditor::MainWindow::onMenuBrushHeight(wxCommandEvent&)
We should rather post the event than call the callback directly.
Thanks Yggdrasil... the references problem is because I create temporary wxEvents as reference paramaters, gcc doesn't like this, creating them on the stack first, then passing them in is fine, but creating them in the function call is apparently not acceptable.
I knew this, I've had to deal with it before... will clean it up (and maybe even do it on linux :) ) tomorrow.
Edit:
All re-enabled and fixed up.
-
I ported the editor to megaglest too now. Good work, its really nice to handle now!
In GAE/Megaglest I updated the strings Trappin mentioned and I set the player startpoint colors to those known by everyone
red->player1
blue->player2
...
I didn't checked it in in megaglest(editor) yet, I will do this tomorrow
-
I'm currently adding some info support for the editor. When you move the mouse over an object/resource its name is displayed in the statusline.
This feature already works.
The next thing I add is a simple "brush" copy where you get the object/resource brush which is under the mouse by simply hitting the space bar.
I will add these changes to the GAEs editor too and will checkin tomorrow.
update:
It was done quicker than i thought! I already checked in .
@Trappin: I'm quite shure you will love this feature! This speeds up mapping a lot!
-
Very powerful map editor, I am really looking forward to us with this map editor to do out of the new map!
-
See this topic (https://forum.megaglest.org/index.php?topic=2456.0) if you don't know what this is about.
(http://img14.imageshack.us/img14/4320/indexck.png)
This is the new version of map editor buttons.
Changes:
- Rarely used tools are removed. Such include: Open, Save, Reset, Reset Players, Resize, Flip X, Flip Y, Info, Advanced, Reset zoom and pos. They will still be accessible from the textual drop-down menu.
- New tools are added: Undo, Redo, Gradient, Players 5-8.
- All images are now in a single folder. This makes easier to view all the images at once and to batch-convert them. Beggining of the filename indicates what textual drop-down menu do they belong to.
- Some images are modified significantly or only several pixels, while others are the same.
You can download it here: http://dl.dropbox.com/u/2044596/glest/andy0101_buttons_v02.zip
Since I haven't played the GAE Megaglest yet, I don't know what colors are teams 5-8.
Note to whoever wants to implement them in the map editor: don't forget to write tooltips since not all of the images are self-explanatory.
-
I committed some initial work on adding your icons to the map editor. Just added all icons and dumped some of them in two toolbars. I have actually no idea how to lay it out in a good way. I never made any map. So, anyone can feel free to change it and add the rest. We can also add the icons to the menus (not checkable then) or remove the menus which have buttons in the toolbar.
-
I committed some initial work on adding your icons to the map editor. Just added all icons and dumbed some of them in two toolbars. I have actually no idea how to lay it out in a good way. I never made any map. So, anyone can feel free to change it and add the rest.
It's great that someone took the job. :) Thanks!
Please lay them out like this:
Toolbar 1: Edit: Undo, Redo, Randomize, Randomize Heights, Switch Surfaces
Toolbar 2: Height: -5, -4, -3, -2, -1, 0, 1, 2, 3, 4, 5 (blue ones)
Toolbar 3: Gradient: Same as above (red ones)
Toolbar 4: Surface: Grass, Secondary Grass, Road, Stone, Custom
Toolbar 5: Object: Tree, Dead Tree, Stone, Bush, Water Object, Custom 1, Custom 2...
Toolbar 6: Resource: Gold, Stone, 3, 4, 5
Toolbar 7: Player: Only one button (players), which would be a drop-down menu with these buttons:
Red (1), Blue (2), Green (3), Yellow (4), 5, 6, 7, 8
Toolbar 8: Radius: 1, 2, 3...
We can also add the icons to the menus (not checkable then)...
Nice idea! It would be easier to remember what button does what. Of course, tool-tips are still inevitable, and they should be identical to the text in the menu-bar.
...or remove the menus which have buttons in the toolbar.
No. :) There is no application that has something in the toolbar and not in the menubar.
BTW, I've downloaded Megaglest - colors for teams 5-8 are â–ˆ White for 5, â–ˆ Cyan for 6, â–ˆ Orange for 7, and â–ˆ Pink for 8. But I haven't made the buttons for them yet because there is no orange color in 4-bit palette. :P And having one true-color or 256-color button when all others are 16-color, hmm... not likeing.
BTW2, could someone change the colors for teams 1-4 in the map editor? In reality, they are red, blue, green and yellow, but in the map editor they are...
(http://img682.imageshack.us/img682/5746/playersq.png) and it's really confusing. I know I'm annoying, but think of me as a beta tester. :D
-
Just about the colors:
I converted your icons to xpm to get it easily included in the code. Every xpm has its own palette with full rgb. There's no problem with orange. Just provide png or convert to xpm yourself.
I will change the player color later.
-
I think titi already changed the colours to the expected values for players 1-4.
-
I converted your icons to xpm to get it easily included in the code. Every xpm has its own palette with full rgb. There's no problem with orange. Just provide png or convert to xpm yourself.
OK, I'm looking at the Wikipedia article (http://en.wikipedia.org/wiki/X_PixMap) about XPM. Based on this info, I conclude the following :D
- XPM supports transparency, but not the Alpha channel
- The more colors I use, file size will be bigger, since each color used has to be defined before the image.
Right?
Colored button images for players 5-8 will be released in a few days, but you don't have to wait for it. It would be awesome if you could upload the map editor with tool-bars so we can test it.
I think titi already changed the colours to the expected values for players 1-4.
Well, it doesn't seem so in my Map editor. Maybe I have an old version? It's 1.5.0 beta 2, built Mar 4 2010.
-
OK, I'm looking at the Wikipedia article (http://en.wikipedia.org/wiki/X_PixMap) about XPM. Based on this info, I conclude the following :D
- XPM supports transparency, but not the Alpha channel
- The more colors I use, file size will be bigger, since each color used has to be defined before the image.
Right?
Yes, but the file size is not so important nowadays. It's still really small.
Colored button images for players 5-8 will be released in a few days, but you don't have to wait for it. It would be awesome if you could upload the map editor with tool-bars so we can test it.
I could only provide linux binaries and it's not useful atm.
I think titi already changed the colours to the expected values for players 1-4.
Yes, it's fine.
-
I've fixed up the order of the object buttons, and swapped the road and custom(ground) surface texture button.
1.5 beta3 for windows can now be download here (https://sourceforge.net/projects/glestae/files/map_editor/1.5/map_editor.7z/download).
@ Yggdrasil: I had to 'translate' the mouse co-ords to account for the toolbars, everything was being placed about 50px up from where you clicked, can you confirm this is also needed for linux? If it isn't (ie, if it places things about 50px below where you click) could you please wrap the contents of translateCoords() [it's defined just above GlCanvas::onMouseDown()] in a #ifdef WIN32.
@ andy0101: The custom objects all have names these days (based on the precedent set with the tilesets that came with Glest), maybe some new button images for them would be nice?
@ Yggdrasil & andy0101 : Nice work, it's looking pretty schmick now :)
@ Anyone: If someone wants to take the cheat sheet and add titi's space bar innovation to it, and then format it nicely (pdf or html), it would probably be a good idea to distribute it with the editor.
Cheers.
-
maybe we add some more content/info in misc->help ?
-
You mean like some actual help content? What a novel idea ;)
-
There was a resize problem. The map jumped up and down if one resizes the window. In initial size it was fine on linux so i did not notice that this also adds an offset to the mouse pointer. I hopefully fixed that now. Nevertheless it needs your translateCoords now.
-
Great job! It works perfectly, but there are more things to be done. Resource and edit toolbars are missing.
@ andy0101: The custom objects all have names these days (based on the precedent set with the tilesets that came with Glest), maybe some new button images for them would be nice?
Work in progress...
And, should the Invisible blocking object have an invisible image? :D
@ Yggdrasil & andy0101 : Nice work, it's looking pretty schmick now :)
Thanks!
-
Done. I also modified other objects and created 5-8 player icons (players 1-4 on this image are only for comparison).
(http://img87.imageshack.us/img87/8330/index2o.png)
Download: http://dl.dropbox.com/u/2044596/glest/andy0101_buttons_v04.zip (http://dl.dropbox.com/u/2044596/glest/andy0101_buttons_v04.zip)
EDIT: Oops, the numbers are wrong... two objects are 5, and others are one less... ah it's over now.
EDIT 2: fixed :) (not in the image, but in the ZIP)
-
I added the rest of the icons and also found the reason for the offset of the mouse pointer. The mainwindow draws the map in glCanvas with its own size not with the size of glCanvas. So i removed translateCoords for linux. If it now also works on windows then please remove it completely.
It really looks now much nicer. Thanks for your contribution andy0101.
-
You're welcome. Also, when the "map zoom and position" is reseted, map's upper-left corner isn't positioned under the tool-bars (green arrow), but under the menu-bar (red arrow). I guess that was also because of the canvas issues and should be fixed now.
(http://img405.imageshack.us/img405/9606/arrows.png)
-
Does anyone use the randomize feature? If nobody has any objections I'm going to start working on making it a bit more useful.
Maybe if I get it working well enough it could be incorporated into the game itself for random maps?
-
Yes, I use it. Before I start creating the map I always randomize it a few times to make it look more realistic. Improved randomizing function would certainly be useful.
BTW: creating large maps (128x128) takes up a lot of CPU. Placing objects isn't real-time - when I click, the object shows up a second or two after click. Especially if the radius is big and I draw the line very fast.
Here is a video (http://dl.dropbox.com/u/2044596/glest/map-editor.7z) that explains it better (it's 500 kB 7zipped but 26 MB after extracting) :bomb:
It is even slower now because of the recording process.
Also, that is not my regular cursor, It's just for the purpose of recording.
Does anyone else have this problem? (I have a 1.6 MHz GHz processor, but it doesn't seem to be sufficient)
EDIT: OMG LOL I mean GHz :O
-
It's actually because you randomize the heights that it's so slow. 64x64 maps are fine as far as the lag and randomizing doesn't seem to affect it noticeably. 128x128 maps for me can be drawn on smoothly without randomization and after randomizing the heights the lag is terrible. 256x256 maps the lag is really really bad even without randomization and after randomization the editor becomes unresponsive.
If the height rendering was improved then it should solve your problem, but there may be other issues as well.
-
True, I tested all the combinations and it's same here. Something needs to be done about that.
Usually I don't create big maps since I'm a detail-freak, but I would like to try, and it's really hard because of the lag.
-
I added a map preview which loads the map into glest with a selectable tileset. Should help mappers to see what they are doing.
I committed this to the branch tmp_0.2_merge because there's is already a better commandline handling of glest. So it won't be available very soon, just to inform other devs that this is already done.
-
As far as map randomization goes how should the player start locations be randomized? There are basically two options:
1. Systematically place the player star locations around the outside edge of the map with a little bit of randomization to ensure that everything about start location is fair.
2. Randomize the start locations anywhere on the map while only stopping to make sure that the players didn't get put right on top of each other.
-
I added a map preview which loads the map into glest with a selectable tileset. Should help mappers to see what they are doing.
I committed this to the branch tmp_0.2_merge because there's is already a better commandline handling of glest. So it won't be available very soon, just to inform other devs that this is already done.
We should be able to save these previews in a folder which also contains the map. Then, the previews can be loaded into Glest to let us preview before we play as well. ;D
-
Yes that is a good idea.
-
The "new" map editor is great. :thumbup:
But when I try to open the map by opening it in Windows, it will just start up the editor, and will not open the map. (I associated the GBM/MGM files with the map editor)... So...why? ::)
Thanks. :)
-
Loading a map via file association works fine for me in Linux... are you sure you associated the files correctly?
-
As far as map randomization goes how should the player start locations be randomized? There are basically two options: ...
This will be tricky, and some terrain analysis may be needed to get good results. I'd recommend ignoring this problem for now, just concentrate on good hieghtmap and object placement results. Even resource placement might need some terrain analysis to get good & 'fair' maps.
But when I try to open the map by opening it in Windows, it will just start up the editor, and will not open the map. (I associated the GBM/MGM files with the map editor)...
Ensure you didn't associate them with the old map editor, this works fine for me on windows.
-
We should be able to save these previews in a folder which also contains the map. Then, the previews can be loaded into Glest to let us preview before we play as well. ;D
It would be nice to have a map preview in the new game menu but what i added can't be used for this. It's just direct loading the map without units and fog of war in glest, no render from far away.
-
This will be tricky, and some terrain analysis may be needed to get good results. I'd recommend ignoring this problem for now, just concentrate on good hieghtmap and object placement results. Even resource placement might need some terrain analysis to get good & 'fair' maps.
Well, my algorithm so far uses seed start locations for players and resources (including trees) and grows resources around the seeds. It so far builds playable maps which are fair a decent number of times.
(http://img696.imageshack.us/img696/5884/editorrandomization.th.png) (http://img696.imageshack.us/i/editorrandomization.png/)
I could commit the code I have so far or post a patch if you'd like to take a look at it.
-
Never mind, it works. I just had to "click" on it once... :-[ Silly me. :|
Thanks. :thumbup:
-
I could commit the code I have so far or post a patch if you'd like to take a look at it.
Please commit to trunk which holds the newest map editor. Post commit review is just fine.
-
Ok, the changes have been committed to trunk. I made comment blocks at the top of the Map::randomize() function talking about how it works and at the bottom about what I thought for terrain randomization.
-
I did a bit of work with the terrain randomization, I have not yet implemented the "diamond" stage in the "diamond-square" algorithm but filling the map with squares looks like this:
http://www.mediafire.com/?ytdmnjoth3m (http://www.mediafire.com/?ytdmnjoth3m)
(http://www.mediafire.com/imgbnc.php/66fca452b31a440981f4937ee41e730f2g.jpg) (http://www.mediafire.com/imageview.php?quickkey=yyn02ftnjio&thumb=5)
-
Looks good, way more realistic. :)
-
Thanks ElimiNator. ;D I wasn't even finished yet though!
I've finished the "diamond-square" terrain generation now, and it gives some pretty neat results. I still have yet to do any terrain analysis for good object placement, but I'm sure everyone would like to see what I have so far. I don't know if this map is playable for 4 players (I think the yellow guy got put in a lake) but It's still fun to look at in the map preview.
http://www.mediafire.com/?biuoztqzj20 (http://www.mediafire.com/?biuoztqzj20)
(http://www.mediafire.com/imgbnc.php/ad80ba68801723a2993349b1537f3a272g.jpg) (http://www.mediafire.com/imageview.php?quickkey=jud3zvzzx2j&thumb=5)
-
Do you think there could be a way to make the map random but give it radial symmetry, so none of the players are at a (dis)advantage from the terrain?
-
Quite possibly, the algorithm that's being used right now can be seeded and I intend to do that eventually. If certain points were seeded up and others seeded down then lakes or mountains could be coaxed into existence. I don't think 100% symmetry would look good but partial symmetry could look good and still be fair.
As far as player placement goes, I'm still planning on doing a bit of terrain analysis so that players don't get placed in lakes like the poor yellow guy in the last map I posted.
-
... in the "diamond-square" algorithm but filling the map with squares looks like this:
/me drools
I like algorithms, especially ones I'm not already familiar with :o
I've had a look over the additions in changset 530, but not your newer commit yet, I can solve some of your TODOs and probably some other problems with another algorithm I'm quite fond of, but it will require moving some code from the game into the shared lib.
You seem to be 'full steam ahead' though, so don't 'wait up' on my account, but as soon as 0.2.13 is out the door, I have some fancy tricks I'd like to share with you ;)
-
Well, I'm quite fond of algorithms as well :)
I'm also rather fond of fancy tricks and if you're planning to tell me about some I'd be happy to listen.
There's also a couple of other terrain generating methods that I looked into. One especially looked like it would be good at generating valleys and I was thinking about using it in addition to the one I'm using now.
-
Good work. :)
In 'Programming an RTS Game with Direct3D' book he multiplies a hightmap defining the player areas and multiplies it with the generated hightmap. "To ensure each player gets an equal size of flat terrain" and "to ensure that a path exists between the players". He uses perlin noise (and multiplying different octave levels) to generate the hightmap, although it looks like the diamond-square method is more popular.
-
Thank you.
I hadn't actually thought of thought of using a heightmap mask like that, it's a good idea I think. I think that book is actually at the library here at the university and I might go have a look at it.
-
Another quick question: when will the pretty icons be implemented into the editor? :angel:
Anyways, looks good! I like the fact that it shows me what is selected at the bottom.
Last quick question. Will all new map features stem from this map editor, or will we need a new one? If we will need a new one, how do I know when this one is "maxed out"? Thanks, no more questions for now. :)
-
Another quick question: when will the pretty icons be implemented into the editor? :angel:
Most of them are in already.
Last quick question. Will all new map features stem from this map editor, or will we need a new one? If we will need a new one, how do I know when this one is "maxed out"? Thanks, no more questions for now. :)
Any new 'map features' will break compatibility, and the current map format has some serious flaws, so if any new features get added, my preference would be for a whole new format, not a extension. That's likely the route GAE will take, I can't speak for the mega-mob. The old map editor might be able to be adapted, but it would be as much work as a new one, so a new one would probably be created from scratch.
Cheers.
-
https://sourceforge.net/projects/glestae/files/glestae_snapshots/map_editor/map_editor_win32.7z/download
Another quick question: when will the pretty icons be implemented into the editor? :angel:
Most of them are in already.
This is the link I used. I thought it was the newest one, but apparently not... :confused:
-
https://sourceforge.net/projects/glestae/files/glestae_snapshots/map_editor/map_editor_win32.7z/download
That one was build about a month ago. The newest one is in the GAE trunk. The newest released one is http://sourceforge.net/projects/glestae/files/map_editor/1.5/map_editor.7z/download (http://sourceforge.net/projects/glestae/files/map_editor/1.5/map_editor.7z/download) i believe.
-
Doh!
I changed the folder I was putting them in on sourceforge, and forgot to update the first post... Sorry! :-[
-
The new editor is awesome - thanks guys.
-
How can I edit the xpms in the icons subdirectory? I want to correct some colors in the icons and so on.
Which program did you use to edit them? Gimp can do it, but then the variable names will be different and some other things are the way the compiler doesn't like it.
Or do I have to manually change the variable name after editing it in a paint program?
-
Oh, this could be my fault. I just converted the png files to xpm with imagemagick and also changed slightly the names of the char** because they were ugly. I just assumed it works in Gimp. It adds "_xpm" to the name and does not make it const, so there are plenty of warnings and the error 'cause of name change. Maybe we should also add "_xpm" as suffix...
Meanwhile, have a shell script:
#!/bin/sh
# fix xpm when edited with gimp
if [ -n "$1" ]; then
sed "s/static char \* ${1/.xpm/}_xpm/static const char \*${1/.xpm/}/" -i $1
else
echo "usage: $0 file"
fi
If you only want to change some color values you can also edit it directly. Just change the hex rgb values at top.
-
I added some frames to the object Icons ( their size is now a bit unusual 20x20) shownig the color they have in the symbolic map later.
I checked that in in megaglest now. Should I also add them to GAE and which is correct branch to do that at the moment?
-
trunk is the place to work. If you think it is useful, please go ahead and add it.
-
By the way, I'm out of sync, does/will GAE support 8 players and all this stuff the same way MG does?
-
By the way, I'm out of sync, does/will GAE support 8 players and all this stuff the same way MG does?
It doesn't yet, but will.
-
The next editor version needs to force the .mgm file extension type when selecting player start locations higher than 4 positions.
-
I also think there should be a way to *hover* over a cell and be told its coordinates, as finding those out in scenarios is VERY ... undesirable. Preferably in the task bar.
-
how about a button you can push to bring up info on a certain cell, such as coordinates, type(tree, bush, empty), un/walkable, and any other useful stuff, it would basically be properties.
-
The next editor version needs to force the .mgm file extension type when selecting player start locations higher than 4 positions.
It does, it may not change it on the status-bar immediately, and the save box may even be set to 'gbm' when you save, but if it has 5+ players, it will save as mgm.
I also think there should be a way to *hover* over a cell and be told its coordinates, as finding those out in scenarios is VERY ... undesirable.
Can do, I guess if it's for this purpose it should tell you the cell co-ords, not tile... might seem a bit confusing to some people :look:
Is finding the cells so hard in-game ?? Toggle debug-info, click ground, read co-ords from debug info (PosWorldObject, co-ords of last position or 'thing' clicked).
-
But Kris just made a new eight player map and it saved as .gbm.
This is my new map Swampland Islands
This map is made for 8 players and has plenty of gold around the map.
This map was made for beginners for 3 simple reasons 1. Easy to navigate 2. Lots of resources and 3. your starting spot is almost completely closed off from everyone else giving you time to set up your base yet it is easy for you to exit.
There are a total of 23 islands big and small. I have tested the map on all 8 players and all of them are easy to use.
Here is the download link. http://www.mediafire.com/file/m2v65pn46z6d3e6/Samp%20Islands.gbm
Have fun and leave comments.
-
Perhaps he manually did so?
-
The editor should not allow manual file type selection for maps with more than 4 starting locations. I guess people could still edit the file name using the windows right click/rename function - but why? Why is it no one seems concerned with maps crashing the glest client? compatibility is a core issue here.
If a gamer came to this site from lets say.. hmm.. CNET.. with a fresh install of Glest 3.2.2 and s/he downloads various factions, tilesets and maps and the first thing that happens after modding vanilla Glest are client crashes - and for no apparent reason - what do you think their reaction would be?
(http://i821.photobucket.com/albums/zz136/TrappinGlestMaps/Glest%20Other/glest_crash.jpg)
/uninstall glest
-
I think different :).
I would say 8 is standard now. I see no reason to keep compatibility to the old glest. Its dead. I would say lets call all maps gbm again.
-
I think different :).
I would say 8 is standard now. I see no reason to keep compatibility to the old glest. Its dead. I would say lets call all maps gbm again.
Its development may be dead, but it seems like a lot of people still play it because they don't know about MG or GAE. Having their game crash through no fault of their own (just not knowing any better) is going to turn a lot of people off, I think.
-
I'm in full agreement with Trappin and John, I see no reason not to have compatibility.
-
I think different :).
I would say 8 is standard now. I see no reason to keep compatibility to the old glest. Its dead. I would say lets call all maps gbm again.
Its development may be dead, but it seems like a lot of people still play it because they don't know about MG or GAE. Having their game crash through no fault of their own (just not knowing any better) is going to turn a lot of people off, I think.
Full agreement with John.
Pros of keeping the formats separate:
If a gamer came to this site from lets say.. hmm.. CNET.. with a fresh install of Glest 3.2.2 and s/he downloads various factions, tilesets and maps and the first thing that happens after modding vanilla Glest are client crashes - and for no apparent reason - what do you think their reaction would be?
/uninstall glest
Cons:
[Insert sweet nothings here]
-
Do people who still play original glest really download maps?
If they start to think about map downloads they will quickly face MG/GAE! And thats what we all want or not?
Its like a new version of a game, I see no point to keep compatibility with the past here.
-
I agree with Titi, Vanilla Glest is a nice little standalone game for casual gamers but anyone who wants to mod/map for Glest should be doing so for one or both forks.
-
True, but consider it this way:
MG makes a new map feature. GAE will probably impliment it sometime, but hasn't yet. I make a map with that feature, but having the same extension, it can now crash GAE (assuming it doesn't know how to handle this new feature). The situation also works in reverse. Or if by some random chance, some poor, unlucky fool who doesn't want to download MG for reasons unknown (perhaps MG is too big of a download for said person, and maps are his/her limit?) and thinking its a vanilla glest mod, downloads it, only to have a crash.
Of course, I see your point, but I still have the last word:
Cons:
[Insert sweet nothings here]
How hard is it to make a new extension? Not one bit. ;)
-
We already have mgm, why do we have to break compatibility? :look:
-
We already have mgm, why do we have to break compatibility? :look:
+1 :thumbup:
Don't change the existing gbm format for legacy support... Go ahead and change mgm, though, I think maps need to have a version string stored in them, so that if modification done, even though the extension is the same, we can still find out which maps are which version (ie: v2 might have support for objects larger than one tile).