Celtic Minstrel

Um, I think it's pretty good by now. I haven't looked recently, though.

Okay, I wrote up a tentative grammar for special node definitions - it's up here. Any thoughts? (Note: I adjusted the list of possible node types partly on whim, combining ones that seemed similar and such; before actually using this grammar, we'd have to make sure the list here matches the list in simpletypes.h.) EDIT: Maybe I should put a sample here! The following file would define a node sequence (IDs 0, 1, and 5), which reveals a town if the party has enough gold. @if-gold ex1 50, 5 # If they have 50 gold, take it and jump to node 5 goto 1 # Otherwise, jump to node 1 @disp-msg msg 2 # Shows string 2; the omitted argument is assumed to be -1 @town-visible = 5 # Explicitly specify node number (if omitted, assumed to increment from last node) msg 3,4 # Shows strings 3 and 4 in the message dialog ex1 3,1 # Town 3, set visibility to true

Besides just updating, it's in dire need of better formatting... if anyone wants to help out with that, it would be wonderful.

Oh! Silly me, you can use std::to_string() to replace itoa! Though, that requires c++11, but we're already compiling as such, so that shouldn't be a problem. lexical_cast is still nice (because it can go both ways), but for converting anything to a string, to_string is a little better.

I've pushed my work so far, so you can take a look if you want. I think it still needs some work (more enumerations instead of integers, for example), but I think it covers everything necessary.

I'm reluctant to switch to a full-fledged scripting language like AvernumScript. In particular, I seem to recall that the nodes system is one of the reasons BoE was considered easier to design for than BoA. I don't have any objections to improving the special nodes interface though. And I was thinking about storing the nodes in a sort of assembly/BASIC-like syntax, which could end up being sort of like a scripting language (but more low-level than AS). The node system has a lot in common with assembly languages in particular, with each node containing an "opcode" and a set of parameters, but if we were going to properly support that as a scripting language, we'd have to include support for things such as labels and defines. Regarding your first sentence about missing things, those could be just as easily implemented as additional node types.

Okay, so the <id> is effectively intended to be a uniquely generated ID. I'll leave it in, but might choose a different way to populate it. I'll scrap the author ID and the <user> subtag. At the moment I'm thinking I'll expand on your idea of saving certain location-bound data with the map data (you had sign IDs and special node IDs); so far I'm thinking boats and horses, but I'll likely add more as I think of them. So far, I've got a working XSD schema for the core scenario data, and one for the core town data. On the todo list are monsters, items, terrains, outdoors, and dialogue. For the version control, I think what you mean by "dev layout" is kinda what I was thinking of - the editor (and possible also the game) would be able to load a scenario from an unpacked folder - so I'll go with that; the only question is how the scenario can detect that a folder contains an unpacked scenario. I can probably work something out once I get to coding it. About nodes needing a revamp, did you have any particular ideas about it, or was it just a vague thought?

I'd like to talk about the eventual new scenario format. I noticed Sylae started on it a bit here; that could be used as a base. As for my own thoughts, I think I'd like to split up the towns a bit more - keep the map in a separate file, probably the special nodes as well, and maybe even the dialogue. I like the idea of saving the special nodes in a format that vaguely resembles an assembly language, for example, and I don't feel that XML is a good choice for two-dimensional data; I'd prefer just having a file with one row per line, separated by commas or tabs or whatever. I also want the editor (and maybe the game as well) to be able to handle two separate formats. Since the scenario format will be a gzipped tarball, the editor should be able to read an unpacked scenario as well as a packed one. I'm not sure if this is too complicated, but the main reason for having an unpacked scenario format is actually so that we can see diffs to the mainline scenarios in the version control. I'm also not quite sure how it would identify an unpacked scenario. I'm going to start building a schema for the sample in the above link, but I was wondering what the point of the <id> generated from creation time is? (Also, how do you expect people to use their Spiderweb user ID as an author ID if they don't have a Spiderweb forums account? ) And what's the purpose of the <user> subtag under <ratings>? Originally I was going to bundle it up in such a way that the old BoE detects that it's a BoE scenario from a newer version of the game - do you think that's still necessary?

Well, that's not going to last, I'm afraid; once I finish with the scenario editor for the Mac I'll be working on porting that over to Windows, and it depends very much on Boost.

We have Boost as a dependency already, so boost::lexical_cast<std::string>() can be used replace itoa(). (Though, I'm not quite sure if the Windows code depends on Boost yet.) (Incidentally, lexical_cast uses std::stringstream in pretty much the way you're thinking.)

Is there a file types dropdown from which you can select "All files (*.*)"? Failing that, someone would probably need to tweak the code.

The scenario editor compiles for 10.7, but there are two factors that make it not qualify as working - half the dialog boxes haven't been reimplemented yet, and saving is currently impossible (it was disabled due to plans of making a new scenario format because leaving it enabled could've resulted in scenarios compatible with nothing). Maybe I'll find the time to fix all that soon and release a working editor. Until then, I'm afraid you'll have to find a way to get the Windows editor to work. Sorry!

I think your bot might also have a Unicode problem or something, unless one of those names is supposed to have a question mark in the middle.

I'm pretty sure that's correct, yes.

Seems like a good idea! I think we'd want to get permission from the individual designers before distributing additional scenarios with the game itself, but having this as a separate download accessible from the same place as the game seems probably okay.

Yes. I usually use Rezilla for my resource editing needs, but for exporting resources en masse, Resknife might be better. I think it actually has a mas export function. Of course, the exported files will still be in the System 7 sound format, so then you'll probably have to convert them to WAV or AIFF.

Yeah, uh, I need to fix that eventually... >_>

I know the E3 sounds are accessible in the Mac version as 'snd ' resources.

I doubt it was intentional for the icon to stay the same, but... in E3, the recipes from E2 that used toadstools were changed to use holly instead.

No, as the owner of the repository it's my responsibility to make sure the pull request is handled. I already did that as of my last post, so if there's still an issue it's with Sylae's Jenkins, I'd guess.

Pulled! The latest build should work for you, Ishad.

If I recall correctly, they can be used as a substitute for holly in certain recipes? Not quite sure, but they do substitute for something else in certain recipes.

That was because cl.exe by default links in a very simplistic command parsing routine. I had to explicitly tell it to link a different one that supports globbing. I guess cmd.exe doesn't expand the globs before forking, so the program is responsible for doing it. Or something like that. Main thing is, I think I fixed the issue, and it does now work in cmd.exe, so your test might've been biased (but that said, I wouldn't be surprised if it would've worked in bash before changing that, as well as in powershell). EDIT: Wait a second! I forgot to commit that fix. Whoops!

Done!

Although it mostly worked when I tried it on Wine on my Mac, the automap in Exile 1 and 2 didn't display. Using Wine in a Linux VM seems a bit silly though.