k776

Ok. I've gone ahead and created a Flattr account. https://flattr.com/thing/419240/0-A-D-

I like AoEO's approach. You build the farm and it keeps producing until it's destroyed. That said, the reseeding adds more gameplay features (but with it more micro-management). So I'm about 60/40 in favour of unlimited farms at this point.

The game is broken on Mac Lion :-( It's forced to windows mode, and doesn't work very well. And as theShadow pointed out, data needs to be in the users home directory, which is a horrible bug that prevented me from finishing my automated packaging script.

I'm going to try write a Ruby on Rails app with a MySQL database which can receive, process and display the data, along with some fancy graphs, like highcharts.

runner007 is what I've come to know as a copy bot. He joins, he copies other peoples posts (so not his own original content) and then pastes it as his own. If you search up threads, you'll usually find the original post by the non-spammer who posted it. I've now banned him, and deleted all his posts. So, back on topic now....

@Mythos @Pureon And you added a ticket for that bug if one doesn't exist yet? Whats the ticket #? Maybe we can get someone looking into this for Alpha 8.

So, you want to allow copyright infringement... ? Either way, a law in NZ already passed that has peoples internet cut off permanently if someone infringes copyright just 3 times.

I've been thinking: Should the territory size by the factor used to determine they Line of sight? Since at the moment, when you start a map, the civ center LoS is smaller than the territory size. Ideally, if you have the territory, you can see everything within it. We'd still have FoW/SoD on neutral and enemy territories. Does that make sense? That we, we can get rid of any line of sight XML elements, and make the whole thing dynamic. Might work better.

I've been having issues on my macbook. When I use the update-workspaces-new.sh script for Premake 4 support, and I compile everything, there is no errors, but the binary binaries/system/pyrogenesis is no longer being created. When I removed the old one, and ran make again, it worked with no errors, but the binary still doesn't exist. It does seem to be making a binaries/system/pyrogenesis.app package, but when I run it, I get an alert box saying it failed to load, and if I hit report, the following shows up: http://pastie.org/2265572 If I go into the package, and try run binaries/system/pyrogenesis.app/Contents/MacOS/pyrogenesis binary manually, I get the same error. Copying the binary to binaries/system also has the same issue. So right now, using the new premake 4 stuff, I'm unable to play the game after compiling. Any ideas? Edit: Added more details about the error Edit 2: Seems I get this error when using the old premake 3 as well. Edit 3: Looks like an issue with SpiderMonkey. otool -L on the premake 3 binary looks like it's looking for spidermonkey in /usr/local/lib rather than the current binaries directory

Foundations do not contribute to weight. Weight only applies to completed buildings, else as you described, you'll get cheating tactics. Ideally too there would be a system based on the aura size which prevents people from placing foundations for civ centers too close together. You cannot have two civ centers having an overlapping aura, so a system needs to be put in place to stop placing of foundations if its too close, but that system can wait until the rest of the territories functionality is in place. So I like your idea of building the weight up to maximal level (which covers the edge cases). But what if a building is damaged? Does it's weight decrease? If so, could this be tied to health? Maybe weight is 1/5 of the health of something. So a civ center with 1000 health would have 200 weight... or would it be too problematic? Having it's own <Weight> value would increase flexibility I guess, so maybe it's pay not to tie it to health? Either way, do you have enough to go with and get something working?

Nicely written Michael. I think the dynamic boundaries will make the gameplay more exciting than static settlements. @Philip: You'll know better, but to me, implementation wise, each tile would store the weights of each player in the tile data. And the player with the greatest weight for that tile is the one who "owns" it, and the border runs along the tiles edge. In the case of a tied weight, the tile is shared and the border runs through the tile. e.g A 1 2 3 B A and B are opposing player buildings, 1 2 and 3 are tiles between the buildings Simple Case: If A and B have the same weight and aura, then A gets tile 1 and half of tile 2, B gets tile 3 and half of tile 2. Complex Case: If A has weight 100 and aura of 2, then tile 1 is weighted at 100, tile 2 is weighted at 50, tile 3 is weighted at 0. If B has weight 300 and aura of 3, then tile 3 is weighted at 300, tile 2 is weighted at 200, tile 1 is weighted at 100, tile A is weighted at 0. With those values, A owns half of 1, and B owns the other half of 1 and the whole of 2 and 3. So: Tile weight = ( ( aura_size + 1 ) - distance_in_tiles) * (building_weight / aura_size) Note: The (aura_size + 1) offsets the tiles so the first is the one next to the building, not the one it's on. (note: bad math? Tell me a better way :-) ). Make sense?

MyBB is great. I used to develop it a few years back. I personally would make the portal.php page of the forum the homepage of 0ad.me, thus transforming the the forum into the blogging software... You simply tell the portal to pull posts from an announcement / news forum, lock that forum down so only you can create threads in it, and you're good to go. I did it for this forum: http://www.wildfiregames.com/forum/index.php?app=portal That way, you only have one piece of software and more importantly, one set of themes for the entire experience.

It's been less than 12 hours since your first post. Give it a day for people around the world to respond. As far as haXe goes, I'd have personally gone with CoffeeScript (http://jashkenas.github.com/coffee-script/) if I were writing code that compiles to JS.

:-( It means you're not playing the game ;-) It's fine, just as long as they are meaningful comments (not spam or +1 or bump posts).

Yup, I think after the premake 4 stuff has been reviewed and committed, we should work toward proper Mac support.

Nicely written. I have a far better idea of how it works now. Why can't the long path finder simply pick it's path based on the blue areas? If performance is an issue, why not introduce a third path finder? long = based on the tiles medium = calculated for every 25% of the long path short = calculated within the units LOS The problem I still see with having a long path finder though is that units could walk many times more distance than they needed to if a line of trees had only a single hole. Is there more advanced, faster algorithms that can be used?

Hey. Thanks for sharing the code. I don't have time to drill into it too much yet, but looking good so far! From a cosmetic standpoint, the code styles (indentation, curly braces) and file names could do with some unifying (different ways it's done at the moment). I personally use 2 space indentation, open curly brace on the same line as the function is defined, and one class per file (i saw one file with like 3 classes in it). The more consistent the code is, the better. The files could do with being split into folders too. e.g. rootbot/ _init.js data.json rootbot.js economy/ economy.js plan-buldings.js .... military/ buildDefence.js ... Other than that, awesome work. Can't wait to try play it later today.

Yes, the map was too big, and your computer doesn't have enough RAM to generate it the game hasn't set aside enough memory to generate it. What are your computer specs? We should probably add limits so this type of thing doesn't happen.

Sure, we'd be happy to take a look. It'd be great if you could release the whole source code under the GPL license the rest of the code is licensed with. That way, if you choose not to continue to develop it after you hand in your assignment, others might be able to pick up from where you leave it. Of course, you're more than welcome to continue developing it. It would be nice to be able to include another AI with Alpha 6. :-) Would you say the AI is less than 2 weeks from completion (or atleast, to a point of being playable without any errors)?

Some speed boosts would be nice. 4 AI = slow game :-( Not sure if that's because of the AI system or specifically JuBot though. But any caching you can do would help.

@Yves: Philip looked into integrating CMake a few weeks ago. Not sure where he got with it. You may want to have a chat with him on IRC about it.

Interesting. I thought otool might have had to be used in this case. Would you be interested in helping to make 0 A.D. a first class app for Mac? If you'd like to help out, would you like to try edit the makefiles, or creating a script that automates the otool changes. Maybe the end goal is a 'make mac_package' command that create a nice app bundle? Mac is one of the few packages we don't have at the moment, so it'd be great to have these, as you've just done with Alpha 5. If possible though, the binary should work on Leopard or Snow Leopard, and on 32bit or 64bit. That should cover most Mac users.

Nice. I'm a Mac user, and 0 A.D. team member. Would you mind sharing your process for packaging the game so that, if I need to, I'll be able to do it for others. Specifically, how did you get it to work with both 32bit and 64bit machines, how did you solve the hard coded system library locations? Did you bundle them in the package?

http://trac.wildfiregames.com/ticket/836 I remember having a discussion about it. I cannot remember the outcome of that discussion. IIRC, the best option might be to include enet 1.2 into the 0 A.D. source code (or upgrade to 1.3 but still bundle the enet source code).

Moved to the Development & Technical Discussion forum. And entities already have a WinCritical or something like that on them to indicate what needs to be destroyed in order for you to win. I think, rather than make the AI try to resign, have it try to sensibly rebuild in a new place, i.e. it retries to rebuild elsewhere