Jump to content

FeXoR

WFG Retired
  • Posts

    1.426
  • Joined

  • Last visited

  • Days Won

    28

Everything posted by FeXoR

  1. You replied to a topic that was closed. And it was closed for a reason. Replying in another topic defeats the purpose of both topics in general and closing a topic specifically. So I ask you to stop that. Playing doesn't requite you to write anything and it was not your playing that got you banned. I can only advise you to think before acting (including but not exclusively writing), again, especially how others might feel about your actions (including but not exclusively what you say).
  2. 0 A.D. doesn't use money (of any curency like $ - not to mention "$$$"). It uses the actual resources needed to produce units and/or build buildings. You don't have to repay depts - de facto removing resources as a game element. I herby ask you to think things through before posting, seriously!
  3. CPU: Intel Pentium 2x1.7 GHz RAM: 3 GB Graphics: ATI Radeon Xpress 1200 Series I can run any game I want but 0 A.D. (at least not fluently) and Path of Exile (Sadly) Sidenotes: - High framerates can cause headache and sickness ^^ - On my first LAN party I played Duke Nukem 3D on a 14'' Monitor - and reduced the viewport to a size smaller than a regular postcard... after I edited my system files so network drivers fit into the memory
  4. AFAIK for a long time in history ships where mainly used for transport purposes. They where more or less all the same size and had no real measures of attacking. Than, within a relatively short timeframe, ships got bigger and bigger and ramms where added. It would be nice to know what timeframe that happend in. If you have any information about this (or I overlooked that in the forum) I would be greteful if you could point me to it.
  5. That's likely because of the modern worldview mainly focussing on price/cost (in contrast to what individual people value - or society as a whole). (Not to be mistaken for the numeric value (or simply quantity) as a mesure in a given unit...)
  6. Hi Vlad123. You are correct. There is no "money" resource in 0 A.D.. Since at this time money was somehow similar to gold you could see money as part of metal. IMO there is no need to add it because you cannot build anything with money but only buy the material you need to build something. Traders used money for the easier exchange of goods. Example: City 1, Woodstock: - The city lies within a forest thus wood is easy to access thus the people of Woodstock doesn't value wood that much. - They don't have access to stone to build longer lasting buildings thus the people of Woodstock value stone very much. City 2, Quarrypebble: - The City lies within rocky hills with many natural quarries with some grassland arround thus the people of Quarrypebble have easy access to stone and don't value that much. - The thin layer of earth on the otherwise rocky ground does not support trees so the people of Quarrypebble value wood quite high. Merchant: - A merchant with some money goes to Woodstock and buys some wood. - He brings it to Quarrypebble and sells it there. Since wood is valued there more he likely gets more money back than he spend initially. - He uses some of this money to buy stone, again quite cheap. - He returns to Woodstock and sells the stones there, again likely with some profit. Now check what has changed: - Money: Towns -> Merchant (Represented ingame by the cost of metal to produce the merchant. He'll spend some of the money to get e.g. food and shelter so the money might go back to the towns) - Wood: Woodstock -> Quarrypebble - Stone: Quarrypebble -> Woodstock Assuming the player manages Woodstock the main change for him is he exchanged wood for stone (and that's exactly what happens ingame). Note: - The access to resources have risen for everyone (That's the real gain of trading). - There is no gain in value (both towns value the resource brought to them less the more trading goes on which cancles out against the slight increase of value of the resource they produce by beeing able to sell it) - There is no money generated (Who ever plantet that into the brains of people, I heard that several times now) - If one of the parties realizes what's going on and just slightly changes it's behaviour to at the end of the loop come out better all money will end up at this party
  7. The WallPiece.Length property values are more or less just coppied from the Obstruction values. Actually they are to big, not to small. I had it wrong by a factor 2^(-0.5). I'm adjusting WallPiece.Length to actually fit the space the given entity can fill in a wall without leaving gaps. IMO this should have been done when the property/a new entity template with that property was added.
  8. The WallPiece.Length property does not match the actor's size either (The distance between the towers is the WallPiece.Length value): I put 3 towers next to each other and manually replaced the middle one to show that the poportion WallPiece.Length to actual actor width is neither 1 nor constant for different templates. It might be that those values are optimized for ingame wall placement. However, without correct information I can't remove the hardoded length values in in wall_builder.js without extending the number of propperties of the entity templates further or accepting to make the RMS wall placement fit worse. Trying the Obstruction (though that will likely leave gaps when e.g. towers are cone-like)... EDIT: For the Maurian tower the values match quite well.
  9. @s0600204: Thanks much for the explanation what the "Footprint" property is originally meant for. Still I can't figure out why it's values vary that much compared to the actor's extend (which is even worse considering it's use for the hitbox as wowgetoffyourcellphone stated). Concerning the usage of 0*PI: That was meant to clearly show that this argument is an angle (No Idea why I used 2*PI/2, the patch was more forced in like propperly reviewed back when it was added). I'll likely remove all of them as you asked (which is of cause appropriate ) I'll try the WallPiece property but the ingame placement varies quite a lot from that in wall_builder. EDIT: The problem readjusting wall_builder.js mainy originate from this: - The wall_builder was added prematurely - The clean original wall concept (one scale per wall set, wall elements of the same type have the same length ratio within each wall set) was put to reality neither by the actor designers nor by the ingame wall placement (it was replaced by arbitrary length values only roughly matching the idea) - wall_builder.js has extended functionality beyond the concept (originally due to the fact that no template information where available to RMS, wall set scales where the best available information anyways. Some team members strongly objected exposing template data to RMS so there was no reason to beleave that this would change) - Mod support was added after wall_builder.js (as well as the ingame wall placement)
  10. Files for wall_builder.js in http://trac.wildfiregames.com/ticket/2944 @niektb: Yea, I'm using them in the collision detection. Not sure what led me to use "Footprint" here x) (maybe that it's rectangular for e.g. Iberian round towers?) Still, ATM it's a mystery to me what "Footprint" is for ^^
  11. I'm working on making wall_builder.js more generic. This includes using the "Footprint" property of the templates. However, this is matching the visual actor much less accurate than the information in wall_builder.js. All tested footprints are bigger than the visual entities. Here the gaps left by wall towers when the Footprint is used: ...some are just slightly bigger, others nearly 50% bigger. Should I have used another property? And what is "Footprint" for if not matching the actor size?
  12. Reminder: One related ticket to the collision detection is: http://trac.wildfiregames.com/ticket/1901
  13. It seams like the problem is that units are shown in fog of war if they die (So maybe not really the units but their decals, not sure about the terminus/implementation). (Thus a player that has no vision on an area - only scouted it beforehand - can tell fighting takes place there) Thanks for reporting this.
  14. This might be a bug in the unit AI for neutral animals ... or a funny feature
  15. This might not be a path finder issue. It might also be related to improper footprint and/or obstruction (or usage of them). Just a thought
  16. And the build restrictions depend on the inclination of the ground below the obstruction(or footprint? Not sure actually!) AFAIK. Don't pin me down on that though
  17. I agree reusing unit properties for multiple different cases makes the modability of just changing the units properties less flexible. But IMO that fits the case quite well: Only changing the unit properties is and should be easy but you don't have as much controll as e.g. writing code for how things are handled. If you want to have more control you might want to change some code as well. However, if you can clearly point out what you want to have changed and why exactly and what is improved by it in general you may find someone agreeing, adding a patch and get it into the main game. However, untill now at least I am not convinced and don't even know what exactly you whant to have changed... so I threw in my general opinion
  18. Looks good Note that the models have to reach far into the ground so placing them on uneven terrain doesn't make them "float" or the entrance "burried". I'm not sure if the few steps at the edge are enough since the building is quite big. One of the artists should be able to tell you.
  19. I don't mind if the obstruction or the footprint is used. I just wanted to point out my opinion that reusing properties for things that might only be related to but not exactly matching is a good thing e.g. less stats to change for modders and less data to parse.
  20. IMO the amount of properties per entity type should be kept as small as possible. Reusing the footprint (size and shape) for the selection rings makes perfect sense to me (and actually tells the player somthing about how easy the units are to be hit). How far they extend beyond the footprint should be the same for all units (with the same shape, and there should only be square and round shapes for movable units - actually IMO there only should be round shapes so units don't get wedged). It also makes sense to use the footprint size and shape for the unload distance IMO. Could you give an example and reason why you would want a selection ring not fitting the footprint size?
  21. IMO "scores" are always arbitrary because not well defined or at least arbitrarily defined. For the end of game summary screens I'd stick to things that actually are clear in-game properties and no arbitrarily defined "scores". I agree with your calculations of the "efficiency score" ( though it's just the military efficiency score). However, it doesn't help to be highly efficient in using the resources you have if your opponent is half as efficient as you are (in your sore) but managed to gather 3 times the resources (has 3 times the "resource effectiveness" - not efficiency, or you compare it to the time the players had which would be the same for both players). In that case he'd still win. And that's the point of the game. In the end you can simply see which player had the over all better effectiveness by the fact he won the game.
  22. Yes, it would be about the same (just more terrain grids to handle as well)
  23. (This topic reads like one in the urban dictionary )
×
×
  • Create New...