Jump to content

All Activity

This stream auto-updates     

  1. Past hour
  2. he is more younger if you understand what I mean. he must be careful in his apreciations the next time.
  3. I said that they should be implemented in a historically informed way; if that makes them rarer, then so be it. Likewise, I never said that women should be replaced with slaves. I instead stated that slaves should, for civilisations in which labour was primarily conducted by slaves, be the primary economic unit. I have otherwise simply pointed out some alternative ways to represent women that seem more informed. In these discourses, respect is critical to healthy communication, and while I assure you that I am fallible, I do actually try to make coherent arguments; please look more carefully and criticise valid points. My apologies if this seems offensive, but I don't appreciate being taken out of context.
  4. Today
  5. Really. If you read the commit message for the patch, you'll understand why.
  6. > says that women dont have enough action in game > suggests replacing women with slaves, making them even more rare
  7. Maybe someone can do a script for this
  8. At first, pathfinding and formations should be better. I see a lot of work being done by @wraitii, but I don't know to what extend and with what aim. I miss the dev diaries. (I think are improving the system to thread the pathfinding, among others things, like fixing the gliding units)
  9. @Exodarion @darkinterloper @borg- @Nescio @Angen
  10. Hello everyone, Following https://trac.wildfiregames.com/changeset/22379 there will be some changes needed for those of you who have mods modifying templates. I believe that's most of you. Before rP22379 a typical attack component was defined like this: <Attack> <Ranged> <Hack>0.0</Hack> <Pierce>12.0</Pierce> <Crush>0.0</Crush> <MaxRange>72.0</MaxRange> <MinRange>0.0</MinRange> <PrepareTime>1200</PrepareTime> <RepeatTime>2000</RepeatTime> <Delay>0</Delay> <Projectile> <Speed>75.0</Speed> <Spread>1.5</Spread> <Gravity>9.81</Gravity> <LaunchPoint y="3"/> </Projectile> <PreferredClasses datatype="tokens">Human</PreferredClasses> <RangeOverlay> <LineTexture>outline_border.png</LineTexture> <LineTextureMask>outline_border_mask.png</LineTextureMask> <LineThickness>0.175</LineThickness> </RangeOverlay> </Ranged> </Attack> Now you have to wrap Hack, Pierce, Crush (but not Capture !) into a Damage Tag <Attack> <Ranged> <Damage> <Hack>0.0</Hack> <Pierce>12.0</Pierce> <Crush>0.0</Crush> </Damage> <MaxRange>72.0</MaxRange> <MinRange>0.0</MinRange> <PrepareTime>1200</PrepareTime> <RepeatTime>2000</RepeatTime> <Delay>0</Delay> <Projectile> <Speed>75.0</Speed> <Spread>1.5</Spread> <Gravity>9.81</Gravity> <LaunchPoint y="3"/> </Projectile> <PreferredClasses datatype="tokens">Human</PreferredClasses> <RangeOverlay> <LineTexture>outline_border.png</LineTexture> <LineTextureMask>outline_border_mask.png</LineTextureMask> <LineThickness>0.175</LineThickness> </RangeOverlay> </Ranged> </Attack> Sorry for the inconvenience and Happy modding You can answer this thread if you need further details
  11. How can I recover my password?
  12. Something has been working on my mind for some time, mainly because I'm not a big fan of systems based on rock-paper-scissor. The case of the overwhelming advantage of the ranged units in the recent alphas released stresses the difficulty in balancing different type of units while keeping the game history-friendly. I see often people suggesting balancing changes or different gameplay based on historical facts (or according to their understanding of the history). This makes me wonder if this is possible to satisfy people with both historical accuracy and a balanced gameplay with depth and diversity. Ideas like spearman and swordsman having distinctive efficiency against different units are themselves not very historical. Even the idea that the cavalry is the best counter against ranged infantry is itself contradicted by numerous accounts on the battlefields where the later was often used against the former. This is not a mean criticism, most of the RTS falls in these simplifications to ease the gameplay, even the Total War games. This is understandable. Age of Empire 2 has reached a very high level of gameplay mechanics with this system. Even StarCraft 2 has several aspects from rock-paper-scissor systems. However I wonder if the inclusion of battle formation could be an opportunity to innovate in the gameplay. Historically, the battlefield was unbalanced from a game point of view, mostly filled with infantrymen and this across all continents and across all the time periods. The only exception being the nomads. Therefore why not consider an unbalanced system working around battalions of infantrymen? If the gameplay is unbalanced in purpose in favor of the infantrymen, with the other type of units working as support and counter around them, it could be easier to balance. This is kinda a heretic way to think in RTS games but I throw this idea to encourage further thinking. Even for mods, not only for the vanilla. To sum it up my mind, winning an encounter could be based on obvious parameters like the quality of the infantrymen and the numbers but also on parameters strongly related to the battle formation. For example, the battalion could gives a bonus to all the units (obviously) but this bonus could varies according to the depth of the formation. Like this players should consider both the width of the formation in comparison with the enemy's formation (because it will impact how much units will hit your unit in the same time) and the depth of the formation because each additional rank will increase the bonus. Clearly this is favoring the numbers of units, so outnumbering strategies will often win. But it could be counter by flanks attacks where each units attacked by enemy's melee units while being on the sides will lose all the bonus from the formation. Which will give an interesting tactical advantage for the cavalry. Moreover, this could also be countered by ranged infantry raining their missile on the infantrymen. Not only to cause damages and kill the units but in decreasing the bonus or even causing malus for the units hit. It could even slow down the movement of the whole formation and slowing their rate of attack (DPS). It could also be counter by forcing the player to split his army and to use clever strategies to destroy quickly the army with a smaller force, see this. In my mind, the ranged units and the cavalry should work as support and counter against each other to weaken the enemy main forces (which is the infantry). For the moment, I do not know how it could include the champions cleaverly but I wanted to share my thoughts. This is could be tested in a mod maybe.
  13. Would need an icon and a proper template that doesn't depend on DE
  14. Should be better now pers_ice_house_02.zip
  15. Hamilcar Barca: portaits are very rare in web, but some source here
  16. https://code.wildfiregames.com/D1926 would help with running the game on really slow machines I guess.
  17. @gameboy that code will not work, nor will the previous examples you posted do either. Some are C not C++ which isn't a problem by itself, but we don't code in C anywhere, some are not cross platform, example #include <windows.h> Will only work on windows. Nobody actually needs to change the gamma in the game, you can do it using external software if you need to. Also, when posting code snippets, please use the code tools from the forums. It's unreadable otherwise. Thanks.
  18. @Stan` This code is more practical, it is simpler, it can effectively solve practical problems. BTW: we should not delete those settings, should adjust it. // The hDC DC handle, if NULL, uses the entire screen // wR wG wB 0-255, default 128 BOOL SetBrightness(HDC hDC, int wR, int wG, int wB) { BOOL bRet = FALSE; HDC hGammDC = hDC ? hDC : ::GetDC(NULL); #pragma pack(push, 8) typedef struct _tagD3dGammaramp_t { WORDred[256]; WORDgreen[256]; WORDblue[256]; } _D3DGAMMARAMP, *LP_D3DGAMMARAMP; #pragma pack(pop) _D3DGAMMARAMP mGamRamp; memset(&mGamRamp, 0, sizeof(mGamRamp)); for (int iIndex = 0; iIndex < 256; iIndex++) { mGamRamp.red[iIndex] = min(65535, iIndex * (wR + 128)); mGamRamp.green[iIndex] = min(65535, iIndex * (wG + 128)); mGamRamp.blue[iIndex] = min(65535, iIndex * (wB + 128)); } LPVOID lpRamp = &mGamRamp; bRet = SetDeviceGammaRamp(hGammDC, lpRamp); if (hDC == NULL && hGammDC) { ::ReleaseDC(NULL, hGammDC); } return bRet; }
  19. @Stan` I wrote a piece of code that might be able to adjust and correct the gamma on the display. Class header file : (gammaramp.h) #ifndef GAMMARAMP_H_ #define GAMMARAMP_H_ /* CGammaRamp class Encapsulates the Gamma Ramp API and changes the brightness of the entire screen. */ class CGammaRamp { protected: HMODULE hGDI32; HDC hScreenDC; typedef BOOL(WINAPI *Type_SetDeviceGammaRamp)(HDC hDC, LPVOID lpRamp); Type_SetDeviceGammaRamp pGetDeviceGammaRamp; Type_SetDeviceGammaRamp pSetDeviceGammaRamp; public: CGammaRamp(); ~CGammaRamp(); BOOL LoadLibrary(); void FreeLibrary(); BOOL LoadLibraryIfNeeded(); BOOL SetDeviceGammaRamp(HDC hDC, LPVOID lpRamp); BOOL GetDeviceGammaRamp(HDC hDC, LPVOID lpRamp); BOOL SetBrightness(HDC hDC, WORD wBrightness); }; #endif Class C++ File : (gammaramp.cpp) #include <windows.h> #include "gammaramp.h" /* CGammaRamp class Encapsulates the Gamma Ramp API and changes the brightness of the entire screen. */ CGammaRamp::CGammaRamp() { //Initialize all variables. hGDI32 = NULL; hScreenDC = NULL; pGetDeviceGammaRamp = NULL; pSetDeviceGammaRamp = NULL; } CGammaRamp::~CGammaRamp() { FreeLibrary(); } BOOL CGammaRamp::LoadLibrary() { BOOL bReturn = FALSE; FreeLibrary(); //Load the GDI library. hGDI32 = ::LoadLibrary("gdi32.dll"); if (hGDI32 != NULL) { //Get the addresses of GetDeviceGammaRamp and SetDeviceGammaRamp API functions. pGetDeviceGammaRamp = (Type_SetDeviceGammaRamp)GetProcAddress(hGDI32, "GetDeviceGammaRamp"); pSetDeviceGammaRamp = (Type_SetDeviceGammaRamp)GetProcAddress(hGDI32, "SetDeviceGammaRamp"); //Return TRUE only if these functions exist. if (pGetDeviceGammaRamp == NULL || pSetDeviceGammaRamp == NULL) FreeLibrary(); else bReturn = TRUE; } return bReturn; } void CGammaRamp::FreeLibrary() { //Free the GDI library. if (hGDI32 != NULL) { ::FreeLibrary(hGDI32); hGDI32 = NULL; } } BOOL CGammaRamp::LoadLibraryIfNeeded() { BOOL bReturn = FALSE; if (hGDI32 == NULL) LoadLibrary(); if (pGetDeviceGammaRamp != NULL && pSetDeviceGammaRamp != NULL) bReturn = TRUE; return bReturn; } BOOL CGammaRamp::SetDeviceGammaRamp(HDC hDC, LPVOID lpRamp) { //Call to SetDeviceGammaRamp only if this function is successfully loaded. if (LoadLibraryIfNeeded()) { return pSetDeviceGammaRamp(hDC, lpRamp); } else return FALSE; } BOOL CGammaRamp::GetDeviceGammaRamp(HDC hDC, LPVOID lpRamp) { //Call to GetDeviceGammaRamp only if this function is successfully loaded. if (LoadLibraryIfNeeded()) { return pGetDeviceGammaRamp(hDC, lpRamp); } else return FALSE; } BOOL CGammaRamp::SetBrightness(HDC hDC, WORD wBrightness) { /* Changes the brightness of the entire screen. This function may not work properly in some video cards. The wBrightness value should be a number between 0 and 255. 128 = Regular brightness above 128 = brighter below 128 = darker If hDC is NULL, SetBrightness automatically load and release the display device context for you. */ BOOL bReturn = FALSE; HDC hGammaDC = hDC; //Load the display device context of the entire screen if hDC is NULL. if (hDC == NULL) hGammaDC = GetDC(NULL); if (hGammaDC != NULL) { //Generate the 256-colors array for the specified wBrightness value. WORD GammaArray[3][256]; for (int iIndex = 0; iIndex < 256; iIndex++) { int iArrayValue = iIndex * (wBrightness + 128); if (iArrayValue > 65535) iArrayValue = 65535; GammaArray[0][iIndex] = GammaArray[1][iIndex] = GammaArray[2][iIndex] = (WORD)iArrayValue; } //Set the GammaArray values into the display device context. bReturn = SetDeviceGammaRamp(hGammaDC, GammaArray); } if (hDC == NULL) ReleaseDC(NULL, hGammaDC); return bReturn; } Example for using the CGammaRamp class: #include <windows.h> #include "gammaramp.h" int WINAPI WinMain( HINSTANCE hInstance, // handle to current instance HINSTANCE hPrevInstance, // handle to previous instance LPSTR lpCmdLine, // command line int nCmdShow // show state ) { //Example for changing the brightness with CGammaRamp class: //Be aware that this exmaple may not work properly in all //Video cards. CGammaRamp GammaRamp; //Make the screen darker: GammaRamp.SetBrightness(NULL, 64); //Wait 3 seconds: Sleep(3000); //Return back to normal: GammaRamp.SetBrightness(NULL, 128); return 0; }
  20. Another guy running 0 A.D. in Raspberry Pi. It seems that tiny maps with not too many resources could run smoothly. Maybe we could even make a mod for less powerful computers. hf
  21. @Boudica I thank you to be a part of this. We made it happen all together. It's hard to come up with a fair system. However, this is what we have. It's more accurate if a player has high level of participation like you. There are still things we need to improve. Currently, the score system encourages participation, winning, destroying, killing, sharing resources etc. Every week is different from other weeks. I have compared the players according to their participation. @Unknown_Player and @ffffffff have 7 weeks. You have 6 weeks. So, comparing the best 6 weeks seems fair to me. I use the same method for other players. Two of them have the same point. So, I looked how many weeks they participate. Obviously, If you participate more you have better chance. Yes, it's good to have a break. But this not the end. We'll have another event. Stay tuned. Have a great day!
  1. Load more activity
×
×
  • Create New...