Rachek

Oh, well, bad news. There's probably going to be a bit of a delay. I managed to work a bit too efficiently as a contractor and worked myself out of a job. I've been laid off - just after leasing an apartment and getting into college. So, I'm going to be madly focused for a while on not going massively into debt and maybe, occasionally, eating. To reiterate, I'm not abandoning this or anything, I just need to devote myself completely to getting my affairs in order. Still, I find working on this entertaining enough that I'll probably work on it regardless. I just can't guarantee anything at this point. Sorry folks.

Oh yes. You're my number one skeptic. Keep it up, by the by. The fact that you consistently point out that you don't think this will happen spurs me to try to prove you wrong. Sort of like constructive criticism, just more pessimistic. =D Depending on how insane work is I expect I might have something that could be played around with by this weekend. Maybe. It won't be pretty or great but it'd be more substantial than screenshots.

Sorry for the double post, but I'm not sure if just tacking this onto the end of my previous post would mark the thread as unread and such. Anyway, just a status update for the skeptics out there. Work is taking up a good majority of my time but things are coming along nicely. The editor can now import custom and default floors and creatures (ala corescendata.txt) so I've put together the beginning of the town editor. I put together a simple but robust method for handling informational and error messages so you can see a bit into the debug output in this screenshot. Right now I'm going to work on implementing terrain and item processing, so I can get corescendata2.txt loaded and finish up properly displaying the town. Then maybe editing would even be possible. I'll keep you updated. Not too much longer now, folks. I'm hoping to get this to the level of the original editor and then go from there. Fortunately I have enough of a framework that most of the remaining core work is essentially copy/paste with some tweaking.

Once I get it at least marginally working, probably. I'm not using anything proprietary so far so I don't see any reason why not. I'd just rather wait until I've got it working and have cleaned up my experimental and thoroughly spaghetti-ish code before I inflict it on anyone else. As far as the working bit goes, I'm quite far off from that but definitely chugging along. I just wanted to show what I currently have. I'd let everyone play with it but for the moment it doesn't actually do much and I'm afraid it'd be too disappointing. That's about it so far. It can fully read a scenario and I have some basic preliminary work on converting the data structures into a format that's more Java-friendly. I just finished the code to let it load graphics, hence the retro background and scenario icon. I'm thinking that next I'll be working on getting it to read the scenario data files and start on the insanity that is custom objects. It won't be much longer now I'm thinking before I'll get it to the point you can start to play around with it.

Just an update: got a lot of work done over the holiday weekend. I have a basic GUI and it's fully capable of reading all of the data from BAS files. Right now I'm working on the code needed to load and display graphics and their individual icons. After that it'll be relatively trivial to start making things like a map editor and such. I'm not sure when it will be in any way presentable, but I've got some of the more complex things taken care of. It seems to be going pretty smoothly.

Ha, no! It's still going. Somewhat slowly due to work/school/life, but definitely kicking. I've been hesitant to just say, "Hey, still alive! No, nothing yet!" ad nauseum. Just rest assured: until I say so, this project should be assumed alive. Anyway, after being unable to get Mono to work myself I've pretty much given up on C# and have switched to Java. That, at the very least, should be readily supported by everyone. I'm having to do quite a bit of tinkering with my existing code to translate it properly, but I'm getting there. I haven't the slightest ETA at this point as I've never worked with Java extensively before, but the good news is that now that I don't have to constantly check for compatibility I can generally move faster. Technically I tried to make my own editor in an endeavor roughly like this about two years ago but gave up due to being too busy. It was quite functional and able to load all of the data types, the scenario data, and display town/outdoor sections, if not fully capable of editing, and I'm going through its code to use in this project. Once I get the hang of Java, I feel this should take off rather quickly. Honestly I'm more focused on this version than I ever was on the old one just because I went and told people about it. Having other people interested really does help. While I'm thinking about it, is Java regularly used/available on Macs? I'm just assuming it is, as Java is about as common as Flash in some ways. Though at this point, if it isn't, I really don't know what to do otherwise.

Yeah, really the fact that Blades of Avernum is installed is kind of irrelevant. The editor will be completely standalone in the end. At the moment it just checks for a folder named "Blades of Avernum". It could even be empty - it just needs a folder. I was thinking that having it know where BoA was installed would be useful, but really that won't be needed so I'll be removing that fairly soon. As it is, it's a good excuse for testing the folder browser. I think I've got the kinks worked out in Windows, but I'm still working for compatibility on Macs. Speaking of, I've managed to convince (con) a friend of mine to lend me his old MacBook for a while so I might actually be able to test this stuff on my own. Maybe. I'm still trying to figure out how to work it.

I have one last version to try out. Barring some new issue, it should work. I've had to make my own dialogs, so with this one you should especially run it in a directory other than Blades of Avernum to make sure the folder browser is functional. It should also be able to better handle error conditions so if anything does go wrong it should do more than just hang. It can be downloaded here: https://dl.dropbox.com/u/26820555/BoA%20Editor%20Files/Releases/0.0.0.2/BoAScenEditor.zip While waiting for results on this I'm starting preliminary work on the editor itself. At the very least I've figured out what to avoid when it's running on Mono. I don't really have any sort of an ETA there, but I should have something soon.

Yes, if you see that screen, the test was successful. Thanks! The colored bars were supposed to be split. The left has three solid colors, while the right has a gradient. I've mostly been worried that the colors could get mixed up between platforms, though it's looking like all of them use the same ARGB format which simplifies my job quite a bit. I can remove some unnecessary code that should speed up loading and converting images greatly. I've been putting together one last version using input from ξ that should be fully compatible with both operating systems. Once it's done, I'd appreciate it if you could try it again as I don't have access to an XP machine to test this on. I definitely want to make sure this will run in as many places as possible.

With any Windows version since XP, .NET v4.0 is automatically installed. Before that, you have to do it manually at the Microsoft website. Takes just a few minutes. I think I'll probably include the distributable installer whenever this thing gets closer to working properly just for those that need it. Well, I'm realizing that there's just no support whatsoever for some fairly basic features so I'm having to make alternatives. Definitely a good thing this is coming out at this point rather than later. I think it might be good for anyone that tests to also give me a copy of the EditorConfig.dat file. It has some more information that might be helpful. As it is, once I can get the test program to work everywhere, I'll be ready to make the real thing.

I've managed to track the problem down to the display of message boxes. It looks like that isn't supported across operating systems. I'll remove the messages and see if that lets it run properly. EDIT: Okay, I've removed the message boxes and updated the file. It can be redownloaded at the previous link. Now, it should either work or just close itself. Either way, the log will tell me of any issues.

Huh. There's a tool devoted specifically toward detecting Mono compatibility problems. So, I used it, fixed some other things that apparently aren't supported, and got a (hopefully) working version. It can be found here: https://dl.dropbox.c...orTestFixed.zip Considering the whole point of this test is identifying compatibility issues, the fact it didn't work is actually a good sign! As an aside for programmer types, anyone have a clue why memory mapped files wouldn't be supported by Mono? Seems like a bizarre thing to not handle given they're supported by most major operating systems. Oh well.

So, I feel dumb. Turns out the code I used to handle making the log file isn't actually supported by Mono. It just crashes. So, I'm rewriting my own, definitely supported alternative. As for making a double clickable app... maybe. I think it could possibly be possible to make a very, very simple Mac app that would function as a launcher. That seems trivial enough, though I couldn't really compile it or anything.

Testers needed! I finally have something! It's still just a test, though I'd like to get at many people to try it out as possible. It doesn't actually do anything but I'll be able to make sure some of the big things I have planned can work. Once I am reasonably certain that no gigantic bugs are there, I'll be able to finish up the actual editor without worrying about the core functionality failing. So, if you'd like to help, just download the test program here: http://dl.dropbox.co...AEditorTest.zip All you need to do is run it, get the log file, then email it to me. I'd prefer testing on a Mac, but Windows tests will be good as well.

Wonderful, thanks! I think that fairly soon I'll see if some people can run what I have so far and have it start up properly. If it starts, that means it will have been able to properly locate BoA, set up its directory tree, and install all of the resources it'll need. Seems like a good first step. At the moment, it'll assume that it's being run from the main installation directory (the "Blades of Avernum" directory) and if it's not, a browser will appear asking for its location. Simple enough I'm thinking. Once I know the basics are taken care of I'll be able to move on the the nicer things. At this point, all I need to do is finalize the basic implementation of its resource management system and it'll be ready to test. Which means likely a day at most. I'll be out of town this weekend but I should be able to work on my laptop, so expect to see something soon.

I do like to think I'm fairly stubborn when it comes down to things like this. One little setback isn't the end of the world, it's just an excuse to find new solutions. I love challenges, hehe. So, I need a bit of information. Could someone provide screenshots or otherwise make available the directory structure of BoA when installed on a Mac? The editor tries to find the main executable (or at least a file with the correct name) to determine if it's located the installation directory, and then accesses the resources from there. That would be "Blades of Avernum.exe" on Windows, but I have no idea what it would be on a Mac, and if there's an equivalent to the "Data" directory on a Mac I'd need to see that too. I've found a way to determine which OS it's running on, so a lot of the things like this can be automated nicely once I know how it's all laid out.

So another update: my idea didn't work. What I thought would be a simple problem managed to derail everything. I guess that's what I get for experimenting. The tests I mentioned before aren't very useful if I can't even get it to work properly on Windows. Gah. I've shelved that particular bit of code. I may try it again later, but for now I'm just going to make a simpler, WinForms-only model. Mono claims to fully emulate WinForms, so as long as I stick to that it should cross over hassle free. It won't be very pretty, but it'll get the job done I'm thinking. So, rather than try to untangle what I have from my failed experiment, I've been rewriting everything while copying over what works so far, which is most of the logic for the various scenario objects. Another small setback, but I've got a much firmer grasp on exactly how I want everything to work, taking into account what didn't work out right before. Overall, things are on track. I'll keep things updated as I get closer to an actual working version.

It seems like Mono may be a bit of an annoyance, but it's the best I can do. I couldn't begin to write a native app so something mostly cross platform is the next best thing. I'm really trying to make an effort to let this be available to everyone rather than just tying it to my platform of choice. While I don't know about Macs, I have used Mono extensively on linux systems and they're distantly related in the end. It shouldn't be all that difficult to install, going by my own experiences. That aside, I'm nearly ready to attempt the testing I mentioned before. I can't say when it will be ready, but mostly I'm just cleaning up a few obvious bugs before I inflict it on anyone else. Its core logic is all done, however.

Mono is the open source framework that lets programs written in C# and similar languages run on non-Windows systems. I chose C# specifically for that purpose. Otherwise the project would have to be divided in two - one version for Windows users, and one for Macintosh. That would mean two development branches, two UI styles, two downloads, ect. With Mono everyone can use the exact same program which means that, for the most part, everyone will have the same features and experience regardless of their OS. Of course, it means that Mac users will need to have Mono installed to use my editor. Hopefully that won't put too many people off.

Yay, relevance! I'm really hoping this will rekindle interest in designing scenarios, so this definitely helps in keeping me motivated. Anyway, at some point relatively soon I could use some help with some preliminary testing. I've been working on getting a generic framework for the GUI set up to give everything a nice docking tab feel, and while I've been testing what I have so far rather extensively and making sure it works just right, I'm stuck with the same problem as before: I can't test it on a Mac. It's built entirely out of basic WinForms components, which Mono claims to completely emulate, but if for some reason some feature breaks I'd rather know about it sooner rather than later, particularly if it causes some sort of major disruption. So, if there's anyone out there that would be willing to run some simple tests on a Mac with Mono, I'd appreciate it. The app itself isn't quite ready yet, though I expect it will be done within a week or so.

Just a quick update: I'm not dead! And neither is this project. I really am going to finish this thing eventually! I do have slightly less time due to a new job, but that's life. Lately I've been putting all of my effort into a revamp of the GUI. I was quite dissatisfied with the fact that I was relying on the functionality of a control set that wouldn't work on Mono, and I failed to find any sort of alternative that wasn't equally entrenched in Windows. Not to mention I found no way to implement the overall style I was looking for (that being the docking-tab functionality that most modern IDE's use) without shelling out a lot of money for licenses and such. And they wouldn't work with Mono either. So, I've been tinkering with some other options. No real results yet, though if I cant find anything soon I'll probably just make everything myself. I'd like to avoid that, but I'll do it if I have to.

Well, to put things bluntly, since it seems like you actually know what to do and how to go about doing it, and I've been putting an unpleasant amount of time absolutely flailing with the same issue, I think I'm just going to back off and see what you come up with. I could actually be better spending my time dealing with about a dozen other issues than beating my head against my keyboard. Such is the price I pay for ensuring compatability, I suppose.

Oh, that's not what I meant either. .NET and Mono have many, many methods available for working with native libraries. If a C++ program could link to it, a C# could as well. I'm thinking that the one thing that'll probably do me in here is HFS. The more I read about it, the less it actually makes sense. Quite perplexing.

I've got the PICT format mostly worked out and I'm in the process of making the exporting functions. As far as cmg files go, I'm finding scant few resources that actually describe the format as opposed to how to use various unavailable API's to manipulate them. Still, getting the PICT files working is the first step. That's not necessarily true. I'm proficient with both languages. At the very least I'm learning just how little I actually know about the inner workings of a Mac. Any information I can get at the moment is most helpful.

That's almost exactly what I thought of. From what I can tell, converting a PICT to BMP is very tedious. I'd have to emulate at least a subset of the Quickdraw library which is kind of extreme for this. However, BMP to PICT seems (roughly) straightforward from what I've read. It'd just be another slight derivation from the standard scenario format. I can definitely see having designers use BMP's and have them processed and archived just like the default images. Then, when the scenario is built/compiled/whatever-you'd-call-it it could convert the images to the proper formats. I already have nicely functional code to handle converting the images to and from BMP's trivially. All I'd need to do is extend the concept to convert the resulting BMP's as well. Awesome. I've been worried about this one.