Jump to content
The Dark Mod Forums

grayman

Development Role
  • Posts

    13591
  • Joined

  • Last visited

  • Days Won

    199

Everything posted by grayman

  1. In the context of this discussion, when you see "~", read it as "the key that puts weapons away". It's not hard-coded to the "~" key.
  2. Nice catch. I made a small DLL change and committed it to the src (player.cpp) and game (tdm_game01.pk4) trunks for those who use the trunks. 1.03 players can apply this new patch: http://www.mediafire.com/?jhxj1dmuptfcn3b
  3. You'll find a 1.03 patch here: http://www.mediafire.com/?6t2y4b7c7dbwebb Make sure you read the README_FIRST.txt file inside the zip file.
  4. I'm trying to create a 1.03+ "patch" you can apply to 1.03. The changes are in the scripts and the DLL.
  5. Sorry. I didn't know that would happen. Anyway ... The weapons changes are committed for #597. Please try it out and post comments. I think I accommodated everyone. Here's how it works: Arrows If switching from one arrow type to another, the drop bow and raise bow animations no longer play. The arrow type changes and an equip sound plays, to indicate nocking a new arrow. If you have the bow raised to fire (attack state), switching to another arrow type lowers the bow, selects the new arrow type, and puts the bow into its idle state. When an arrow is fired, and more of the same arrow type remain, the equip sound plays to indicate nocking another arrow. All Weapons If you switch weapons, the current weapon is replaced with the new weapon in its idle state. (If you hit ~, no new weapon appears.) If you switch weapons when the attack button is depressed, the attack animation ends, the weapon is lowered, and the new weapon appears in its idle state. The continued depression of the attack button and its subsequent release are ignored. (If you hit ~, no new weapon appears.) If a weapon is in the attack state and the BLOCK button is pressed, the weapon returns to the idle state. All three weapon types behave this way, even though BLOCK only works with the sword. Sword If the sword is in the BLOCK state and you switch weapons, the sword is sheathed and the new weapon appears. (If you hit ~, no new weapon appears.) Request for someone to look at an animation: Whoever does animations needs to look at dropping the blackjack from its attack state to its idle state when you press the BLOCK button. The blackjack and the hand currently become separated as they lower, and it doesn't look good. I committed a Windows DLL that you can pick up with a trunk update.
  6. The weapon changes are in. Read this.
  7. I've only had one run-in with gui scripting (SATC briefing), but I wonder if, instead of separate blocks for each objective, can there be one large text block per objective screen, with the objectives pasted in one after another with one line separating each? This would solve the spacing problem, and also allow for objectives longer than 3 lines.
  8. where is the ai's clip model through all this?
  9. Everything's working, but I need Aprilsister's answer to finish out the RMB request. I also added NH's arrow equip sound after you fire an arrow, to represent nocking a new arrow if you have any left.
  10. What action do you have your RMB set for? Your wording implies RMB cancels an "about to fire" weapon by default, but in my setup it does nothing.
  11. Great minds think alike. I've already come to the same conclusion after examining the blackjack script. Since the idle state already has a path to the lowered state, it's easiest to create a new transition from the attack state to the idle state, then force that to go immediately to the lowered state. I'm hoping the other weapon scripts are set up the same way.
  12. Good point. I'll make sure RMB aborts each weapon's attack in the same manner.
  13. Reselecting the current weapon is currently ignored, and that won't change.
  14. Here's the plan, which I described only yesterday in the "Grayman's working on ..." thread: ------------------- When you switch weapons, the current weapon should be replaced with the new weapon, even if fire button is depressed. If it is depressed, then the code should ignore the subsequent release. TDM weapons are two-phase weapons: fire button down prepares the weapon, and fire button released fires the weapon. A weapon switch before release should abort the release. So if you have the BJ raised to strike, and you switch to the sword, the BJ would lower and be put away, the sword would be unsheathed and put into its idle state. Not raised to strike. And if you have an arrow nocked and raised to fire, switching to another arrow would lower the bow, select the new arrow, and put the bow into its idle state. Not raised to fire. Identical behavior to hitting the ~ key. ------------------
  15. I think this is a great idea. It would be a good place to not only deal with FM betas, but also code change betas.
  16. I researched this this morning and I have to humbly eat my words. W/O giving anything away, there is a custom movable object in the mission whose mass I changed to zero at one point during development to keep it from being blown away under certain circumstances. By the time the mission was released, those circumstances were no longer possible, but I neglected to reset the mass to the custom setting of 0.6. Since it's only caught by an assertion with Debug DLL's, the problem never surfaced during normal gameplay. Good catch, and I will keep this in mind for future missions. There's no need to release another version of SATC to fix this.
  17. Dmap certainly does have a memory leak. The amount of memory in use after dmap runs is greater than before it runs. Since dmap's output is written to files, there's no reason it should keep anything in memory when finished, but it appears to not return all the memory it requested. When working with large maps, I can't have DR and TDM running at the same time. I've found that the optimum way to work is to dmap to make sure there are no leaks, then kill TDM and DR, then restart TDM. I don't know if TDM itself has a memory leak; I've never measured that.
  18. TDM source code has numerous places where assertions fail with a Debug DLL. I don't know if the dev team has a history of eliminating them, but I myself haven't tried finding the root cause of any. You can push through them by selecting "Ignore", which is what a Release DLL does, which is why they don't normally show up. Btw, I make no specific mass settings in Somewhere, so what you're seeing isn't specific to that mission.
  19. Thanks, Sotha. I skimmed through the Wiki. I'm interested in the button-controlled briefing. Though everyone has their own tastes, I'm hoping that button-controlled briefings prevail in future maps, for the simple reason that it's easier to debug a map when one doesn't have to continuously sit through a long timed briefing, since the ESC key won't drop you out of a briefing correctly. (I'm sure someone will now tell me how to skip a briefing; I haven't looked in the code yet to find how to do that.)
  20. @Aprilsister: savegame loads up fine. That guard is really stuck. This will help in testing, thanks.
  21. There's something wrong with the way ESC is handled during briefings. The comments in the briefing template say that hitting the ESC key returns you to the main menu, but the code doesn't behave correctly.
  22. Could you make this available in zip form? I have neither rar nor torrent installed on this system. Thanks. I got the impression that stgatilov was looking into the zip situation, so I'm not planning any work there.
  23. Knocking the texture use down to a few and deleting all the grime patches didn't help much; I'm still practically frozen in the courtyard beyond the guardhouse. So I can't use this for a test case.
×
×
  • Create New...