dvangennip
-
Posts
158 -
Joined
-
Last visited
-
Days Won
5
Posts posted by dvangennip
-
-
Well, First Iberians are not good harvesting and im confused because we are one of the best gatherers and harvesters. For this iberians arent good for me and the warriors of iberians cost so much. Iberians also missing hunters that is important to spanish people because in Spain there are many hunters. Celts are good but I think they need to improve their blacksmithing and fishing.
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.
-
Yeah¡ That`s correct but I am spanish and the iberians are too bad in farm and cultives. Sorry but i have a garden and one terrain of cultives. Recollect food in Spain is very imporant since of the iberians, Cetiberians was existed in my willage. Because I write this post. Thank You
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?
-
Howabout boat designs in the nile river?
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.
-
Ship design did not really change till the late middle ages as there was no need to change,sailors are a very conservative group
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. -
When I play, the way to know which phase my enemies are is normally observing which buildings/units the enemy has.
For your own visual feedback on which phase you are, some subtle changes to the GUI artwork could do the trick IMO
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:
-
Hi i think 0.a.d lacks some historical accuracy with ships. When archers are garrisoned they would fire from the ships. I think this can be implemented similar to how siege towers work in the game since garrisoned units do not follow your orders on who to fire on and can fire from any angle. It is pretty cool seeing a siege tower of 20 archers fire in a 360 degree radius in the enemy city
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").
There seem to be no variances between ships from different races.
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?
-
Hi i dont know if this is the right forum but i would like to make an art suggestion. I think it would be great if when progressing from one phase to another it changes the building model from one to another more sophisticated looking building. I hope this is a planned feature.
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
If possible it would also be great to add effects like smoke coming out building chimneys as an optional graphics feature
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.
- Error creating initial buffer !!
ERROR: error loading sound: pathname=audio/resource/mining/mine_stone_12.ogg, error=No error reported here
- Error creating initial buffer !!
ERROR: error loading sound: pathname=audio/resource/mining/mine_stone_13.ogg, error=No error reported here
- Error creating initial buffer !!
ERROR: error loading sound: pathname=audio/resource/mining/mine_stone_14.ogg, error=No error reported here
- Error creating initial buffer !!
ERROR: error loading sound: pathname=audio/resource/mining/mine_stone_15.ogg, error=No error reported here
- Error creating initial buffer !!
ERROR: error loading sound: pathname=audio/resource/mining/mine_stone_16.ogg, error=No error reported here
- Error creating initial buffer !!
ERROR: error loading sound: pathname=audio/resource/mining/mine_stone_17.ogg, error=No error reported here
- Error creating initial buffer !!
ERROR: error loading sound: pathname=audio/resource/mining/mine_stone_18.ogg, error=No error reported here
- Error creating initial buffer !!
ERROR: error loading sound: pathname=audio/resource/mining/mine_stone_19.ogg, error=No error reported here
- Error creating initial buffer !!
ERROR: error loading sound: pathname=audio/resource/mining/mine_stone_20.ogg, error=No error reported here
- Error creating initial buffer !!
ERROR: error loading sound: pathname=audio/resource/mining/mine_stone_21.ogg, error=No error reported here
- Error creating initial buffer !!
ERROR: error loading sound: pathname=audio/resource/mining/mine_stone_22.ogg, error=No error reported here
- Error creating initial buffer !!
ERROR: error loading sound: pathname=audio/resource/mining/mine_stone_23.ogg, error=No error reported here
- Error creating initial buffer !!
ERROR: error loading sound: pathname=audio/resource/mining/mine_stone_24.ogg, error=No error reported here
- Error creating initial buffer !!
ERROR: error loading sound: pathname=audio/resource/mining/mine_stone_25.ogg, error=No error reported here
Segmentation fault
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' -
So there is downloadable nightly build? Wow, haven't tried yet...
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.
-
My instinct would be to open a bug report for this and let it be for now (especially as the errors don't seem to be harmful), though maybe that wouldn't be the best way to go about it. Any other programmers have thoughts on this?
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.
-
Apple's openGL drivers are notoriously slow. I think you may win some FPS's if you play at the native resolution, though (compared to slightly lower).
It is the native resolution of my external monitor
(as I used it with Windows, so let's blame the drivers for the difference). -
You should most definitely be able to run the game in windowed mode, see http://trac.wildfire...Manual_Settings for how to set it up, the bug should just be that it's not possible to change it while running the game.
Found it! For everyone, set windowed=false in the config file.
You'll need to set a breakpoint on the "CGErrorBreakpoint" symbol (with "break CGErrorBreakpoint" in the gdb console), so the engine's execution will be paused when an error occurs. Type "bt" in gdb to get a backtrace and post it here. Then type "c" to resume execution, until another error occurs. When another error occurs, do the same thing.
There seem to be at least three different messages here: kCGErrorTypeCheck, kCGErrorIllegalArgument and kCGErrorRangeCheck. You need to resume and repeat for at least three times.
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.
-
I don't know if this thread is still active, but I have a proposal. (I'm yet to understand the game design, so pardon if there are some parts that are obviously impossible to implement).
1. Gates operated by two soldiers, each on the sides of the gates. It could be pre-added or garrisoned soldiers, but the most important part is that gates uses their LOS.
2. Every time a unit is in the gatekeepers LOS, the gate reacts automatically. It opens for friendly units and keep closed for enemies. If there are both the gates prefer to be closed (sacrificed the friendly units outside)
3. There is an option for gates to be manually opened/closed.
4. The gates opens slowly, takes about 5 seconds to be fully opened so you could be sure who are you letting inside.
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.
-
Oh well, since I can find literally no info on any of these errors, we'll have to do the digging ourselves.
I will have a look at it tomorrow, it is past midnight here. Will post the results if I manage.
-
I've been looking at it, and I think it would make more sense to put the drop downs below the preview image, wedged between it and the map description field. Anyone?
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.-
1
-
-
I suspect we are talking about different 'errors'
The flickering is a known issue that can be attributed to existing code in the engine. The odd error messages you got ("preposterous datagram length" and all that), however, is not. So we are curious to know if these error messages happens with the vanilla GLSL renderer or only after you have applied myconid's changes.Ah, that was the confusion
No, those 'datagram length' errors have not come up in the vanilla code. I checked the game and Atlas.Myconid explained the Alt+Enter issue, as for Alt dragging, perhaps the OS is using that keyboard combination? (I think at least some Linux window managers use that combination for moving the window or something, so it's at least a possibility) If that's the case you can always set the keyboard combination to something else, but if it's not it sounds like an actual bug which should be solved.
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).
-
Do you get the errors on the vanilla build and preferglsl=true also, though?
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.
-
The flickering is a known issue with the shadowmap, not caused by my changes. It can be ignored for now.
As for the errors, a search shows they're Mac-specific, though there's absolutely no info to go on (none!). Can you at least check if these were caused by my changes? You'll need to compile the vanilla code and make sure that preferGLSL is true in the config (even if they were caused by my changes, there might be nothing we can do about them). They aren't fatal, though, which is good.
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.
Edit: Ok, it looks like these errors have something to do with the Mac's window manager. Loads of applications have them, but there's no documentation and nobody has any solutions for them. FWIW, I found an old forum comment that suggested that changing resolutions sometimes helps (you can hit Alt+Enter in-game to switch from fullscreen to windowed in 0ad), though that's hardly a solution. I think this can go down as another driver/OS bug...
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):
GAME STARTED, ALL INIT COMPLETE
Sat Jul 28 21:42:43 s030454t.local pyrogenesis[36019] <Error>: kCGErrorTypeCheck: CGSDispatchDatagramsFromStream : Bad datagram type 50331648
Sat Jul 28 21:42:43 s030454t.local pyrogenesis[36019] <Error>: kCGErrorFailure: Set a breakpoint @ CGErrorBreakpoint() to catch errors as they are logged.
Sat Jul 28 21:42:43 s030454t.local pyrogenesis[36019] <Error>: kCGErrorIllegalArgument: CGSGetPortStreamData
Sat Jul 28 21:42:43 s030454t.local pyrogenesis[36019] <Error>: kCGErrorRangeCheck: CGSDispatchDatagramsFromStream : Preposterous datagram length 926941440
Sat Jul 28 21:42:43 s030454t.local pyrogenesis[36019] <Error>: kCGErrorIllegalArgument: CGSGetPortStreamData
Sat Jul 28 21:42:44 s030454t.local pyrogenesis[36019] <Error>: kCGErrorTypeCheck: CGSDispatchDatagramsFromStream : Bad datagram type 83886080
Sat Jul 28 21:42:44 s030454t.local pyrogenesis[36019] <Error>: kCGErrorIllegalArgument: CGSGetPortStreamData
Sat Jul 28 21:42:44 s030454t.local pyrogenesis[36019] <Error>: kCGErrorTypeCheck: CGSDispatchDatagramsFromStream : Bad datagram type -1600876732
Sat Jul 28 21:42:44 s030454t.local pyrogenesis[36019] <Error>: kCGErrorIllegalArgument: CGSGetPortStreamData
Sat Jul 28 21:42:44 s030454t.local pyrogenesis[36019] <Error>: kCGErrorTypeCheck: CGSDispatchDatagramsFromStream : Bad datagram type 968884736
Sat Jul 28 21:42:44 s030454t.local pyrogenesis[36019] <Error>: kCGErrorIllegalArgument: CGSGetPortStreamData
Sat Jul 28 21:42:45 s030454t.local pyrogenesis[36019] <Error>: kCGErrorTypeCheck: CGSDispatchDatagramsFromStream : Bad datagram type 1080298820
Sat Jul 28 21:42:45 s030454t.local pyrogenesis[36019] <Error>: kCGErrorIllegalArgument: CGSGetPortStreamData
Sat Jul 28 21:42:45 s030454t.local pyrogenesis[36019] <Error>: kCGErrorTypeCheck: CGSDispatchDatagramsFromStream : Bad datagram type -253748968
Sat Jul 28 21:42:45 s030454t.local pyrogenesis[36019] <Error>: kCGErrorIllegalArgument: CGSGetPortStreamData
Sat Jul 28 21:42:45 s030454t.local pyrogenesis[36019] <Error>: kCGErrorTypeCheck: CGSDispatchDatagramsFromStream : Bad datagram type 994050304
Sat Jul 28 21:42:45 s030454t.local pyrogenesis[36019] <Error>: kCGErrorIllegalArgument: CGSGetPortStreamData
Sat Jul 28 21:42:45 s030454t.local pyrogenesis[36019] <Error>: kCGErrorTypeCheck: CGSDispatchDatagramsFromStream : Bad datagram type 859832576
Sat Jul 28 21:42:45 s030454t.local pyrogenesis[36019] <Error>: kCGErrorIllegalArgument: CGSGetPortStreamData
Sat Jul 28 21:42:45 s030454t.local pyrogenesis[36019] <Error>: kCGErrorTypeCheck: CGSDispatchDatagramsFromStream : Bad datagram type 876609792
Sat Jul 28 21:42:45 s030454t.local pyrogenesis[36019] <Error>: kCGErrorIllegalArgument: CGSGetPortStreamData
Sat Jul 28 21:42:45 s030454t.local pyrogenesis[36019] <Error>: kCGErrorTypeCheck: CGSDispatchDatagramsFromStream : Bad datagram type 692060416
Sat Jul 28 21:42:45 s030454t.local pyrogenesis[36019] <Error>: kCGErrorIllegalArgument: CGSGetPortStreamData
Sat Jul 28 21:42:45 s030454t.local pyrogenesis[36019] <Error>: kCGErrorTypeCheck: CGSDispatchDatagramsFromStream : Bad datagram type 725614848
Sat Jul 28 21:42:45 s030454t.local pyrogenesis[36019] <Error>: kCGErrorIllegalArgument: CGSGetPortStreamData
Sat Jul 28 21:42:45 s030454t.local pyrogenesis[36019] <Error>: kCGErrorTypeCheck: CGSDispatchDatagramsFromStream : Bad datagram type 742392064
Sat Jul 28 21:42:45 s030454t.local pyrogenesis[36019] <Error>: kCGErrorIllegalArgument: CGSGetPortStreamData
Sat Jul 28 21:42:45 s030454t.local pyrogenesis[36019] <Error>: kCGErrorTypeCheck: CGSDispatchDatagramsFromStream : Bad datagram type 1698693376
Sat Jul 28 21:42:45 s030454t.local pyrogenesis[36019] <Error>: kCGErrorIllegalArgument: CGSGetPortStreamData
Sat Jul 28 21:42:45 s030454t.local pyrogenesis[36019] <Error>: kCGErrorTypeCheck: CGSDispatchDatagramsFromStream : Bad datagram type 704643328The 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
New Sound Manager svn patch
in Game Development & Technical Discussion
Posted
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