Jump to content
Eternal Lands Official Forums
Vegar

Integrating the map editor - discussion

Recommended Posts

Radu has said that he wants to integrate the map editor into the client. Before we can get started on this, we need a plan. Map editors are encouraged to post here, this is your chance to influence the future of map editing.

 

The way I see it, there would be a button on the login screen (or preferably on a server selection screen so that you can edit maps without being connected to any servers) that takes you to the map editor mode. Here you will have the functionality of the current map editor. The HUD bars will be reused, but with new buttons and icons related to map editing, probably the same buttons as are in the old editor.

 

The time can be set by clicking at the desired time on the clock in the HUD, to see the map under different light conditions.

 

To move around, I imagine you move the camera using the cursor keys (or wasd if desired) and the mouse to rotate. The camera is entirely free, it will be like flying. This allows you to see your map from all possible angles.

 

Technical details:

The goal is to re-use as much of the existing code as possible.

 

The map editor will be a window of its own, using the game window's drawing function (display_game_handler). This will make sure any changes to the client's rendering is propagated to the map editor too, but it also raises a few problems. As it is now, nothing is drawn if you don't have an actor that belongs to the client. Alvie and I are working on this. Most of the changes we make to get it working, will probably be commited to the main client repository as we go.

 

That's all I can think of for now. If you have any comments, suggestions or anything else, don't hesitate to post.

 

 

I can not promise that I'll be able to complete this project due to RL constraints, but I will at least get started on it.

Share this post


Link to post
Share on other sites

Hmmm when you mentioned that the client currently needs to have an actor that made me wonder if a default actor (or one of a selection of default actors could be applied (perhaps it could be toggled invisible) could be included in the map editor view. When I was trying to make a map, it would have helped me to visualize the scale having an actor standing there.

Share this post


Link to post
Share on other sites

Keep the movement/rotation and everything else to the current keys assigned in the map editor.

 

What I would like to see are hot keys to switch between the modes that you can choose from(the top bar in the map editor), like this would be good:

1=ground tile

2=2d

3=3d

p=particle

l=lights

h=heightmap

 

 

Other things I'd like:

-Currently you can choose a ground tile and holding down the mouse button you can paint the tile on the map. Make this also work for Deleting a tile.

 

-It would be nice to have a DELETE ALL feature. Basically anything you drag your cursor over will be deleted(2d,3d, groundtile, etc..ALL). It should be an area the size of a ground tile that is affected under your mouse cursor.

 

-The new particle system needs to be integrated: http://www.eternal-lands.com/forum/index.p...3&hl=editor

 

-New buttons made for the functions under: ctrl+e, ctrl+r, ctrl+w, ctrl+b...might be more i don't remember atm.

Share this post


Link to post
Share on other sites

Yes, that's another reason why integrating the map editor into the client is good, this way we can use various GUI stuff from the client.

Share this post


Link to post
Share on other sites

Hello all,

 

this post is to keep you informed on progress of integration of map editor in the standard client.

 

Vegar spoke to me about this project, and I promptly announced my availability to work with him on this. Thanks Vegar for the invitation. It's not a project for the fainted of the heart, and, according to our (me and Vegar's) principles, we want to do it the less intrusive way as possible. Not only that, but also to reuse as much as we can from both (as they are now), and maybe to help build/rebuild foundations for the client code itself.

 

This said, let me expose and maybe clarify how are we doing it.

 

In order not to pollute the client code (because we're at very early stages of development) we have created a separate branch so that we can keep commiting our code for the purpose of exchange. I know most of you are probably against the use of branches, but read until the end. We were emailing patches back and forth and it was becoming quite a mess to manage and integrate at same time.

 

This branch we're using is being managed the "reverse" way : usually you develop in a separate branch, and merge to main trunk when you finish. But, after speaking to Vegar, we decided to do it the other way - merge from the trunk to our branch, and do it often. This is what I call a "continuous integration project" - you all do your changes in the main trunk, we merge those periodically into "our" branch, and make sure everything fits in. We're to make these up-merges each 2-3 days so that we don't lose track because the longer it gets the harder it will be.

 

Right now the ELC_MAPEDITOR_BRANCH is up-to-date with the main trunk, and it's supposed to be that way (allow for 2-3 days) until we (and everyone) feels it can be integrated into mainline. While it is not, and due to some CVS deficiencies, we also have two tags there, which I ask here no one to change. One, which is called ELC_MAPEDITOR_LASTSYNC_TAG, points to the latest versions of main trunk we have already included in the map editor branch. The other one (which is temporary - but required when we merge) it's called ELC_MAPEDITOR_HSYNC_TAG. So to you all understand how we are managing this, let me write down the process:

 

* Each time we want to merge up main trunk into our branch, we need two "pointers" - one for the last versions we already merged (the tail), and one that points to the latest versions in main trunk (the head). This is because we don't want to re-include code we already merged in. These are CVS tags, respectively ELC_MAPEDITOR_LASTSYNC_TAG and ELC_MAPEDITOR_HSYNC_TAG. The latter is only needed because we don't want any code commites while we perform the operation to be left out.

 

* So we update the main trunk, and move the tag HSYNC to it. so HSYNC points to the latest version (unless someone commits rightafter - no problem about it tho).

 

* We merge the changes between LAST_SYNC and HSYNC tags into the branch. If conflicts show up, we solve them. We commit these changes into the MAPEDITOR branch.

 

* We "move" the LAST_SYNC tag to where HSYNC tag points, so that next time we merge we won't get repeated stuff.

 

* And so on.

 

When everyone feels comfortable about the code, we just "diff" our branch against the main trunk, patch and apply.

 

Questions ?

Edited by alvieboy

Share this post


Link to post
Share on other sites
No questions, but please keep us up to date with your progress!

Any ETA for a functional build?

 

We will post our successes (and failures) here.

 

About the ETA, we have none defined yet although we have an high level plan, but since the requirements may change (either due to different functionalities/new features/technical constraints) we have not yet came out with a milestone date for the first build.

 

We'll work on that, and post here some date we fell comfortable with.

 

Álvaro

Share this post


Link to post
Share on other sites

Hey all,

 

after some development, we (me and Vegar) do believe that is best to have the editor code not so mixed up with client code - to accomplish this we could put our implementation specifics in a separate directory. We have about 7 or 8 new files now, and we don't want to "pollute" the main directory - it's also not necessary to mess with existing code so much. We also like to have code split across several files according to the function it implements, instead of having huge blocks of code in one single file that reference basically everything everywhere.

 

So, unless someone disagrees, we'd like to have the mapeditor code in some subdirectory, named "mapeditor", and put our mapeditor-specific code there.

Share this post


Link to post
Share on other sites

Yes, sure, making a map_editor sub dir makes sense, just like we have the I/O, eye candy, shaders, etc. code in specific sub dirs.

Share this post


Link to post
Share on other sites
Branching of any use here?

 

Yes, we had to change some things on the startup process and some changes in the scene drawing (and more), which if included right now would break the client. So branching makes a lot of sense while we don't have this thing stable enough to merge in the main trunk. We also need to share code very periodically, even if that code does not compile at all.

 

Álvaro

Share this post


Link to post
Share on other sites
Branching of any use here?

 

Yes, we had to change some things on the startup process and some changes in the scene drawing (and more), which if included right now would break the client. So branching makes a lot of sense while we don't have this thing stable enough to merge in the main trunk. We also need to share code very periodically, even if that code does not compile at all.

 

Álvaro

Text-book case ;p

Share this post


Link to post
Share on other sites
Text-book case ;p

 

Lol, I have to have that text-book on my mind then :) Althrough I never read one about SCM :P

 

I take you do not fully agree with this, do you ?

 

Álvaro

Share this post


Link to post
Share on other sites
Text-book case ;p

 

Lol, I have to have that text-book on my mind then :) Althrough I never read one about SCM :)

 

I take you do not fully agree with this, do you ?

 

Álvaro

No, you're misunderstanding me. I wasn't being sarcastic. The phrase 'text book case' means that the case is perfect for what you're intending.

 

Oh, and I've never read anything on SCM either; that would be awfully boring.

Share this post


Link to post
Share on other sites

I did some changes in the build system for Linux (Makefile.linux) that might be useful in the main client.

 

* The dependency list is generated on the fly - you don't have to wait for the "make .depend" to finish so to start compiling. This uses the "autotools" approach.

* The compile command is suppressed and changed to be more readable (like kernel kbuild). Errors/warnings are still shown on the terminal.

 

I wonder if some of you might take a loot at it (just update to ELC_MAPEDITOR_BRANCH) and see if it might make sense to integrate sooner into the client.

 

There is some stuff there that is mapeditor-specific, that would not be merged, of course.

 

Álvaro

Share this post


Link to post
Share on other sites
I'd really like to see this one go in. It makes recompiles so much smoother.
I agree, its much better than before and working fine as far as I can tell. Nice work Vegar and Alvie.

Share this post


Link to post
Share on other sites
I'd really like to see this one go in. It makes recompiles so much smoother.
I agree, its much better than before and working fine as far as I can tell. Nice work Vegar and Alvie.

 

Ĩf no one objects, I shall commit this into mainline then.

 

We can always remove it later if needed.

 

Álvaro

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×