Jump to content

All Activity

This stream auto-updates     

  1. Past hour
  2. Hello, iam from brazil. i am install the first OD in 19.06 .2019 my problems is the zoom in game is IN forever. i use the scrooll down , the - and not resolve. Auto in zoom too why i do? thanks
  3. Today
  4. Maybe then we could restrict catapults to buildings when attack range is implemented.
  5. version 0.5.0 Fixed: Disabled map browser zoom animation Added: Buildings placement hotkeys (extendable for custom buildings) Building placement's hotkeys list: hotkey.autociv.session.building.place.Archery_Range = "unused" hotkey.autociv.session.building.place.Barracks = "Space+B" hotkey.autociv.session.building.place.Blacksmith = "Space+N" hotkey.autociv.session.building.place.City_Gate = "unused" hotkey.autociv.session.building.place.City_Wall = "Space+W" hotkey.autociv.session.building.place.Civic_Center = "Space+C" hotkey.autociv.session.building.place.Civic_Structure = "unused" hotkey.autociv.session.building.place.Corral = "Space+K" hotkey.autociv.session.building.place.Defense_Tower = "Space+D" hotkey.autociv.session.building.place.Defensive_Structure = "unused" hotkey.autociv.session.building.place.Dock = "Space+G" hotkey.autociv.session.building.place.Economic_Structure = "unused" hotkey.autociv.session.building.place.Elephant_Stables = "unused" hotkey.autociv.session.building.place.Embassy = "unused" hotkey.autociv.session.building.place.Farmstead = "Shift+Space+F" hotkey.autociv.session.building.place.Field = "Space+F" hotkey.autociv.session.building.place.Fortress = "Space+A" hotkey.autociv.session.building.place.Greek_Theater = "unused" hotkey.autociv.session.building.place.House = "Space+H" hotkey.autociv.session.building.place.Kennel = "unused" hotkey.autociv.session.building.place.Library = "unused" hotkey.autociv.session.building.place.Market = "Space+M" hotkey.autociv.session.building.place.Military_Colony = "unused" hotkey.autociv.session.building.place.Military_Structure = "unused" hotkey.autociv.session.building.place.Outpost = "Space+O" hotkey.autociv.session.building.place.Resource_Structure = "unused" hotkey.autociv.session.building.place.Rotary_Mill = "unused" hotkey.autociv.session.building.place.Sentry_Tower = "Space+Y" hotkey.autociv.session.building.place.Siege_Wall = "Space+J" hotkey.autociv.session.building.place.Siege_Workshop = "unused" hotkey.autociv.session.building.place.Special_Building = "unused" hotkey.autociv.session.building.place.Stables = "unused" hotkey.autociv.session.building.place.Stoa = "unused" hotkey.autociv.session.building.place.Stone_Wall = "unused" hotkey.autociv.session.building.place.Storehouse = "Space+S" hotkey.autociv.session.building.place.Structure = "unused" hotkey.autociv.session.building.place.Temple = "Space+T" hotkey.autociv.session.building.place.Wall_Turret = "unused" hotkey.autociv.session.building.place.Wonder = "Space+V" hotkey.autociv.session.building.place.Wooden_Wall = "Space+E" To add new buildings names just add them to user.cfg with the same naming style as the currently added.
  6. I meant when an attack order is given, I wasn't precise. Even if in a general case it makes sense to follow a target with attack order, it is often not the case for catapults who target a unit which goes then out of range (since we just want to target the army actually). And the case might happen if we click on a unit that is out of range but with other valid targets around, would we really want the catapult to take a lot of time to pack/unpack in middle of the fight ? But of course, then comes the situation where we target a unit (building) that is out of range and we want the catapult to do all the actions to do so. Since it's difficult to differentiate the case, a solution needs to be taken. In AoE2, packing the trebuchets is always manual, which can be frustrating especially for players slow/not experienced but otherwise the system works well, it's just a matter of choice i suppose. Well, the weakness would be far from removed (actually, if only this is their weakness then we could say that current cata don't have weakness since we can cancel instantly if we ever want to). The catapults will still have to pack if you see that your army protecting them is losing and you have to go back. This situation is in the case where catapult starts unpacking because you decided so/made mistake.
  7. Looks nice! @MarcusAureliu#s do you want it included in the next version of the Community Maps mod?
  8. Maybe that would be more logical indeed. March 2018: rP21630 Fix UnitAI behaviour inconsistent with its stance for packed units and set default stance to standground for packed units. April 2018: rP21784 Fix a couple of packing problems from rP21630 rP21786 really fix packing problems reported in rP21630 May 2018: #5175 October 2018: So perhaps the fix to #5091 should be different, I didn't want to get involved with that mudding, but the unpack-loop issue remains reported and is put into the scheduled list #5328 (which means there will be at least three clicks being spent on the issue). (Already the case?) #4015 and D1520 as FeldFeld pointed out. Standground? Simulation commands are orders. The user sends an order so as to start a process. UnitAI has an order queue and performs that one step at a time. Orders can be cancelled by removing them from the queue. So it's logically consistent with the UnitAI in general, but this packing AI may be unique and warrant some different behavior. Reverting to 0% slowly seems sound to me instead of instantly jumping to 0%, which indeed would justify considering to replace the cancel command with the pack/unpack command, and account for that somehow in the packing part of UnitAI. Sounds like invoking spaghetti code but, maybe inevitable. But that's the weakpoint of siege engines, they should be and remain that vulnerable during that stage, no? Agree, it must be fun to play. That proportional-progress proposal is possibly still the right thing to do, depending on expectations of logic and gameplay design. For aggressive stance, and for forced attacks in any stance it sounds reasonable to follow the attacked target. I suppose it's important to satisfy the definition of an order. If there is an order to perform X, then by definition X is ordered to be performed, and that means doing the preconditions like packing to achieve that. So one could introduce an order type (such as ground based attacks) where the siege engine attakcs units in the target area without implying that a specific unit should be attacked (thus not providing reason to have it unpack at any time). Dunno. Images may vary slightly from actual product. There are many ways to skin a cat. Doesn't require hierarchical force to commit a catapult AI fix. But for my review I need a decision whether I want to be frustrated by throwing or riding the bomb.
  9. I loaded the file in Blender and made a few checks but didn't find something inherently wrong. 1 material maximum... okay Mesh parented to the armature... okay Vertex groups... okay Did you get any error before or after those three like unable to load skeletons or something ? If you changed the rig, you need a new skeleton file.
  10. So you mean zooming animation? If yes, then you are right. I should change it to something less nauseous. The feature is already on phab on queue review.
  11. I did some extra checks after taking all that into account (changing the animations used etc...) Aaaand I think I found the issue. Seems like the rig, while present, isn't connected to the mesh anymore in my re-exported file. Which I assume makes it non-existent for 0ad. So I re-expored again with a few changes and now the rig works as intended in maya (added the file). Good. But 0Ad now tells me this With the mesh not showing up at all. Probably a Maya/export settings issue. jdr_kelpie.dae
  12. This map is not intended to fulfill the asthetic needs to be officially featured but it is playable and someone might enjoy. The environment is based on the Lonely mountain from Tolkien's universe. lonely mountain.xml lonely mountain.pmp
  13. Thanks for the summary. I'll just add to some of the points: This currently only happens for those forced orders but still it perhaps shouldn't. I'm not really sure if this depends on the stance but I don't think so. Soldiers behave in the same way in that when you make them attack a certain unit, they will do so and even follow it as necessary. We should discuss if the catapult should start moving if the selected target wasn't in its range at the beginning. Otherwise such an action would result in a no-op and the attack cursor better be grayed out for targets out of range. Regular units can't be easily told what target type to pick either, so perhaps it is a broader issue. For units, we have the attack move (with possible modifiers), but using an attack move doesn't sound right for catapults that aren't supposed to move while attacking. The item that is possibly missing: Ordering a catapult to move while it's unpacking doesn't cancel the unpacking process and waits for it to complete. This seemed to be addressed in one of the existing tickets. EDIT: Oh yeah, and regarding the instant cancellation, I understand that it's how it works in AoE but we don't take that as a relevant argument for it, right? I'd look at what looks more realistic here unless there are good reasons not to. I've even considered a similar thing regarding buildings several times (going slightly off topic now). An important part of the game currently is deleting some buildings before they get captured to 50%. But isn't that a weird thing to have in the game? It comes to mind that the destruction of own buildings might require workers to be assigned to the job. Similar to construction but faster and actually very close to attacking that building. This is actually quite a different issue but it's similar in the way that something is instant and it might better not.
  14. Oh okay. So first "static_meshes" should contain both the mesh, and the armature. animation should also contain both the mesh and the armature. However if multiple static meshes are using the same animation because the skeleton is compatible you do not need to export all the meshes as animation. The static_mesh should have the same number of bones and vertex groups than the animation. The static_mesh may not have two vertex groups with the same name.
  15. Thanks for the answer ^^ Oh so it might be precisely because I re-use the existing mesh that it does this ? Right now I didn't touch the animation dae, only the static mesh for the unit.
  16. Hello and welcome to the forums @Adrix ! Skeletons do not need to be pointed to, they are recognized automatically, this is both a good thing and a bad thing. Yeah, if it's using the same skeleton as another one you do not need to create the file. Yeah, most of the time, import doesn't work with animated DAEs, you should ask @The Undying Nephalim for the source file instead.
  17. Hi there, Newbie trying to take on modding. Right now I'm just trying to add custom units to Hyrule Conquest for @#$% and giggles before expanding on new stuff. But I'm having issues with exporting rigged models. I managed to import non-rigged meshes and have use them (thanks for the guide and tips on the discord btw, very helpful ^^). Things get more messy with rigged ones. As a start I'm only using models and animations already present in the mods, so I at least know that the problems doesn't come from the model itself. I created a new actor and template and setup everything. In the case, it's Mipha's model, just recolored and using a Zora's set of animations. The skeleton matches. If I copy paste the original Mipha's meshes .dae and point to it, it works fine (there is a small animation glitch with the tail but overall the unit works as intended). But if I open the .dae on Maya, re-export it without modification, and then point to that new file in the actor, I get this If I understood correctly there should be a xml file for each skeleton ( created using the convertor), but I couldn't find where to point out to that file. And regardless, shouldn't it work anyway since it the same Zora Skeleton already used elsewhere (unless I must change something in the dae file itself ?) ? Or is it something I'm doing wrong with the export ? Here is my setup in the attached files, if it's of any help I also added the dae file generated. Sorry to ask for assistance. I've been going in cricle with that for a few days now and I can't see myself addind my own stuff if I struggle with already made one T T'
  18. Hello, I'm new here! I wanted to add some more information about Persians nation. The face of king Cyrus II is somehow Arab lied face,  I sent a picture of a more Persian liked face structure. Furthermore, The Immortals appearance isn't like the original Immortals. ( I uploaded their picture too ) Also, Persians did not Farvahar ( the one with a ring in his hand ) sign on their shields because it was a religious sign for them. Some of them used "Derafsh Kaviani" as their flag on their shields. Also Most of Ancient Persian soldiers used Some sort of helmets which was called "Khud". You can take a look to the pictures for more information. Thank you.
  19. @Boudica What stance does this happen in? Default stance for siege units is Stand Ground, which sounds like it shouldn't exhibit this behaviour - if it does, it should be fixed. The way I understand it, there are a few things at play: Catapults auto-unpack if on "aggressive/defensive/standground" and units come in-range. That does sound wrong on most states to me. Cancelling packing/unpacking at 90% progress is instant ( @Boudica you would prefer that it takes as much time to go 0-90 and 90-0 I understand?) Catapults try following their target when it gets out of range, i.e. automatically packing and then trying to move This sounds broken to me in all cases, even for forced orders. We could do it only for forced orders, never on its own for unforced orders. Regular stances are not sufficient for catapults No way to tell them to prefer units or buildings Agressive/defensive/flee/standground isn't very helpful with regards to packing - unpacking. Is this complete? Points 1-3 seem like unitAI issues that we could fix for A24 - depending on what happens exactly. Point 4 is probably something we should do but it would be harder. Point 2 is doable also, but would be a change of behaviour - not sure if we want that or not, as @Feldfeld has said, AoE 2 has immediate-cancelling.
  20. Yeah, I know my initial post is quite long (and I tried to make it as short as possible). But let my quote myself: So I didn't suggest to let the catapult finish its current action instead of cancelling. I even later mark that as weird behavior that happens when you try to move an unpacking catapult. My idea was that if you start unpacking and get to i.e. 75% progress, then you can get to 0% in the same time by ordering the catapult to pack. You mostly only say which state you want the weapon to be in and it gets there smoothly from whatever state it is in. So neither jumping from 75% to 0% instantly (as cancelling does), neither going further up to 100% and only then going back to 0% (because there is no reason to).
  21. For me it just feels nicer to use gameplay-wise. Without the cancel i would have to stay frustrated with needing to wait for the catapult to unpack to pack it again. It is also how it's done in AoE2. Currently, the case where multiple catapults in different states are in selection is handled by having 2 different cancel buttons, although they look the same. It's also not realistic having to let the catapult finish unpack where it is at only 1% on the progress, but to be fair I don't want to have a game 100% realistic in situations like this anyway.
  22. Thanks for the replies. So it seems we can agree on some of the points. And the bugs seem to be known, we just might to check on the existing tickets. Thanks for mentioning the unit following problem. I suppose it would be taken care of by omitting the automatic packing and unpacking (while an explicit move or attack command can still have a starting implied packing or unpacking prerequisite). Not sure how to handle the case when you try to attack a target that is out of range though. I guess it shouldn't then be possible to do this to maintain consistency. If the catapult moves automatically to have the target in range, why shouldn't it start moving again if a unit goes out of the range later? I'm not sure what your reasons are to keep the cancel command in place. What do you think about the logical problem of unpacking an almost packed catapult instantly by just cancelling? How to handle the case when there are multiple catapults with different states in the selection? I don't know if I should use the unpack icon or the cancel packing icon. I see several problems with the cancel icon and I don't really see an advantage of it. @Stan`, I guess standground is the default, perhaps you meant passive instead? I'd just think that the various stances probably don't make much sense for catapults anyway. Maybe there should be one when the catapult just doesn't pick targets by itself (passive) and then the default (standground). That reminds me of another issue I forgot to mention. I don't know how the attack-move commands work for catapults but it could be useful to tell the catapults to target units in their range. Perhaps this also is solved by targeting areas. Catapults are especially powerful against units but the problem is that it's hard to make them attack units only when there are buildings near.
  1. Load more activity
×
×
  • Create New...