> 1.) the editor do the collect for the arches. It will write: > > - bmaps. > > - crossfire.png > > - archetypes > > - animations > > The current collection method must remain available. If I'm > just doing some > quick change for some arch, I don't want to have to load up the > java editor just > to collect those. Maybe the server doesn't even have java > installed, or is set > up such a way that I can display back to my system. > > And really, it would probably make more sense for the java > editor to just use > the existing collect scripts. If the java editor creates the > files in the same > form, no big deal, and I don't have a problem with the java > editor having a > collection option, but that must not be the only way they can be > collected. I'm > also really suspect about having the editor actually create archs > - yes, it may > allow for better checking on integretity, but at the same time > may lead to a lot > of new archs being created when they in fact should not be. The editor collect 100% compatible scripts. The bad thing is that you need to load all - well, when packed later, this need only seconds. The good thing is the strong control. I found without really looking for 2 small bugs in the arches. I don't think people will create arches like wild when the arch editor is out (and this will need some time, i don't have it on priority list). For this, the whole action is to hard, setting up all the stuff. > > 2.) transfering arches and maps > > > > I will setup the arch and maps in a way, we must touch every pieces to > > transfer > > it to iso. The editor will have some commands to automate this, > for example > > a > > find & replace thing. > > I'm unclear what exactly this means. > > Non ISO support MUST REMAIN. (or not, but if overhead view goes > away, so might > I). I really really really dislike iso views for most games. > Yes, it looks > nicer, but I find the playing of it a PITA. > > I'm going to send out another message about more large scale map > updates. But > IMO if every map needs to get touched up for ISO, in addition for every > archetype/image, this results in a ton of work. Well, thats the old discussion. The maps will not be compatible - and should not. I mean the look of course - not the logic (mashines, quests). This is a clear point i think? Why we are using iso? Because it give us other option for the look. So, thinking the old maps can be transformed, is childish. I don't know why every one think this is good. it is possible, yes. Its also possible to make a ascii client... In real: - Our maps look BAD. Our gfx set is bad. - the game is great. All people whinning about bad look, unfinished maps and broken quests. Repairing this is the smae amount of work. So, you can't avoid the work when you need results. If you want to stay for flat - stay. The server will not be effected, nor the gameplay. The bad point is, that we will split dev power. Btw: showing ISO maps flat is much better. Bad thing is , that you have to draw new or special monsters. Iso multi monsters don't need so much place like flat ones. Well, this only effect a few monsters, 90% will be untouched i think. For this, it is possible to do create new flat monsters. > > > Let me say that this will give us the chance: > > - to restyle some maps > > - using more intelligence style sets! > > - style sets will give the power to use mask, i will introduce > this later > > - rework the painful looking of some maps > > - and so on > > Some maps need that. But I'm fearful of this ever getting done. Doing > something like updating every map will take a ton of time - I've > seen this with > the images. > > > > But we have MANY unfinished maps! > > - bad style > > - unused exits > > - unfinished quest > > - broken maps! > > That of course has nothing to do with iso or map form. It is > just a matter of > resources - the person doing the map ran out of time, moved on to > somethign > else, or may just ran out of ideas. I don't see how having to > rework all the > current maps is going to help that out at all, except to maybe get a more > conistent step. > > > Ask AV about how long he needs to finds out the puplands map > and how much > > work it was. > > documentation about maps (and anything else) is a pure developer > issue. Rework > all the maps you want, but if the developers don't write the docs > about the new > maps, you run into the same problem. The reason of lack of docs > is (either map > or programming/arch/whatever) is simply because people don't > write them. Unless > we force them somehow (don't accept anything without doc), I > think we will get > into the same program again. But if we get too anal about what > we accept, then > you get into the problem of people saying 'I don't want to jump > through those > hoops', and thus don't develope. You haven't understand this mark. MAP LOGIC is not touched! And i will include a replace system . Working over a map, changing style and look is not the big work. Thats a "eye work" not a "brain work". Setting up the logic, connection and game play - thats was hard in maps. > > 3.) Scripting: Scriptfire > > > > Scripting is so great and gros scriptfire works fine. > > This will give us the chance to include this from bottom up. > > MW will put it in CVS, so we can use it in all versions. > > I said it should probably be put it, but didn't actually > volunteer myself to do > it Gros - do you think it is ready for inclusion? > > > > > 4.) Client hacks for windows and linux > > > > I will do a fast patch so linux and dx client can show & play iso maps. > > Don't do fast patches, do proper patches. > > One of my pet peeves is the 'fast patch' which takes the easy > approach and then > needs to get fixed up later to do the properly thing. > > IMO, what proper means in this context is command line option to > switch between > iso and non iso display. Then we need 2 skins for the client. One for iso, one for flat. But thats not hard. Remember that even the editor handles booth mode. And you can change at runtime and for every part.