Leaderboard
Popular Content
Showing content with the highest reputation on 2014-04-07 in all areas
-
Please, when designing these interfaces keep in mind mods that might add civilizations and factions. For example, try to design an interface that would work with 20 civilizations with 3 factions each, with some of those civilizations having instead o 3 just 1 faction, and others having 10 or more factions. The interface should be able to handle such a case. Some suggestions with this in mind: Get rid of the buttons on the left-hand side. Instead, organize the list of factions by civilization (like in http://www.kde.org/announcements/4.0/screenshots/dolphin-groups.jpg) and allow to chose a civilization. Clicking a civilization header selects all the factions of that civilization.Use smaller icons (like in http://icrontic.com/uploads/features/2013/08/WorldMap.png , maybe without text as well since we have the informative right-hand sidebar).When more than one faction is selected, add a message somewhere that explains that, when the game starts, a factions will be randomly chosen from the selected factions. This flexibility, being able to choose any set of factions regardless of the civilization to randomly get one of them, would be awesome, and you could still do it on a civilization basis as explained. Replace the Random All button with a Select All button on top of the list of factions.The informative panel shouw show information about the faction that you are currently hovering, or the last faction that you were hovering if your are not hovering any faction at all.We would need a cool vertical scrollbar when the list of factions does not fit the screen.3 points
-
2 points
-
I believe for it to be worth the effort it should bring something like a bonus of motivation to the population or else be in a neutral village. not just a unit you put there or there it could be a small theatron with flame throwers and jongleurs. The main problem I see is that it's not like the Settlers where all units are bound to be a city. Every unit is bound to his task doesn't have to eat or anything.2 points
-
I've played a game on this map and I like it very much. It looks good and works well for gameplay!2 points
-
This thread is for discussions and updates about the SpiderMonkey upgrade to ESR31 I've decided to create a new thread because getting the upgrade to ESR24 into SVN was an important milestone and the previous thread was already quite long. Ticket: 2462 Check it out from my github branch (read the readme!). Short summary what happened so far The upgrade from the old SpiderMonkey version v1.8.5 (released in March 2011) was quite a big task due to the API changes. The conceptual changes (like having a 1to1 releation between global objects and compartments) were the biggest problem. Another problem were inconsistencies and duplication in our own code. The smaller problem were simple API changes. These issues are sorted out now and we can continue with the upgrade to ESR31. Performance We expected a lot from the upgrade to ESR24 because most of the significant SpiderMonkey changes from v1.8.5 to v24 were solely to improve performance. There's a new baseline compiler, a new JIT compiler with enhanced optimization capabilities called Ion Monkey, improved type inference and a lot more. There was a whole team of programmers working on performance improvements over years. The commonly used benchmarks show a big improvement but unfortunately we figured out that this does not improve performance for us and the performance got a little worse with the upgrade. It's not a big secret that these benchmarks get "special care" from the developers of Javascript engines such as SpiderMonkey or V8. Browser market shares are the main factor deciding how much money these companies get from e.g. search providers for adding their search as default entry in the browser. Benchmark performance improvements seem to be important for marketing, which is where the term "benchmarketing" comes from. The benachmarks were originally desigend to be a good representation of real world application performance but now one could say they are not related to real world performance anymore because of all the tuning and benchmark specific optimizations. Still, I trust Mozilla that the fundamental engine changes will also improve performance for embedders like us at some point (and probably they already do). What they did first after integrating big changes like Ion Monkey or Baseline was making sure they don't decrease benchmark performance. Now that this goal is completed they can start fixing performance issues which don't show up in these benchmarks but are important for other applications. H4writer fixed some of these problems we reported during the upgrade to v24 and apparently they continued fixing others in the meantime. ESR31 schedule ESR31 is still in development. We have time until the end of the month to get changes in, so I'm starting early with the work on the upgrade (well, as early as I could). That should also help detecting performance regressions and ease the integration of API changes. The final version should be released in July and I'm aiming for Alpha 17. Exact rooting, moving GC and GGC While upgrading to v31 I'm also working on the transition to exact stack rooting and the support of a moving garbage collection (GC). V31 will probably be the last version supporting conservative stack scanning (the opposite of exact rooting). This change should bring some performance improvements, in theory, but we'll see what happens in practice. This transition will allow us to use features such as generational garbage collection (GGC) and compacting garbage collection in the future. The progress is tracked in #2415. Performance: current status V31 really brings some improvements compared to V24. Unfortunately I can't compare it to v1.8.5 easily anymore. I've used a non-visual replay with 4 aegis bots on the map Oasis 04 over around 15000 turns and measured how long the whole replay takes. This shows the difference more clearly than the graphs I've used before. I've found a bug with incremental GC causing problems with off-thread compilation of JIT code. I've reported the incremental GC problem on the JSAPI channel and they created bug 991820 for it. I've also confirmed once more that disabling garbage collection of JIT code makes a difference. Unfortunately there are currently only functions meant for testing purpose which allow us to do this and I'll ask for a proper solution soon. Here's the comparision with different variations concerning the problems mentioned above:1 point
-
Tienes que reemplazar "testmod" con el nombre de la carpeta de tu mod, a no ser que "testmod" sea el nombre de tu mod. En este ultimo caso necesitaría más información.1 point
-
From my experience, a deform bone (a bone that the name doesn't start with "prop-" prefix) without influencing any vertices throws an error in atlas. Animation states (walk, run, death, etc) are inherited by the childs (props), but not the speed of the animation. The speed is the constant that the animation loop plays when the unit enters that animation state, so the "structural" mill animation can be tuned to conform the walking donkeys separately.1 point
-
Good work. Looks good. Cool that the random maps are upcoming. That's so awesome. (no idea on the different texture paint methods though)1 point
-
Not sure? What do you think? As a multimesh is not allowed, we need each ball to be a separate prop. Can be attached to one and the same prop point, hence bone. Best not the moving think, so the neck or the spine would be suitable. Then each of these ball needs a in respect to circle around in the same manner. Could even use one ball and vary texture/colour via pyrogenesis random selections. Then pyrogenesis should also make the animation start in a offset, best homogenuous to make the arm movement animation of (Enrique's breakthrough) blender biped easy. Still wonder if it could be done easier and with more variation. E.g. make the biped almost let fall one ball. This might be difficult though and one ball animation might no longer be enough. Ah, yes, the animation speed should probably be uniform too unless we manage the biped arm movement in a way that it looks semirealistic in all cases, no matter when a ball comes near.1 point
-
You are thinking to much in the limits of 0AD only... inventories would be usefull for mods... something like Warcraft3 with usable items for example. And last time I checked using a completely own config file was only possible if one would fork 0AD completely into a separate game, a mod always has to extend the existing core config/mod. This might be intended, but is not very user-friendly for creating total conversion mods without forking. Sometimes forking is undesirable as you might want to keep it a mod during early development for people to be able to quickly download and test/play early versions without messing up their main 0AD game. It also makes it easier to contribute back to the main game if your are modding and not forking. Edit: practical examples mentioned in the mod forum: making a turnbased game like Civilisation, or a ActionRPG-RTS hybrid. Both need quite extensive changes in the config etc., but one could start small an keep it a mod for 0AD if true moddability was possible (and not just extendability like it seems to be the case so far).1 point
-
When reported the spammer gets an invisible block. Invisible so they can access their accounts and create tickets, but those tickets aren't saved.1 point
-
How about a invisible block? => spammers are still able to create tickets, but the tickets never show up and get lost immediately.1 point
-
1 point
-
About the rotary mill donkeys animation: There's a way to animate the rotary mill (although this is not the thread to discuss it) and avoid making the full 360 circle animation which would be a very big animation data file. It should be as follows: - The actual part of the mill that rotates should be a prop attached to the main structure. - This Mill rotating thing should have two prop-bones where the donkeys will be, these prop bones must be parented to the bones that makes the thing rotate. - Make a small looping walk animation for the donkey. - Apply the donkeys where the prop-bones should be and give them the walk animation loop, so they will play the walk animation while the rotation of the parent will make the illusion that they're walking. Of course the speeds will need to be tuned so there's no slide-effect going on. The problem I was talking about in the IRC is that prop-bones do not record animation . This means that you can animate them in the armature, but the engine will not read its movements. The only way to make them move is parenting them to "normal bones" or "deformation bones" and they will follow its parents movements/rotations. About the actual zebu rig in this thread: - Not enough bones for decent animation. - The mesh is symmetrical, but the armature is not. - Envelope weighting is not suitalbe for accurate deformation. It needs vertex groups for each bone in order to have better control over deformations. - Inverse Kinematics for the legs and tail would make animations much more real and easier to do.1 point
-
What an honor. Alas, I feel it is not game-ready yet. I could use some advice on the visuals especially texture choice.1 point
-
Since we seem to have a sizeable Spanish language community, we might consider checking adding a language pack to the forum software?1 point
-
Perhaps the use of heroes would be a tad overpowered in a way though. Since this game is heavily based off of the Age of Mythology game, I would suggest that we grab an idea from AoM: Titans Expansion using the Atlantean Civ as an example - where any unit can be made into a hero and multiple heroes can be made at a certain cap. Or perhaps you can get a regular unit to change into a historical hero and for each civilization's different units there would be a different heroes for each type of military unit for each civilization.1 point
-
We try to put all performance sensitive code in C++, which is still faster than asm.js. Certainly if you also know that the conversion of variables from regular js to asm.js costs some conversion time, just as with the conversion to C++ datatypes. Also, asm.js is meant as a compilation target, not as a language to write. Which would mean we can just as easily rewrite the performance sensitive algorithms directly in C++ rather than in some other language that has to be compiled separately to js.1 point
-
H4writer pointed me to bug 984537 which is planned to get into ESR31. I can test this patch and see if it really solves the problem for us, but according to him it should.1 point
-
Okay, I fixed it and it is now playable. Therefore I need playtesters and critics. I need comments on the playability and the looks. It is a demo map so you can find it under demo random maps. schwarzwald2603.zip1 point
-
I've added support for using the scrollwheel in SVN. Personally, I agree with FeXoR on the civilization selection issue and I think that a good contextual help system would work better over a dedicated page. But I think this discussion is on the brink of descending to a heated argument which is silly because: The GUI department doesn't have the resources to implement major features any time soon.This is a trivial issue. Come on, 28 posts on this alone. Really?As for Pureon's new mockups: I really like them, but the yellow buttons distastefully remind me of our first GUI version.1 point
-
Per our PM conversation. This is basically how you would set it up with the prop points. celt_sb_animated.zip1 point
-
There are ways to solve this. Like we can provide a zipped git repo that you can just unpack to get a (slightly older version) of the git branches. Those separate files can be distributed in any format, and can also be resumable. I think we should release a zipped git repo on every alpha release. So people can just download that, and manually update to the current git revision. We could also split the git repo in several repos, though that'd add more management issues.1 point
-
Hi, I'm going to share my workflow for texture creation within blender. I developed this technique while working in WFG and the need to make custom textures by myself in a reasonable timeframe. (This is a How-to post not a tutorial ) This may be helpful if you're a better modeler than a texture painter like me. The process is like this: I made a .blend file which is basically a camera in orthographic view mode (without perspective) that is pointing down, a plane which is exactly the same size as the camera and a sun lamp to get some shadows in the texture. With this setup, when you make a render, the square plane will fill all the render image. Once you have modeled whatever you want to be the texture, you can use the plane that fills the whole camera view to bake normals, ambient occlusion, displacements... whatever. You need to have some basic knowledge in blender to know how to apply textures, modifiers, etc.. so you create the scene textured, and you render to get the texture that will be used (preferably for 0AD lol) In this video I show the final scene of how I made a test texture for an elephant howdah. The bricks are just cubes that have two subsurf modifiers (that makes them smooth), displacement modifiers (that makes them bumpy) a desaturated leather texture that makes them grey and a rusty metal texture that makes them dirty. The wood is a single plane with a wood texture, and little details are modeled with a metal material. After rendering the scene and check the texture, I use the plane to bake the normals selecting all the geometry I want to bake, select the plane last, create a new image to bake the normals, and baking them with "selection to active" checked. Since the plane has the same ratio as the camera, the normal texture matches the rendered texture. Here's some links to pages with licenses compatible with 0 A.D: http://www.texturemate.com http://agf81.deviantart.com/gallery/ http://opengameart.org/users/yughues I also used this technique for creating textures for units. The trick for units is using a background image with an existing unit texture, and modelling only the "new parts" placing them following the background image as reference. Then make the render with transparent background, and use GIMP or photoshop to add the resulting rendered texture in top of the base texture. Here's an example of the blendfile I used to create Ashoka's texture. I used Cycles renderer instead of blender internal because it works better for metallic reflections (but is harder to make a good light setup). Here's the blendfile ready to model the contents of the texture and render it. Blender texture creator.zip1 point
-
We'd really like to do them justice in the sequel, plus they were much more 'active' against Rome during the imperial period ("0 A.D. - Empires Ascendant" takes place from 500 B.C. to 1 B.C., while "0 A.D. - Empires Besieged" takes place from A.D. 1 to A.D. 500).1 point