zoot

You should use Git http://learn.github.com/

Out of curiosity, do you never buy from online stores that only take credit card?

There's some tips here as well: http://www.wildfiregames.com/forum/index.php?showtopic=15796entry236219

Excellent move, well done.

Yves, obligatory spelling fix: https://github.com/z...9606b3ac98.diff

It seems to work for minor changes, but oh well. Here's a different suggestion then: Would it be possible to show line numbers in the call stack? It can sometimes be helpful to know not just what function made a call, but also what part of the function made it.

I've done a bit of testing, it's working really well. A few nitpicks: - The game supports "hotloading", meaning if a loaded script is changed on the disk while in a game session, it will be reloaded. Any chance the UI could reflect this? I assume the UI polls the debugging server anyway to see if it is break, so maybe it could poll for updated scripts too? - Can we fit a 'hostname' field somewhere in the UI to allow the user to connect to a different host than 127.0.0.1? Would be useful for people with multiple computers. - The place to click to set a breakpoint is not well-defined visually. If I click in the far right side of the line number, it doesn't set a break point, but if I click in the far left side it does.

Wow

Remember to do this (or something equivalent for a permissive license of your choice).

It has:

Ah, I see. It just doesn't step through the functions themselves...

Hmm, so will this effectively skip the line? Or what will happen if the line is something like: "a = b()"? What value would a be assigned, if any?

Unfortunately we can't expect 24/7 support for a non-commercial engine It's not really important how many computers you have tested it on, if those computers don't support the feature you are looking for. In my own experience, not all drivers/card do mipmapping equally well, and that often leads to the blurred textures you are reporting on lower to mid-end systems.

This is due to the AI consuming too much memory. It's a known issue being worked on: http://trac.wildfire...com/ticket/1650 In the meantime, you should try to play with only one or two AIs at most. Or multiplayer (vs humans only), which is not subject to this issue.

This link points to an arbitrary post in the thread. Here is a link to thread itself: http://www.wildfiregames.com/forum/index.php?showtopic=16991

Not CSS sprites The ones in the current UI engine.

Let's be abundantly clear: replacing the current UI engine with something else will not be easy. Anyone who thinks otherwise should just go ahead and do it. The fact that SpiderMonkey and Gecko both happen to have a Mozilla logo on them does not make it any easier to change all the existing code that relies on the old engine. Since no one has been able to come up with a HTML mockup of how the UI could look, I'm a bit skeptical that it will ever be suitable for this purpose. If we can't even come up with the HTML, how should we be able come up with all the deep C++ integration code it would require? That said, I still think it's worth considering overhauling some of the existing UI engine code. It has many little shortcomings (like not being able to change colors dynamically) and the XML format isn't overly easy to grok (what are 'sprites'?).

Maybe someone can make a JS plugin for Codeblocks, then. Some of the code from the C plugin can probably be borrowed, since the syntax is similar. I guess that could work. If the debugger prints some useful code to stdout when it breaks (like: "DEBUGGER: In break on line x in file y."), IDE plugins can parse that and know when to connect.

Could it rely on battle detection? Like, for every player who is in battle, add x slaves per turn.

Eclipse should be cross-platform too - though it is a bit bloated. Anyway, I have a feature request: how about a way to set breakpoints through a command-line argument? For instance, pyrogenesis -breakpoints=/path/to/breakpoints.txt And then the debugger would set the breakpoints defined (somehow) in the file /path/to/breakpoints.txt. This would make it feasible to use the debugger with the -replay argument (to debug a recorded commands.txt)

Then specify how it worked in the situations discussed earlier in the thread. (And no, I only played AOEI and II.)

Well, discussions in the abstract have their merits, but they can only get us so far. Surely, people would be able to make more educated arguments if they had tried both options in practice.

You probably shouldn't be allowed to - the building preview should turn red.

Oh, I see. Yeah, in both cases some work-around for the vertical terrain drops is required.

Lemme put on a broken record: I wish we had Git, so everyone could test both options on separate branches. There, I said it