leper

Well you seem to have found your way around quite well as your first post indicates, and in case you have questions you can also join #0ad-dev on QuakeNet. So I guess it might not be the smallest first task, but it still is somewhat self-contained.

Yes, but that is still trying to work around territories by just hiding territories, not fixing the root cause. So some small modifications to CCmpTerritoryManager should be all of the C++ changes that are needed.

No, you can't modify the TerritoryManager in a mod. You can however supply your own territorymanager.xml file, and also provide your own versions of the related JS components.

That just changes the display of the territory, while I think you'd have less issues by not calculating territory at all.You also shouldn't update interfaces (or rather the components implementing them dynamically. Interfaces are mostly there to allow multiple components to provide the same interface for other components to work with, not to dynamically switch between different implementations. Switching between implementations given that they provide the exact same interface and you only want one of them is however possible if you make that change in a mod where you just provide your modified version of the component and that is the only one used. Could be possible, but a simple change to CCmpTerritoryManager to store whether it is enabled and should actually do something would make this a lot easier.Doing so in a mod would be easy, but I guess this is meant for inclusion in the game at some point and thus using another way would be nicer. Now for how to solve this nicely: You should add a boolean to CCmpTerritoryManager whether or not to calculate territories at all, then return early in most functions, Or simply not subscribing to some messages. I'd suggest storing whether to use territories for a player (since that might be wanted by some) in cmpPlayer and using that and the enabled flag of cmpTerritoryManager in cmpBuildRestrictions to decide whether or not to check territories. IsConnected in cmpTerritoryDecay could need some small modification too. This way we would also support some civs (where we can remove the territory related xml parts) without territory while others have it.

Press enter while the textbox is still focused. See #2451.

If only there was some kind of documentation about what tech modifications are available.

A typo snuck into one of my commits, fixed in r16967.

See simulation/data/player_defaults.json which has a Color property for each player. Note that this file will be moved and renamed as part of #3355. Individual maps might still override those settings. The colors (or rather that file) could also be used as part of checksumming mods for multiplayer compatibility so there is a small chance that such a change might cause an OOS in the future (unlikely but still worth noting). Also note that a change to this file will only affect the player color for you, and any maps you produce that don't save the color will have the original default colors for all others.

No.

Which might have been a no-op, since VS2012 changed the default to use SSE2. Someone actually testing the latest autobuild might help, else we'd need to add /arch:IA32 to prevent it from generating SSE2 instructions (which also disables SSE which might need explicit enabling then). There aren't a lot of doubles in the code, and even floats aren't used in a lot of places. So the benefit of SSE2 on performance might not be that huge (if at all).

It does. The building placement code checks quite a few things (territory, visibility (for human players), obstruction (which currently checks the full obstruction and not just the center point for walls), footprint (for docks), distance to buildings with the same building restriction) of which the passability (pathfinder passablity) is one of the things checked. This passability is dependent on the slope of some tiles (though this can differ for some passability classes. EDIT: All of this only applies to buildings placed in-game by a player. Triggers could just place it there, as can map makers. Big buildings can also have quite some height differences when placed on a slight slope that is still passable, so some extension into the ground is needed.

No. There was not a lot of useful code (not breaking everything, removing error checking, ...) that was worth salvaging. See the (unfinished, though from looking through the remainder there isn't a lot of useful code in there) split up attempt for some details http://git.wildfiregames.com/gitweb/?p=0ad.git;a=shortlog;h=refs/heads/projects/philip/megapatch-split. #2020 and all his other tickets were succeeded by the "megapatch" (if you need a zip file of a patch that is a bad sign, if that zip doesn't contain a series of patches with reasoning (commit messages) for each of them you're doing it horribly wrong). If you take a look at the patch at #2020 and the corresponding commit in the split up attempt you'll notice that there are some tests in one that aren't in the other. Not that this patch or the megapatch was actually supported in any way... So there is no issue with adding a custom allocator utilizing memory pooling, but since from a quick glance that patch is missing some error handling and wasn't tested (it is neither used in the patch at #2020 or in the megapatch) so it could be broken. If someone is willing to work on this I'd suggest taking a look at the patch and then starting from scratch.

Most metal near the southern mountain next to the trading town. An abundance of wood and food near the coast (and on that two islands in the delta), lots of fish in the sea. Either food or wood in the north behind the mountain range. Stone would make the area between the two mountains another place to fight for.

The template changes in http://trac.wildfiregames.com/changeset/16751#file12 should be done for your mod too. That's one of the issues from copying all templates.

http://trac.wildfiregames.com/changeset/16795#file6 made shared LoS using a tech possible, so the template for player changed. You need to do the same. The other errors might be caused by that failure or not, fixing that first would be nice.

Slight variations of the layout niektb proposed. The black area could be a small (defended) mining town with two markets (or one that yields some more gain). The trade route is changed to be more arc-like (ok, not that much in my drawings, but well that is just a rough layout), also having two ports. Maybe having the two halves be a bit less symmetric (eg using one of the two versions below and niektb's version in some combination) would be nice. Giving the mountain/delta area some use (eg metal/stone mines) would make that area another battle ground. Regarding shieldwolf23's suggestion the map layout (by replacing the mountains with rivers or similar) could be changed to reflect Mesopotamia.

Also see http://svn.wildfiregames.com/docs/writing-components.html#component-creation.

You can't rely on other components being constructed in Init() (only system components are guranteed to exits). You also didn't add a GetClipSize() to cmpAttack. Lateness of a timer is just when it should have fired (so how late it is). This is needed since Timers only fire once per simulation turn, so you might have to do multiple attacks per turn for your addition (I'm assuming faster fire rate).

Just define something like this.actualclip = this.clipsize. Then use that size when decrementing and if it reaches 0 set it to clipsize again.

Check UnitAI.prototype.Init. Making the clip size a property of eg the Ranged Attack would likely be the nicest way to handle this, but that would require edits to Attack.js too (mostly to the schema and adding two functions or something):

UnitAI.js is where you should do that change (both setting the animation and doing the actual code change). The INDIVIDUAL.COMBAT.ATTACKING state is where you want to change things.

Rating was disabled because the rating code caused a slowdown of the bot itself once there were some users (~25) in the lobby, which impacted matchmaking itself. Unless that is fixed (patches welcome, guidance offered) ratings stay disabled.

Since all you seem to say is the above and have no public code to show for it nor want to contribute patches but just leech of the exisiting code base and improvements I'm closing this topic since there seems to be nothing worth discussing here (apart from Phyics, but that is OT).

He's in the Alpha 18 lobby, though not for more than 30 seconds most of the time. Also mostly quite early during the day when there's less activity. Staying in the lobby instead of joining, seeing no game waiting for players and leaving might help.

You do know that there is a +1 button on each post? Also full-quoting the previous post is something you should avoid.