k776

Of course they're usable and should be included. Perhaps I wasn't clear enough with my original message, so my mistake.What I meant last time was "Do you plan to finish them to a point where they can be committed and used ingame soon?". I would love to see these ingame, and usable in Atlas.

Pureon, even if you committed to a temp folder in the internal section of the SVN server until they are finished. Really wouldn't like these to get lost if, like Mythos, your computer crashed :-( ...

Try revision 8940. Some fixes were made that might let it compile for you now.

The big question is, will these make it into the game? I'd love to have a map in the next release, which only had one player, but was an entire city, to demonstrate how nice it can be. Pureon, would you like to do that? Import the work you've done into the game, and then make a map demoing all the experimental scenery.

Yes, I noticed that too. I think some JS files might be missing from the installation.

:-D Excellent work. How close is it to being fully completed so it can be committed?

haha. Well I personally like http://mybb.com I used to help develop it for about a year, it's open source, and very good! But we have a license for this, so won't be switching anytime soon :-P

Not that I know of. I didn't go searching for one. I based my AI approach similar to how a browsers DOM model triggers events like mouseover, and onclick. I'm not entirely sure, but I'd say it'd speed it up. As I undersand it, if you leave the current AI implementation just staying there, it has to loop over units each turn seeing what has changed and respond accordingly. It's more code, and more processing. And while not severely more, maybe enough to show notable different?With the event/hook system, the AI would get the info it needs. And as shown in the Pastie i sent in an earlier post, it'd only send events if the event is being listened for, so if there is no event, then nothing happens. A blank AI file would then have no extra drag on the system, and events would be much simpler for the AI writer to plug into. Of course, the current system could be easier maintained, and run alongside the event/hook system. But I would prefer to do it event based, as it'd make the AI much more responsive to things that happen. e.g. Imagine a unit is being attack, a unit just died, a building is being attack, and a unit just run out of resources to mine In the current implementation, you'd need to loop over every single unit, and check if their health is decreased (which means storing a list of previous units). That uses memory and time. With the event system, you get that info delivered to you from C++ when it executes that action, so you don't have to check, it'll know and tell you when. At least, that's how I hope it'll work. IT'd be great to have Philip comment on how it could actually be designed, instead of theoretical code...

That is some excellent work! Keep it up. It'd be nice to see bridges in Alpha 5.

Are you willing to take the chance though? If a good portion of them (1k) are spam bots, 1 a day means fighting spam for 3 more years :-PI'd much rather do what we are, let people show activity, and delete those who don't. If anyone gets deleted and they come back, they just re-register. And that way, we can know for sure that spam from existing users won't be a problem.

I think pointing them to this forums Feedback forum (via working link) would be a better idea. Better control for us to monitor and filter.

Eventually, yes. It was more important to upgrade, than not to because of a theme.

After 48 hours, we're like to have lost about 4k+ users, when we prune old accounts. We're doing this because quite a lot of them are possibly spam accounts. We don't want to have to battle spam forever.

Cool. I posted in another thread, but it's important we don't send info without their permission. It needs a dialog asking them if it's ok!

haha. Thanks for responding. We're looking to clear out all spam accounts, and the only way to do it is ask people to post. So thanks :-)

I've filed a ticket so this won't be forgotten. http://trac.wildfiregames.com/ticket/732

Yes, it uses the old database, which is no longer linked to this forum. The web team need to point the site at the new database. It could be a few days.

I've been discussing with Philip about a possible rewrite of the AI code, so it uses an event/hook system. I did a quick code example of how I thought it would work, here: http://pastie.org/1553793 The idea is that it'll allow AI to be event driven, rather than checking every case. e.g. on('unit.attacked', function(unit) { defend(unit); }); The system would be thread safe (as each AI runs in it's own thread), and it wouldn't need any serialization of the AI state, as the save game would just start firing off events again, which the AI would respond to. It would also allow users to write their own scripts, which could listen to those hooks, and act on them. e.g. on('unit.built', function(unit) { if (unit.hero) { Chat.post('Watch out, I just built a hero!'); }); This type of thing could open up ways to all sorts of cool assistant scripts, like alerting you to an attacker, and showing a dialog to jump to it. e.g. on('unit.attacked', function(unit) { GUI.prompt('Jump to a unit being attacked?', function() { GUI.jumpto(unit) }) }); Anyone have any thoughts or concerns on the matter?

Indeed. A gradual reveal of the building would add more realism to the game, and make it more enjoyable. If not done already (I'm pretty sure it does, but don't have time to check), apply this gradual reveal to all entities (trees, hills, buildings etc).

Thanks everyone for being patient. The forum has been successfully upgraded and you can now start posting again. If you notice any issues, please report them in this post and we'll take a look as soon as possible.

Alright, then we support hardware no older than 3 years? Sounds about how long someone might have a computer before upgrading to something new. But I agree, we should collect user data. Something in the game, which on loading, prompts the user "Help us improve, send us anonymous usage data", send cpu, gpu etc stats. Note: It need to prompt them, we cannot(!) send data without their permission, and it should only be done once, so they load the game, and accept or deny, it shouldn't ask again when they load a second time. These changes should be in Alpha 4 if we want any hope of tidying up that render code in Alpha 5. If you need me to, I'll write a Rails application (or PHP, but I'd so much more prefer Rails), which can accept the data packet in JSON, parse it, and store it into a MySQL database.

Here's my two cents. Supporting old hardware is one thing, making it looks best is another. If a graphics card is too old, and doesn't support things for FOW or Shadows), the game should still run on it, but with shadows disabled, water reflections disabled, and FoW becomes SoD. So the idea is, the newer the graphics card, the more graphic features is 'unlocks'. I don't fully understand all the proposals, but sounds like #1 and #2, you could test very easily. if (GL_MAX_TEXTURE_UNITS < 4) { fow.opacity = 0; fow.colour = rgb(0,0,0); shadows.enabled = false; water.reflections.enabled = false; } if (!GL_ARB_shadow || !GL_ARB_depth_texture) { shadows.enabled = false; } 9 lines of code, and you can get rid of dozens of lines of old code that tries to support rendering where GL_MAX_TEXTURE_UNITS < 4, while still 'supporting' (making it runable) on old hardware. As for base line requires, 512mb of graphics is pretty common these days, and most with that much RAM should support the proposals?? So it might be worth saying "minimum: 256mb, recommended: 512mb".

Well, that right there is introducing stances. Aggressive = vision range, stand ground = attack range, and defensive = only if they attack first. But assuming both aren't implemented at the same time, the initial work should be within the closer attack range. Again, stances will change this. But for now, if an enemy is within the attack range, go for him (excludes animals of course) Not by default, but if the other player makes it retreat, sure. Depends how complicated it is to find if the path to a unit is blocked. If it's simple to find out if the path is blocked (that is, they can't get to it without going into FOW, which also means enemy units who disappear into FOW stop being chased), then you retarget to the nearest, strongest enemy. Ideally, they'd know right away if they are blocked, but given the slowness of the path finder, in the case where the archer disappears in FOW because the units are surrounded and can't get to him, then the moment he's gone, they change target. That should suffice for now. Correct, and they're clever tactics, which will encourage people to focus on their units when making an attack, instead of just leaving them. If they are not forced (i.e. user has not specifically told them to attack that archer while they were attacking something else, command_forced = false), then they should target the stronger unit. If archer 2 is stronger than archer 1 they are pursuing, then they attack archer 2 if within range. If archer 2 is weaker, they continue with archer 1. If the units are forced to attack archer 1 (command_forced = true), then they ignore archer 2 until archer 1 is dead, at which point, the command_forced is then false (as the command was completed) and they retarget the strongest unit.Each attack scenario I play in my head works as I think it should using the above defined patterns and the use of the command_forced flag. I think, if implemented, it'd make the combat portion of the game much more enjoyable and useful. Then when stances are implemented, it'd just be some minor tweaks to what was implemented to make the above work.

Agreed. The ideal automated attack order would be: * Enemy warriors * Enemy offensive buildings (town center, tower, fortress) * Enemy women * Enemy non-offensive buildings (house, barracks, farms etc) * Enemy unharmful buildings (walls/ gates) If there was something more important in sight, your units would go and attack it. That said, you should always be able to overwrite their target, and have it stay. A bug at the moment means you might be being attacked, and ty to retreat, but it won't retreat properly. Your units will turn around and try to fight again. I think: * If a unit is given an order, then a unit tries to attack it, it'll ignore said order and defend itself * If a unit is in a fight, then given an order, that unit should follow that order no matter what (even if it means he's being killed from behind while attacking a wall). Seems that, to implement this, you'd need three things: * You'd need a dynamic property on the units, "command_forced" or similar, and set to true if unit is fighting when he receives an order (i.e. you tell him to retreat). * Adjust the nearby unit detection code to automatically attack units, sorted by priority (as above), except if command_forced is true. * Adjust the unit code to set command_forced to false when the unit finishes the command he was told to do (so he goes back into defensive mode).

Correct forum, no advertising on the profile, and a decent looking email address. Looks legit.... @Chickenwings1415: Sorry for the skeptical reception. We've been having quite a few spam bots show up recently making short messages like the one you did. How'd you come to find 0 A.D. ?