*i

Quote: I'm not sure that leadership is really what's needed right now. Leading by example is probably the best way to go. I agree 100%. I think you bring a lot of energy to this, and that is what is needed right now. You seem like you are most interested on the PC side of things, which is good, that is where effort is required. Set up whatever you want for the PC stuff. That being said, we should all collaborate and let ideas be thrown around. I think there is a lot to be gained from discussion. My feelings are close to Djur's. To reiterate what he said, which I feel is entirely correct, too much formality could make this project die out. The whole "bazaar" concept is entirely correct. We want this to be fun, that means people should have the freedom to do what they want. When it becomes formal, the fun tends to stop and it turns into work. Once this happens, the project dies. Once again, I hope you can contribute a lot to this effort. We all have our own interests and desires where we want to see this to go. Let's discuss some specifics and see what we can work out.

I didn't make a SourceForge account, to clear up any confusion. Also, I'm now a bold icon. We can, if we as a group feel it be the best avenue. I don't "own" BoE, the community does. Granted, I've been with the community since its release (10 years now), but still, anyone who wants to be involved should at least have a voice. Before really saying a whole lot, I'd like to hear what other people think. The question is where do we want OBoE to go. I think everyone agrees that priority one is compatability followed by fixing basic bugs and minor "features". Beyond that, there are a lot of ideas, but no coherent path yet. I don't want to influence everyone with my ideas, so let's hear yours first.

Thanks Djur, that helps a lot. I was unaware that OBoE was already used. Oh well. I agree on the issue of the dynamically allocated variables and also agree that it is a big idea. Another thing to keep in mind is having to make some major changes to the Editor as well. With a dynamic number of slots, a lot of the menu type things become unusable in their current form. It's a bigger project that I hope to see done, but for now I think restricting to fixing things up is top priority.

You are correct, Duskwolf. I think I have decided on taking out the error part of the code entirely. The way to combat the infinite loop is after each node call, to have Blades handle any menu command is per Khoth's discussion. This way the player can at least exit out of an infinite loop. Now I just have to figure out how to do the latter.

Right now we are using darcs for the stuff Khoth has prepared.

It's not, as far as I can tell. It looks like a hard coded value of 50. I don't think it pops up anywhere else as I haven't looked everywhere, but I think this one specific thing is it. I believe (correct me if I'm wrong) that Jeff was speaking in general about making changes.

I agree 100%. The thing with the node limit is we can always raise it or remove it, but never lower it or put it back. I want to find out what people would prefer. I'm going to think on this matter and what people have said here.

This comes down to a design philosophy issue. The point is how much do we as the developers trust the designers. In BoA, Jeff still has an upper limit on how many calls he tolerates before the script terminates. With regard to this issue, our options are as follows: 1) Full trust in the designer. Eliminate the ceiling and if the designer messes up, it is his/her fault. 2) Keep some control by the developer by setting an arbitrary upper limit. Set an upper limit to protect players and if the designers need it higher we can set it. 3) Some call to reset the node counter. There is still the possibility of infinite loops, but the designer has to work a bit harder to get into this territory. After speaking with Khoth, one thing that probably should be added is for Blades to handle any menu calls after each node. Such that if the designer would screw up, the player can just abort the game rather than just freeze.

A really basic thing to "fix" is to get rid of the pesky node limit. I have frequently found 50 to be too restrictive. While removing this altogether would be easy, the point of the node limit is to get rid of infinite loops. I propose we keep some kind of ceiling in, but make it quite high. We can always raise it if the need arises. I propose we make it 2500. That should give people ample space to do nodes. I need to update a couple things, but it should be an easy fix. What are people's feelings on this?

OBoE stands for Open Blades of Exile. It is an easy acronym that I propose we use for this open source project. Within this, I further propose a simple versioning system for keeping track of things. BoE -- This is the lowest level of modification. All of the code is identical to the standard release except for any compatability issues. Everything Khoth has done thus far falls into this category. OBoE v 1.x -- Any set of changes that maintain backward compatability with original Blades of Exile scenarios are in the version 1.x set. Bug fixes such as the 100 town bug, strong strength potion, etc. or minor modifications like removal of the 50 node limit would go here. OBoE v n.x (n > 1) -- Any code modifications that would break backward compatability would go here. The goal would be to maintain backward compatability within n. So a scenario created in v2.0.4 would still work in OBoE v2.1.1. However, OBoE v3.0.2 would not support it. Major changes in game balance, mechanics, spell systems, etc. would fit in these. Any independent developments in OBoE are welcome, but I think the community should keep some control over the official versioning. =============== With these set up, I think our first prioirty is to get everything running in BoE proper, the lowest level. Khoth so far has done an excellent job getting everything to work here and it is very exciting. Good work so far! Next we should focus on simple things to do with OBoE v1.0. The future releases v2.0 will need to be planned out a bit more, I have some ideas regarding this, but I would like to start off simple first and take care of getting the basics working before we go off into a more radical territory. Thoughts?

For the record, I was able to get mine to work, but my testing has not been very extensive, i.e. only at the beginning of VoDT.

This is fantastic! I tested it on my Mac and it appears to work as expected. Good work Khoth!

Looks promising! Keep up the good work and good luck getting the thing to work.

Sounds very exciting. Look forward to this next adventure.

I'm hoping that your file didn't somehow get corrupted during the save. It is rare, but indeed possible if things don't get written properly.

It should compile/run in classic mode. While I'm not up on compiling applications like this, my abilities are far more in the scientific code which largely work independent of platform, you will need a C++ compiler for OS 9. Just curious, is anyone actively going to work on carbonizing it?

Quote: The fossil record shows this very thing! That is why you all like punctuated equilibrium. I’ve been yelling this all along, that complex structures spring up suddenly in the record. There’s no sex, then sex; no feathers, then feathers; no insects, then insects; etc. Within a span of a decades to a few centuries? Source. Remember, quick on these time scales is tens of thousands of years.

We don't see nature make systems like this (as you define them above) because our observation time is dramatically limited. The only real conclusion we can draw is that nature does not do this on the time scales we observe. This does not, however, preclude significantly longer time scales. Is design better? Well, that is difficult because our experience with design is with things that were rapidly on a human time scale occur. A way to show design is to be able to show very rapid changes (on the order of decades, although I'll even take centuries or a few millennia) occurring early on in the history of Earth and you would have a stronger case.

No one is arguing that information/entropy can be calculated, that is a concept from statistical mechanics. The controversial part is the claims the author makes using the equations. The definition of "specified complexity" is still quite vague and not quantified.

Stillness, science doesn't work on quotes. So what a scientist said it? It's irrelevant unless a quantitative and hence useful definition is given. Again, what are the units of complexity? How do we calculate/measure it?

I agree, the option to disable the tutorial messages would be awesome.

To summarize, the general consensus is that Wingbolts are very powerful, Kyshaaks are okay but there are better options, and War Tralls suck along with the rest of the Battle Creations.

Exactly as Thuryl said. Even if they are separate people, which I doubt (check your PM) you are still responsible for your account. Letting someone else use it or being irresponsible with it makes the owner still responsible. I can't even remember how many nefarious "little brothers" or "friends" we've seen.

Yes, he was banned and it was your fault because you two are the same person. Good day.

You cannot pass Turabi, neither can you pass the Western Morass.