Show Posts

You can view here all posts made by this member. Note that you can only see posts made in areas to which you currently have access.

Messages - Hellequin

Pages: 1 [2] 3 4 ... 16
Discussion / Re: health and everyone on the battlefield
« on: October 25, 2007, 11:57:10 AM »
(Amusingly, the only programming class I've ever taken was a rock-simple first-year university course in, of all things, Fortran.  I'm a physicist, working as a technical officer in nanotechnology.)

My recollection had been that unconscious troops failed the "agent_is_alive" check, but an easy alternate approach since you're checking their health anyway would just be to drop the is_alive check and instead of (lt, ":this_agent_hp", 100) do (is_between, ":this_agent_hp", 1, 100).  This should tell you if the KO'd companions are the ones being healed.  My guess is that they are, because there's really nothing here which could cause it to multiply evaluate on a single agent.

As for your (is_between, ":this_agent_trp_id", troop_lady_favor_begin, etc_end) portion not working, maybe you should try commenting out this check and replacing it with an explicit (eq, ":this_agent_trp_id", <the troop I'm checking>) instead, to isolate the problem.  Also double-check your constants and their spelling, etc.  Basic troubleshooting; it's probably something very simple, once you find it.

As for elegance, one thing you might consider is running the checks backward - have the first branch be satisfied if it should do nothing.  This may make the logic simpler in practice.  For example:
Code: [Select]
(store_troop_faction, ":this_agent_faction", ":this_agent_trp_id"),
  (this_or_next|neq, ":this_agent_trp_id", "trp_player"),
  (this_or_next|lt, "$knight_class", 1),
  (lt, "$grail_pilgrim", 1),
  (neg|is_between, ":this_agent_trp_id", companion_knights_begin, companion_knights_end),
  (neg|is_between, ":this_agent_trp_id", troop_lady_favor_begin, troop_lady_favor_end),
  (neg|is_between, ":this_agent_trp_id", kingdom_knights_begin, kingdom_knights_end),
  (faction_slot_eq, ":this_agent_faction", slot_ladys_favor, 0), # Set this to 1 on the player faction as well as kingdoms 1, 3, and 5, during game init.  Remember to define the slot constant in module_constants.
  (assign, ":do_nothing", 0),
  # All your healing code goes here, since it's all identical.  While debugging you need to know which kinds have been healed, but you can now use simpler try checks for that - no checking faction and so forth.

Discussion / Re: health and everyone on the battlefield
« on: October 24, 2007, 12:32:11 PM »
If you crack open Schattenlander's "classify_items" script (located in module_scripts), you'll see where I take the "ordering your items" to the next, more complex, level.  The nice thing about isolating everything into that classification script was that it functions much like defining the constants - if I alter something in module_items, I know exactly where to go to accomodate those changes.  One script.

You could do the same thing here, if you prefer.  Then you replace the is_between call with a call to the script, and an (eq, "$is_this_a_ranged_weapon", const_yes) or whatever.  The nice thing about that is that having called the script, you can also get out of it something like "$magnitude_of_prayer_bonus" from the one script call.  Even more elegantly, write a specific "wrapper" script, "script_is_ranged", which calls the classification script internally, and returns a boolean.  (Huh, you say?  If a script's main ops block aborts due to a false statement, such as (eq, 1, 0), instead of completing normally, the script itself is "false" and will register as such to the block that called it, serving much like an (eq) or (gt) operation.)

As for your invocation mode, it's a good idea.  It has a lot of room for chrome, too.  For example, after implementing the main part and getting it working, you could work on a presentation which slowly buids a heavenly glory effect onto the screen, as they hold the key down, culminating in a flash of white perhaps.  I would suggest one thing, though... rather than requiring that they stand perfectly still, give a little leeway (50cm?).  I don't know that the various "impatience" animations don't displace the player's position slightly.  Also if they're mounted you might consider checking it vs. the horse instead, though that gives mounted a substantial advantage; you might instead want to require that they dismount.

As an alternative, use a set of triggers which checks if any of the other game keys (such as move forward) have been clicked, and if so sets a "cancel prayer" flag.  Note that in this version you can just have the prayer key be clicked, not held, which frees you from writing code to detect states such as (key held -> prayer starts -> other key clicked -> prayer cancelled -> prayer key is still being held -> prayer starts again).

The other nice thing I'd suggest for special effects would be to make the camera dramatically circle the PC during the prayer sequence.  An animation would be nice but, alas, I don't know how that would interact with other animations such as being knocked down.  Any of these things can be implemented after the functional part is working, though.

Discussion / Re: health and everyone on the battlefield
« on: October 24, 2007, 09:54:13 AM »
Sounds familiar - very similar to lots of stuff I do in Schattenlander.  A couple of tips:

1) The loop you're looking for is (try_for_agents, ":agent"), no other args necessary.  Note that I recommend using ":this_agent" or something (and associated things like ":this_agent_hp") just to avoid potential confusion once your scripts get more complicated and involve multiple loops.

2) It's quite easily possible to run a separate trigger at the start of the battle to store their initial HP, if you like - probably in an agent slot, there's plenty of those unused.  However, for the first run-through you might want to consider using the "relative" version of store_agent_hit_points (last arg zero or omitted), in which case you'll just get a percentage value.  If this isn't 100 you know they're wounded.  Likewise on the healing stage, a percentage of their max might be a more appropriate benefit.

3) To check for ranged weapons you've got three choices.
3a) You could try using the new operation agent_get_class.  This will tell you not "do they have a ranged weapon" but "are they considered an archer (grc_archer) by the core engine" with all the vagaries that brings.  You'd need a separate check for heroes, for example, and I'm not sure what you'll get on a mounted archer.
3b) For this or the next one, you need to make sure that the items are properly ordered in module_items.py.  In Native this is (now) the case.  Warhammer mod has a different item list so you'll have to check.  Once it's ordered so that the ranged weapons are all grouped together, and the constants ranged_weapons_begin and _end are correct in module_constants, then you just loop through them, using a (try_for_range, ":this_item", ranged_weapons_begin, ranged_weapons_end), and use (agent_has_item_equipped) to check for it.
3c) Use (agent_get_wielded_item), presumably only right hand is necessary.  Then use (is_between, ":this_item", ranged_weapons_begin, ranged_weapons_end), and you're done.  This version will only trigger, then when they not only possess but are actively wielding a ranged weapon - this may be a bonus or a flaw depending on what you were looking for.

The rest you should be okay on.


Modding Knowledge Base / Re: Sadness! Script param cap.
« on: October 19, 2007, 10:24:38 AM »
Ah, well.  At least it's plenty high.

And, heck, you could always write a standard script which goes something like this:
Code: [Select]
  (set_script_param, "$Extended_param_1", 1),
  (set_script_param, "$Extended_param_16", 16)

... if you really want to keep consistency.  Two calls still ain't bad.

Hero & Blade / Re: Hero & Blade 808 Z!
« on: October 15, 2007, 03:04:35 PM »
Yeah, those particle effects were a stand-in waiting for someone who actually, y'know, knew something about particle systems to stand up. ;)

Cartread - at this point you've got a whole lot of options in terms of making magic, the new module system opens up whole kinds of potential.  Just as an example, if you filled a 'hidden' room with frogs, (agent_set_position) could probably let you swap out a targeted orc, swap in a frog at the original position, prorate the frog's HP according to the original's, and presto (squish).  If you do decide to pursue it, I'd be willing to contribute some scripting effort to the cause.  Hero & Blade is cool.

Mwirkkk... thanks!  I had a flurry of interest via email shortly after posting, but nobody followed through.  Reposting it may, if nothing else, let us roll again for that critical 100 on d% that seems to be necessary for this kind of recruiting... ;)

Modding Knowledge Base / Re: Python script/scheme/source exchange
« on: October 15, 2007, 02:36:26 PM »
Note on Winter's above script - one elegant feature of the parameters system is that it auto-fills zeroes if there are fewer parameters than requested*.  So in Winter's example, it would be more cleanly expressed with the five zeroes at the end omitted - just the trailing ) after ":faction".

* Caveat - not yet tested on (store_script_param), this is 0.808 behaviour from (store_script_param_1) and its twin, not to mention all of the header_operations ops.

Modding Knowledge Base / Re: Item modifier (imod) Reference Table
« on: October 04, 2007, 09:48:04 AM »
What changed?

Discussion / Re: .892 module system discussion
« on: September 28, 2007, 04:42:43 PM »
That would indeed be a way to do it, esp. if it was resource-expensive and we wished to reduce the algorithm from O(n^2) to O(n), but in this case no - looking at Armagan's code, it simply covers a square region centered on the indicated troop, width equal to twice the "radius" (not a radius at all), cropped by the battlefield edges if necessary, and then measures every point within that on a 1m grid spacing and uses the absolute highest. 

(In fact, looking at the code, because of the asymmetric way try_for_range handles its endpoints, Armagan's script always looks slightly further in the -X and -Y directions than in the +X and +Y directions.  You'll tend toward highest hills to the southeast of the focus troop.  Not really an issue, just funny.)

Discussion / Re: .892 module system discussion
« on: September 28, 2007, 01:17:31 PM »
Highlander, are you sure?  In that case Native's script_find_high_ground_around_pos1 shouldn't do anything, which would affect the initial behaviour of parties with over 25% archers (per script_select_battle_tactic and script_battle_tactic_init).  I haven't played 0.89x enough yet to notice - do enemy parties with over 25% archers actually start combat automatically holding position on their nearest local high ground?

Discussion / Re: .892 module system discussion
« on: September 28, 2007, 09:43:31 AM »

One idea that occurred to me is to make a mini-presentation of a swirly mostly-transparent thing, and when fighting demons to detect the mouse position and just swirl this around under your cursor.  This could even have indicator functions (ensorceled, stunned, whatever) if desired.  Lots of potential there.

Discussion / Re: .892 module system discussion
« on: September 28, 2007, 09:20:12 AM »
Yeah - I looked through that earlier.  It appears that the "button" object-in-presentation types carry their being-clicked code inherent to the type.

And, Fuji, I think the only effect of those position constants is to eliminate the previous need to use straight numbers for position referencing.  Now you can use pos8 instead of 8.  Any of us could have done this as well, and some may have, but I know it didn't occur to me and I'm grateful that you caught that.  I don't see any indication that they're new in function compared to the old positions (which were effectively position registers, if you prefer), and since they're simply constants you don't even need to go back and change the old code, they're just for clarity.  And, for reference, a position isn't just a vector; it contains its facing direction as well as its location, so it's encoded according to some kind of (x,y,z,pitch,yaw,roll) scheme.  Judging by the retrieval operations, I'd guess it's stored as rotations around the global x,y, and z axes.

Discussion / Re: Math operations in module system
« on: September 28, 2007, 09:11:32 AM »
Your second option proferred - it'll be equal to lower bound if lower than that, it'll be the value unaltered if it's between lower and upper bounds, and it'll be the upper limit (upper bound minus one) if it's at the upper bound or beyond.

To pick an example usage:  You have a script which selects a merchant at random from the merchants list.  However, not all merchants are created equal, you've got 'em ordered by nicest to nastiest, and some towns have a modifier (tend to have a nicer or nastier merchant than the norm).  One way to do that would just be:

(store_random_in_range, ":merch", merchants_begin, merchants_end),
(party_get_slot, ":modifier", "$g_encountered_party", merchant_qual_modifier_slot),
(val_add, ":merch", ":modifier"),
(val_clamp, ":merch", merchants_begin, merchants_end),

It's handy because it means that instead of maintaining careful "data range integrity" throughout a series of operations, reasoning out by what means it could escape its expected bounds and covering those individually, we can insert one operation and ensure that it'll produce an answer in the range we're looking for.

Discussion / Re: .890 and high damage numbers
« on: September 27, 2007, 02:28:15 PM »
Thanks, Fisheye. Quite right.

Discussion / Re: .892 module system batch files
« on: September 27, 2007, 12:34:57 PM »
I glanced at the check_tags one.  It appears to run an additional routine which goes through and identifies all unused objects of all kinds.  That is, scripts that never get called, troops that never get instanced, templates never referenced, and so forth.

Looks like a really handy tool, actually, for mods built on Native or with legacy code kicking around.

Pages: 1 [2] 3 4 ... 16