Jump to content

Heron

Community Members
  • Posts

    12
  • Joined

  • Last visited

Everything posted by Heron

  1. @av93 I'm not familiar with the terminology, but I interpret "micro" as "I have to think about lots of very minor steps", is that right? But how does this apply to my suggestion? Maybe I just don't see the full picture, but if implemented as above you aren't forced to do anything special. Maybe you shouldn't send single units into the enemy's territory, but you don't want to that anyway. If only cavalry can capture, capturing will be a quite rare event, especially if the enemy still has some defence towers which would most likely kill your units before they could be captured. Concerning formations/heros/females: these would require micro actions (as I interpret it), but they already do so. @wackyserious I see two issues. First, the gap between Champions and basic rank units grows even wider. (Also, I don't think it's fair to say a farmer had a lower moral than a champion soldier.) Second, binding the state of a unit to the current owner requires some extra storage/logic. However, this might be not too problematic.
  2. [EDIT: now I saw http://wildfiregames.com/forum/index.php?showtopic=10848] Hey there! Alpha 19 is the first alpha which is playable on my Notebook, that's wonderful! Here is my suggestion: call me a wimp but I hate it to kill all the enemy's females especially in the last minutes of the game. For me, it doesn't feel right to search the whole map for the last two women and kill them or to kill all the females working at a field during an invasion. I'd much more like to conquer women You could implement it the same way as capturing a siege weapon. I think it's quite fair since a female has no chance to kill a soldier anyway and it's also quite realistic (you may think of the The Rape of the Sabine Women). Maybe the default action should be to kill, because if you are playing against several enemies, you might end up with lots of women who fill up your population limit and you had to kill them yourself (which is even more disgusting). Another possibility would be not to count captured units to the _total_ population limit - you have to build houses, though. ----------------- Thinking further, capturing could be possible for all units, not just females. As I totally hated the priests in AOE, I'm not sure if this idea is a good one, but think of the following: If a few (say, less than 5) units are clearly outnumbered, they defect to the enemy. With this (realistic) default action, you could implement a lot of extra features, for example: - develop "oath of allegiance" (rather costly): units fight to death - develop "find_a_good_name" (cheaper): units flee instead of defecting. You can develop one of both options only. - units fighting side by side with a hero fight until they fall - units in a formation resist a longer time - civilisations can be made more unique (may also be used to balance them): one civilisation simply resist longer, another cannot develop the oath of allegiance, ... - or even: having more females in the city make their husbands resist longer. They could even fight a little harder to protect their family, which would encourage the player to create more females. The advantages of this proposal are increased realism, less stupid slaughtering in the end phase and the possibility of profiting of special units of the enemy. As opposed to the AOE priest approach, you cannot "steal" arbitrary units standing behind city walls, for example. Instead, only in a few situations during a game it will be possible to capture units, either if the enemy is incautious enough to have lonesome units or at a point when an enemy is already virtually defeated. Having the player to think twice before he starts a suicide mission is -in my eyes- a good thing, too. It enforces a somewhat more strategic warfare. If someone hates the feature, he may develop the oath of allegiance. What do you think?
  3. Hi, I encountered a segfault just after reloading a map (reproducible). Because it seemed to be caused by a buffer over/underflow, I ran 0AD under memcheck memcheck. There where more than a million of fglrx-driver errors (ati-driver for linux) in the output, so I wrote a small script to remove those. Keep in mind: it's possible, but rather improbable, that the script removes also some non-fglrx-related error messages. See the attachment for the cleaned-up output. logfile_clean.txt
  4. Update: Now I'm back again with my new Linux notebook, installation of 0AD went quite well (one package was missing; I think it was pkg-config - maybe you want to add it to the documentation). I took a look at CTerrain again and think I killed the bug. This is the fixed version, watch out for comments: /////////////////////////////////////////////////////////////////////////////// // FlattenArea: flatten out an area of terrain (specified in world space // coords); return the average height of the flattened area float CTerrain::FlattenArea(float x0, float x1, float z0, float z1) { ssize_t tx0=clamp(ssize_t((x0/CELL_SIZE)), ssize_t(0), m_MapSize-1); //changed from ssize_t tx1=clamp(ssize_t((x1/CELL_SIZE)+1.0f), ssize_t(0), m_MapSize-1); //m_MapSize to ssize_t tz0=clamp(ssize_t((z0/CELL_SIZE)), ssize_t(0), m_MapSize-1); //m_MapSize-1 ssize_t tz1=clamp(ssize_t((z1/CELL_SIZE)+1.0f), ssize_t(0), m_MapSize-1); //the good old nasty indexing issue ;) size_t count=0; size_t y=0; for (ssize_t x=tx0;x<=tx1;x++) { for (ssize_t z=tz0;z<=tz1;z++) { y+=m_Heightmap[z*m_MapSize + x]; count++; } } y/=count; for (ssize_t x=tx0;x<=tx1;x++) { for (ssize_t z=tz0;z<=tz1;z++) { m_Heightmap[z*m_MapSize + x]=(u16)y; CPatch* patch=GetPatch(x/PATCH_SIZE,z/PATCH_SIZE); if(patch == 0) std::cerr << "CPATCH is 0" << std::endl; // just my debugging output else patch->SetDirty(RENDERDATA_UPDATE_VERTICES); // but since GetPatch may return 0 (and it does: #311) we'll check for that now. At this point I don't expect any performance issues. } } return y*HEIGHT_SCALE; } Keep me up to date if there's something small to do for me.
  5. Cool I tracked #311 now. I'm afraid I couldn't patch it because of lots and lots of side-effects. The crash occurs at the following lines of code when GetPatch(x/PATCH_SIZE,z/PATCH_SIZE) returns 0: float CTerrain::FlattenArea(float x0, float x1, float z0, float z1) { ssize_t tx0=clamp(ssize_t((x0/CELL_SIZE)), ssize_t(0), m_MapSize); ssize_t tx1=clamp(ssize_t((x1/CELL_SIZE)+1.0f), ssize_t(0), m_MapSize); ssize_t tz0=clamp(ssize_t((z0/CELL_SIZE)), ssize_t(0), m_MapSize); ssize_t tz1=clamp(ssize_t((z1/CELL_SIZE)+1.0f), ssize_t(0), m_MapSize); size_t count=0; size_t y=0; for (ssize_t x=tx0;x<=tx1;x++) { for (ssize_t z=tz0;z<=tz1;z++) { y+=m_Heightmap[z*m_MapSize + x]; count++; } } y/=count; for (ssize_t x=tx0;x<=tx1;x++) { for (ssize_t z=tz0;z<=tz1;z++) { m_Heightmap[z*m_MapSize + x]=(u16)y; CPatch* patch=GetPatch(x/PATCH_SIZE,z/PATCH_SIZE); patch->SetDirty(RENDERDATA_UPDATE_VERTICES); // crash! (#311) } } return y*HEIGHT_SCALE; } GetPatch(x/PATCH_SIZE,z/PATCH_SIZE) may return 0: CPatch* CTerrain::GetPatch(ssize_t i, ssize_t j) const { // range check: >= 0 and < m_MapSizePatches if( (size_t)i >= (size_t)m_MapSizePatches || (size_t)j >= (size_t) m_MapSizePatches ) return 0; return &m_Patches[(j*m_MapSizePatches)+i]; } Have a look at Terrain.cpp and you will notice that the result of GetPatch is always used unguarded, being a permanent source of trouble. I suggest using (at least) asserts there. Also I would use boost::smart_ptrs as often as possible - just my opinion. A simple if(patch) causes some (to me) strange effects, including a crash at shutdown. Just try. No more time today and probably the next few days to fix this. Hope I could help you, though.
  6. Sorry, not enough time the past weeks... I tracked issue #307 down to CTextureEntry::CTextureEntry(CTerrainPropertiesPtr props, const CStr& path). If CTerrainPropertiesPtr is NULL, OAD will crash at CTerrain::IsPassable in Terrain.cpp: bool CTerrain::IsPassable(const CVector2D &loc/*tile space*/, HEntity entity) const { CMiniPatch *pTile = GetTile(loc.x, loc.y); if(!pTile->Tex1) { return false; // Invalid terrain type in the scenario file } CTextureEntry *pTexEntry = g_TexMan.FindTexture(pTile->Tex1); CTerrainPropertiesPtr pProperties = pTexEntry->GetProperties(); // ugly workaround from here bool rv; if(pProperties) rv = pProperties->IsPassable(entity); //<- it would crash here else{ rv = false; LOGMESSAGE("pProperties was NULL"); } return rv; } With this workaround the game is at least playable. I wrote if (m_pProperties) m_Groups = m_pProperties->GetGroups(); into the ctor of CTextureEntry and the Pyrogenesis Log looked like this: Hope this is still useful for you!
  7. I've got just onboard-sound: "SoundMax Integrated Digital Audio"
  8. Again just an error report, no fix: unhandled exeption 0x0c7f1d5a in pyrogenesis_dbg.exe: 0xC0000094: Integer division by zero. At: wrap_oal.dll [no symbols found]. Occurs right after the map has been loaded.
  9. Well, I cannot start the game: the self-compiled pyrogenesis_dbg executable terminates after clicking the "Start!" button [single player menu]. Cause: Unhandled exception "PSERROR_GUI_InvalidSetting" in GUIutil.cpp: PS_RESULT GUI<T>::GetSettingPointer(const IGUIObject *pObject, const CStr& Setting, T* &Value)
  10. Hm, perhaps you can tell me, which ticket I could take?
  11. Well, i've no multiple monitor system and I've never worked with OpenGL. I know that those are not the best conditions to get into such a game project, but I was always searching for an open source AOE clone and now I want to contribute. #113 is interesting, how many OpenGL skills will I need for that?
  12. Hi, I'm a competent C++ Developer (at least I think so) and I'm working with wxWidgets and boost (<-heavily). I took also a look at SDL. I've NO expirience with Java(Script) and I won't have, too. I've not much time, but I love your game and would like to contribute. So it would be great, if you have a small task to do for me.
×
×
  • Create New...