alvieboy

Hey, yesterday a guildmate (Minion07) spoke to me about how nice would be to have some text macros to write common stuff ( like #gm hello guild ). I found the idea interesting, and not very hard to code, so I took a few hours and implemented some basic stuff. The idea is to have 100 text macros, which can be bound with command "#bind", like "#bind 1 #gm Hello guild", and called by just entering "#N <parameters>", where N is the index of the macro. I did implement the basic without the parameters. You can check here a screenshot (some lines there are debug). Do you think it is useful ? This is only client-side, of course. Some people really would appreciate this feature. With parameters, you could write "#bind 1 Hey $1, you wanna PK?" and later just type "#1 somename". Thanks again to Minion07 for the idea. Álvaro

Hi, The new map editor is not ready to run on Windows - the file selectors were not yet implemented (only gtk, that's why it asks you for it). As of now, I don't think anyone is working on it. But feel free to hack the fileselector code if you wish. Álvaro

After a very long chat and much pondering, Vegar and I have decided to halt the work we've been doing on the in-game map editor. Effective immediately. In the light of recent events (see below), we have decided to fully freeze our development and contributions - it is by no means a decision that makes us happy, but it is something we feel we have to do. It is not, by any stretch of the imagination, only related to the specific events mentioned. These issues arise far too often, and it would be against our principles as decent and honest people to continue to contribute to a project that refuses to respect its player base as people. This makes us, not only as contributors, but also as players, very disappointed. This time, one of our guild members and friends were involved. Next time it will target another player, with the same doubts, same questions, same membership rank, and who will surely be astonished for being kicked out for no other reason than expressing his thoughts and, maybe, valid contributions to the discussion. Maybe in the future, if we are convinced that our effort to EL is worth it, and if accepted back, we will pick up where we left or otherwise contribute to other areas of the EL client. Right now, we sadly have to move on and sail to quieter waters, where we feel in peace with ourselves. AlvieBoy and Vegar. The now deleted thread in the abuse forum that started like this: When I read something like this, it totally demotivates me to give people ANYTHING more than they have now, because we have some little pigs like you who always want MUCH more than you give them. I'm a noob and I have no idea what is the history between Entropy and Quesar. Although I'm the same guild with Quesar I really don't know him very well and I haven't talked to anybody before writing this post. I have no clue what exactly is the crux of the problem since my summon lvl is 0 ( I intend to start summoning next week) But as Burke said : "All that is necessary for the triumph of evil is for good men to do nothing" So I refuse to stay silent ... IMHO calling a player pig for expressing a personal opinion (regardless how correct was that opinion) I believe it is in breach of Rule 4: "You must respect the rights of others and their rights to enjoy this game and the forums." You can also read this conversation here for further details. Zoxe42 was "temporarily" banned from forums for 2 years and his character Zoxe42 banned from the game. Others have been banned "temporarily" from forums, some of them were reaccepted later on.

Ok, commited. Any issue with it let me know. Álvaro

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

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

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

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

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.

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

Yes, I know that. I'll commit a circular dependency check to avoid people doing it. Álvaro

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 ?

Is this related to SKY_FPV ? If so, maybe we could merge it and get rid of the unnecessary #ifdefs. Or have some flag in configuration to enable/disable it. Vegar spent quite a lot of time getting rid of already "mainstream" defines, and since we really don't have a release coming in the next few weeks.... it's only my humble opinion. If it's not related to FPV then ifdef's are ok. Álvaro

There seems to be a bug in how SKY_FPV handles ini entries: I get these on my el.ini (last lines): #follow_cam_behind= 0 #ext_cam_auto_zoom= 1 #follow_cam_behind= 0 #follow_cam_behind= 0 #follow_cam_behind= 1 #follow_cam_behind= 0 #follow_cam_behind= 1 #follow_cam_behind= 0 #follow_cam_behind= 0 #follow_cam_behind= 0 #follow_cam_behind= 0 Quickly fixable, I suppose. Álvaro

Hmm what about using those right-click menus here? Would be spectacular if we could use those on tiles, and have a nice set of options. Álvaro

Great But, Ent also forgot that "hello guild" requires actually "#gm hello guild", which takes a shift. And really prefer using "#1", that's 3 keypresses. And my #2 is "#gm gratz $0", so I can type "#2 Placid". Álvaro

Top 20 ifdefs/ifndefs : 36 WINDOWS 39 WRITE_XML 44 NEW_CAMERA 49 OSX 60 CLUSTER_INSIDES 63 NEW_ACTOR_MOVEMENT 67 DEBUG 67 MISSILES 72 NEW_ACTOR_ANIMATION 73 MAP_EDITOR2 74 EXTRA_DEBUG 81 ELC 92 MAP_EDITOR 98 _EXTRA_SOUND_DEBUG 104 NEW_LIGHTING 119 SKY_FPV 138 GL_GLEXT_PROTOTYPES 184 OPENGL_TRACE 227 __cplusplus 285 NEW_SOUND Fetched with: find . -iname "*.h" -or -iname "*.c" -or -iname "*.cpp"| xargs cat| perl count.pl script: #!/usr/bin/perl my %cnt; while(<STDIN>) { chomp; if (/#\s*ifn?def\s+([^\s]+)\s?/) { $cnt{$1}||=0; $cnt{$1}++; } } foreach my $k (sort { $cnt{$a} <=> $cnt{$b} } keys %cnt ) { print "$cnt{$k} $k\n"; } Álvaro

Hi, here is the description for the new commands for text aliases (see here for discussion). Text aliases allow you to create a quick command alias to some command - this is very useful if you do write same stuff all the time, like "#gm Hello", and such. To avoid having you to type that all the time, there are up to 100 text aliases you can use. Plus, these aliases can have parameters which you must type when you call the alias. Using an alias is very simple, just type "#<n>", without the quotes, and substituting <n> by the alias number you want to use. This number must be between 0 and 100. So, to use alias number 66, just type: #66 . To create an alias, just type "#alias <n> <text>", substituting <n> by the alias number, and <text> by the alias text. This text can include commands, such as "#gm" and "/myfriend" . Example to create alias number 66: #alias 66 I am such a noob I don't know how to create aliases . To remove an alias, just type "#unalias <n>" To list your current aliases, type "#aliases". All aliases can be parametrisable. The parameters are limited to 10, from 0 to 9, and have to be "passed" by your alias invocation. To define an alias with parameters, just use "$N" in your alias text, where N is parameter from 0 to 9. If you want '$' to appear as-is without being handled as a parameter placeholder, just type '$$'. Example of an alias with parameters - remember parameters start at 0: #alias 1 #gm I feel so $0 today because I $1, and now I want to $2 . You can then call this alias like this: #1 sad "am a lousy guy" scream . This will act as if you had typed "#gm I feel so sad today because I am a lousy guy, and now I want to scream". Nice, isn't ? As you can see from previous example, using doublequotes in the alias arguments makes that text behave as a single argument. If you don't pass enough arguments as required, an error will be shown. This seems to be all for now, Álvaro

Hey all, it's in CVS now. Make sure to enable TEXT_ALIASES in make.conf. Tested build on linux and win32. Maybe some of you OSX guys could try building it too. Álvaro

See http://www.eternal-lands.com/forum/index.php?showtopic=39609 I assume your idea is similar. Álvaro

Hmm, I don't have any objection at all. I really did not think much about this issue ,cause there seems to be no consensual approach for the fix/rewrite. If we do agree on how to do it, I'll gladly hit my keyboard to fix it. Álvaro

Some technical issues about this implementation: * It uses code from a patch I submitted to fix the "makeargv()/freeargv()" in windows platform (see here). It was never committed, but can be used from now on. Its required here to handle the parameters. * It uses a simple dynamic buffer implementation, which can be reused for whatever you like (documented for doxy, showing only the protos - the names are self explanatory): typedef struct { size_t alloc_size; /**< Current allocated size of buffer */ size_t current_size; /**< Current size used in buffer */ unsigned char data[0]; /**< Data placeholder */ } dbuffer_t; inline void dbuffer_destroy( dbuffer_t *dbuf ) inline UNUSED_RESULT_DECL dbuffer_t *dbuffer_append_data( dbuffer_t *dbuf, const unsigned char *data, size_t datalen ) inline dbuffer_t *dbuffer_new() inline dbuffer_t *dbuffer_sized(size_t datalen) inline dbuffer_t *dbuffer_new_with_data( const unsigned char *data, size_t datalen ) *`There's some code there also to "escape" strings to be written in files which might contain "weird" chars, by escaping them with octal values. This can also be used elsewhere if needed. Álvaro

Ok, now a screenshot of parameters working PS: do you know any good free image upload site ? Álvaro

yes, but like "#aliases hello". Álvaro

This one is easy and it's implemented as I write this. Not so easy, cause it would require me to write another "parser" But I'll think about it. Álvaro