dvangennip

As promised a few days ago, I ran into the same sound related segmentation fault, so here is a more complete log. It happened at the start of a match (but not the first I started this session, so not a fresh start of the game). sound_manager_segfault.txt

Although the Spanish inhabit the same lands as the Iberians once did, strengths and weakness may have changed over time. I have no knowledge of the subject, but if you do you can always point to reliable references, so people can consider changing something. For now, I checked and the Iberian food gathering and hunting (as well as mining) is not changed from the defaults, so it is not less than other civilisations in the game. Apart from that, balancing the civilisations still has to be done, so it could be imperfect for now. The Iberian units might be a bit more expensive (haven't checked), but that probably means that per-unit strength is better as well. Adjust your tactics I'd say BTW, what do you mean by hunters? Archers? All citizen-soldiers and cavalry can hunt animals and collect meat, so I would say it is not missing at all.

Ok, so could you explain how this insight translates to possible, clear changes or additions for the game? Because I may be confused, but what do you think is exactly wrong with the Iberians and Celts currently in the game?

Well, I have been looking at that recently. Except for a few religious boats (and this reconstruction) there are mostly wall paintings to go from. At any rate, Egyptians had many ships because the Nile was their lifeblood. But river ships/barges could be different from seaworthy designs; the Nile is relatively calm compared to the Mediterranean Sea. There is a problem though, a few actually: further south the Nile is blocked by cataracts, which means a ship has to stop. Goods were either moved to another ship on the other side of a cataract, or the ship was dragged over land, or taken apart and reconstructed. Whether their late design ships could truly stand up against the triremes (and similar designs), I doubt it. Otherwise more states would have copied Egyptian designs. Also, no complete ships have been found. Not even biremes and triremes have been found, only pieces. The wood was probably repurposed instead of leaving it for us to see.

Worse, probably. Knowledge of ship design degraded during and after the time period of this game, at least where it concerned fast and light oar ships such as the trireme (very expensive to build and maintain). There were other types besides the bi/tri/quinquiremes, but navies all used these types in large numbers (Athens was said to have 300 triremes at their peak). Military transport ships were just merchant ships (those can also be used in 0 A. D. to move units). Later ship models such as the quinquereme indeed had ballistic capabilities, other ships such as the trireme models had no place nor the capacity for serious on-board weaponry. Practically it was hard, because the ship had to be pulled ashore each night (no food storage + soaked up water because of light wood used). Imagine having to do that... As for the attack capabilities, there is some work to do, but some day it will be fine For now, ships are like all other units and must face the direction of their attack.

Perhaps adding a flag / two flags to the civil centre in some way (one for town and city phase) does the trick? Just like garrisoning units shows a flag on a building, something similar can be shown on the civil centre. To reduce workload, a modification of the civ's garrison flags could be used, as I quickly did in Photoshop below:

There are some tickets filed on ships, matching your suggestions (garrisoned units fire arrows) (direction of attack) (death animations). Well, there are a few more, but at least consider your requests as noted. However, garrisoned infantry already counts towards extra arrows fired (Trireme default is 3, +1 for every additional unit garrisoned). These all go in the same direction, plus the ship needs to point towards the target. A defense tower does not suffer from this behaviour, but cannot be tasked to attack a specific unit or structure. If a ship looses that ability, it may be more versatile (literally all round) in defence, but less so in attacking (only the default fire power can be "channelled"). Persian, Carthaginian, Greek and Roman bireme, trireme and quinquereme ships have much in common, yes. But this appears to be a result of a technical solution considered the best fit by multiple civilisations (see also info on Triremes and Galley design). Most were derived from successful designs by the Phoenicians or even built by those people (as the late period Egyptians had, due to a lack of quality wood). A design teacher of mine once stated that if your goals are the same, you probably end up with more or less the same solution (as to why understanding of the problem and goals is key to come to different solutions). The Celtic and Iberian ships are clearly different though? What would be your suggestion for improvement?

I have no influence on decisions in any way, but I believe this is not really considered as it would triple the amount of modelling required for every civilisation. Plus, existing buildings do not change in real life just because the village got bigger The Britons civil centre does this, as do a few other buildings. This could be added where it is relevant, but there is a slight performance cost.

I got some errors today, I believe sending some citizen-soldiers to mine triggered the segmentation fault. I forgot to save the info from the Apple application error window. If it happens again I'll save that and post it here. Overall the patch works fine (which is great, to have sounds on OS X ), except that it appears music starts playing at full volume and then fades out to a sustained lower volume. I would expect the music to fade in from 0% volume? This happens at the start of the game, and basically every time the track changes (for example upon start of a game). The automatic switching of tracks (during a game) once took a long time, with no music playing for a couple of seconds.

Could this be solved by resetting the SVN of the game, more specifically the Iberian template file for the tower? Or perhaps just replace that file with the current version? This seems the main error, the result is a result of that: ERROR: CXeromyces: Parse error: structures/iber_wall_tower:1: Expecting an element Static, got nothing ERROR: CXeromyces: Parse error: structures/iber_wall_tower:1: Invalid sequence in interleave ERROR: CXeromyces: Parse error: structures/iber_wall_tower:1: Element Obstruction failed to validate content ERROR: RelaxNGValidator: Validation failed ERROR: Failed to validate entity template 'structures/iber_wall_tower' ERROR: Failed to load entity template 'structures/iber_wall_tower'

For Windows there are regular builds but not every night. For all platforms you can build the game yourself, just look at the Build Instructions. It does require a bit of knowledge on computing, especially if things go wrong.

Looks good! I have recently been thinking of doing a mod of the Kingdom of Kush. The Kushites lived further south of the Nile and were around during the timeframe of this game (±1500 BCE until ±350 AD). Their buildings, culture and customs have much in common with the Egyptians, as (for example) the 25th dynasty of Egyptians were Kushite rulers (things went back and forth for some time around 800-600 BCE). I figured that would be nice civilisation as it had contact with some of the in-game civs, plus it would a nice way to sneak in Egyptian style structures while staying historically accurate I had not yet seen this mod (which appears quiet), so I could take a thing or two from the things here I will post a new discussion in a few days, when I have taken the time to sift through reference images and a rough design document.

Regarding your first comment, do you know you can adjust the angle of the camera by pressing Ctrl+S or Ctrl+W? This way you have full control without automatic adjustments. As for the unit variety, I haven't had trouble with that (but I may be a clueless 'all the units!' attacker). Some of the variety is due to the units' class I think. When they start they are basic fighters, after some experience they become advanced, and finally elite. The little chevrons in the unit picture show this. Higher ranking units have better (different) armour and outfits, get helmets instead of caps, and other small changes. At the least by double clicking on a unit you can select all similar units on screen, that is what I normally use.

I will create a ticket in Trac for this, pointing back to this discussion/post. The errors come up at some point and normally, if no breakpoints are set, stop after about 20 of them (thus, nothing continuous it seems). While I was using gdb this afternoon, it appeared there were more errors (it didn't stop before my patience did ). Perhaps your suggestion that a temporary hickup (e.g., a frame taking more time or a breakpoint interruption) causes the errors is in the right direction? Anyway, the errors are non-fatal and I haven't noticed any negative side effects. So, especially if no one else has seen these errors, let it be. Edit: Trac ticket #1567 was created for this issue.

It is the native resolution of my external monitor (as I used it with Windows, so let's blame the drivers for the difference).

Found it! For everyone, set windowed=false in the config file. Using gdb was easy, so I have attached a logfile. Although I was persistent in continuing more than three times, the stack trace appears very, very similar for the errors. At some point I stopped the program though. Anyway, hopefully it gives a clue where to look further. I noticed today that the errors do not come up straight away, but rather after playing a game for about 10 to 15 (?) minutes. patch_gdb_log.txt

Do you play the regular Alpha release? The current development version (in the SVN repository) implements gates almost exactly as you describe So you can expect it in the next Alpha release. No visual gatekeepers though, and I do not think a gate sacrifices units when enemies are near. One or two enemies slipping through are not a big problem with a defense tower nearby.

The OS indeed matters. On Windows 7 my MacBook Pro of 2007 can get up to 35+ fps, with OS X it struggles to get much beyond 25 fps (usually less). This seems mostly graphics related (moving away from crowded parts of a map has a noticeable effect on fps), but at least my 128 Mb Nvidia 8600GM could be considered just enough (minimum requirement). I have to admit I may stress my system a little by playing at a resolution of 1920x1080, I don't think it was meant for that Anyway, performance measurement should take the resolution into account. Perhaps it is easier to get an idea of systems that have difficulty running the system? On the other hand, my old desktop (AMD Athlon64 (single core) 2.2 Ghz, 2Gb RAM, 256 Mb Radeon X800XL) can barely run the game as it tends to be CPU heavy. When pathfinding/AI performance improves a bit it may be enough, so prematurely setting this in stone may not be the best option.

I will have a look at it tomorrow, it is past midnight here. Will post the results if I manage.

It is something I feel is unnatural in the current interface; having to look at the left to adjust the choice, and seeing the resulting change on the right (with a larger monitor this distance effect gets worse). So, yes, I would agree to put the drop down where the action is There appears to be plenty of space since most map descriptions are quite short.

Ah, that was the confusion No, those 'datagram length' errors have not come up in the vanilla code. I checked the game and Atlas. I do not know of such a key combination in OS X. The behaviour only shows in 0 A.D. Just to be clear: the window is not going anywhere (fullscreen), it is the in-world view that moves similar to what happens if the cursor would reach the edges of the screen. In itself it is not bad (no need to move the cursor a lot to adjust the view a little), but it makes it difficult to only select military units. If this behaviour is not in line with how it works on Windows and Linux I think it should be adjusted (if possible). As for not being able to play the game windowed, I would expect this to be a minor issue (that is to say, not so important to me to get fixed).

Yes, sorry if I wasn't clear on that. The flickering was there with the vanilla code and preferglsl=true. Actually, it is even worse as there is also white flickering on (bright?) parts, such as roofs and trees. See the screenshot below, taken from the same scenario with vanilla code and preferglsl=true. This patch is thus not making matters worse in any way. The patch could be said to improve matters, even though the terrain (dark) flickering remains P.S. Thanks for the info on the insubordinate Alt key.

Ah, I checked the vanilla code and you are correct: the flickering is simply the result of a preference for GLSL. It is present in the regular code as well. I must have missed the earlier discussion on that. Now, this one is interesting. Alt+Enter does not work on my Mac So windowing the application cannot be done. Going off-topic for a bit: selecting only military units does not work by bandboxing (left click + dragging the mouse) + holding Alt, if I start with pressing Alt. If I drag first, then press Alt, then let go of the mouse button, it works. Pressing Alt first, then dragging, results in panning the view. Although it is completely unrelated to the discussion here, I wonder if this is the correct/desired behaviour or that a ticket must be filed? Back on topic. Apart from the issues with the shadowmap and errors everything else looks fine, very fine

I have tried the latest version of the patch, which compiled fine. In practice there is noticeable flickering, between the good look and the thing shown below: Moving the camera, its rotation, or its angle can solve the issue. The flickering is also shown on the reflections of land area on a water surface. The console is bombarded with error messages (all similar, so I won't repeat it here): The system is a MacBook Pro, mid 2007 model, 2.2 GHz Core 2 Duo, 4 Gb, Nvideo 8600 GM 128Mb; running OS X 10.6.8. Especially where it concerns the graphics card it's not a fancy system, so perhaps I should try to disable a few things to see if matters improve? Edit: the same map in Atlas does not show the same flickering, until I start the simulation. Then the situation is similar.

I have just gone through all entities in the editor, via its Actor Viewer. I saw no other texture issues, so let's hope the Carthaginian houses were the only actors affected. Oh, didn't see the post just above this one. Well, that confirms my findings