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 ... 16
1
Discussion / Re: Breaking lances
« on: November 29, 2007, 04:57:15 PM »
It causes them to auto-equip themselves based on their inventory at the time, I believe.

2
Modding Knowledge Base / Re: Inventory slots numbering chart
« on: November 23, 2007, 10:38:42 AM »
That latter is because the player agent, like all agents, doesn't seem to update its equipment on the fly.  Once assigned from a troop it needs a trigger (opening inventory or F-keying an onfield item seem to do it) to tell it to reassess the agent's stuff on the basis of the troop's.

3
Discussion / Re: Catapults
« on: November 13, 2007, 10:46:09 AM »
Ron, Winter was talking about finiteness in the sense of it requiring one-to-one prop placement work per shot.  We can achieve finite ammo counts by script, and only need to change a single number, if we use the spawned implementation the original poster tried.

I echo the comment - that's a brilliant implementation, well done.  Perhaps we should suggest to Armagan that the next module system version might have the ability to kick in ragdoll effects for a scene prop, perhaps for a limited time or on a triggered basis only.  Even better, let it have an initial vector we supply. Tremendous potential.

4
1) Just check the faction of the party instead of the troop.  Yes?  (You might need agent_is_ally or something to get that from an agent number, but I think you can see how at this point.)

2) The op agent_get_horse returns -1 if they're unmounted - this is right in the header_ops comments, I believe.  Then you ask "is agent #-1 human?"  The answer is, error, no such agent.  Just toss in a (ge, ":player_horse", 0) and you're fine.

5
Since as written there's absolutely no conditionals preventing the "@{s52} being checked" string from displaying, and the proper display of the other strings tells you that the queue isn't being spammed, then your try_for_range is aborting.  This normally happens when the range is zero size (the end value is equal to, or smaller than, the initial one). I did suggest you check your constants, before, and you did... but that's still fairly clearly where the problem's coming from.  Maybe you have the constants being assigned more than once?

You could put in a debug string which assigns ranged_weapons_begin and ..._end to number registers, and displays 'em... or, perhaps more simply, replace the constants (for now) with a actual items such as "itm_(the item before the one you're testing with)" and "itm_(an item a few items later in module items)" or something.

6
Discussion / Re: Skill modification
« on: November 02, 2007, 10:25:38 AM »
Nice - I hadn't noticed that, Winter.

And, Ron - if you used Winter's technique to deactivate Power Draw and activate one of the reserved skills, calling the new one "Power Draw" from the player's perspective, then you could use Fisheye's method to implement whatever curve you desire - one which drops off sharply below about 80% of max pull, say, then increases smoothly until 110% of max pull, then tapers off to virtually no effect.  Or whatever.  To the limits of your primary's willingness to add copious nearly-identical items to the mod, anyway.  As for generating the items themselves, if you use Excel to build a spreadsheet and then a combination of Notepad/Notepad++/Word to find-replace, you can build a list of entries which differ only in whatever specific variables you desire.  I can show you how to do this; it involves no coding whatsoever.

But I still think you're focusing too much on the damage numbers, dude.  In play, the effect of a PD above the "damage cap" is still large, IIRC, in terms of the stability of aim it buys you.  Which is bloody important.  If you really want to understand this process, map that effect out too, and include it in your thinking, or you'll be neglecting a major axis of effect.

7
Discussion / Re: health and everyone on the battlefield
« on: November 01, 2007, 09:15:19 AM »
Script_cf?  Winter, are you sure you aren't mixing languages here? ;)  As far as I can tell, a failed call_script acts in all ways like a failed conditional op.  It will abort a try block, it will abort & cause fail on a conditional block, and it will abort an ops block if placed in the main body of same.

Thanks for finding that example, grailknight - not sure if that was the one I originally saw, but it's a good example of what I noticed Armagan doing.

8
Modding Knowledge Base / Re: Random Notes
« on: October 30, 2007, 09:55:35 AM »
Nice.  Copying a snippet (simplified for clarity for just the bit that would apply here) from my Schattenlander code, here's how to do a bell-curve scatter centered on the aim point.  Cf. Schattenlander source, module_throwing_code, line 840.
Code: [Select]
(agent_get_slot, ":Scatter", ":Owner", throw_inaccuracy), # Value from 0 (theoretical only, proficiency 1000) to 25 (proficiency zero), tending to be 15-23 for most realistic proficiencies.

(store_add, ":ScatterUpperLim", ":Scatter", 1),
(store_mul, ":ScatterLowerLim", ":Scatter", -1),

(try_for_range, ":Iter", 0, 20),  # Worst possible scatter (zero skill, horrible luck) is 5m (20 iters x 25cm ea) in each of X and Y.  It's a strong bell curve, though, likely to tend toward way, *way* less.
(store_random_in_range, ":Delta_x", ":ScatterLowerLim", ":ScatterUpperLim"),
(position_move_x, landing_position, ":Delta_x"),
(store_random_in_range, ":Delta_y", ":ScatterLowerLim", ":ScatterUpperLim"),
(position_move_y, landing_position, ":Delta_y"),
(try_end),

It's called a "Drunkard's Walk" in random number theory and it converges to a bell curve.  Many iterations, each of which is a straight random number (such as between -25 and +25 in this example, worst case).  I could look up what the "probable" range is, but I believe it'll be somewhere around a third of the worst case in a setup like this one, depending on how you define "probably".

9
Discussion / Re: health and everyone on the battlefield
« on: October 30, 2007, 09:30:42 AM »
That's exactly what I'm saying.  See for example the Schattenlander source, module_scripts, line 1907 - script "permission" (deprecated in current version, but because its job became obsolete, not because it didn't work).  Look at the last line of the script.

I figured this out based on a Native script I saw somewhere (probably 0.808 source), but I'm damned if I can now remember which one.  Test it yourself!  Very useful.  It's nonobvious because it mostly doesn't occur to us to put conditionals in the main body of an ops block, outside of any tries.

10
Discussion / Re: health and everyone on the battlefield
« on: October 29, 2007, 04:42:35 PM »
Generally speaking if your messages are disappearing this means you're overloading the message queue.  Turning edit mode off may help (gets rid of the red "opcode error" and similar).  Otherwise you basically need to be using fewer debug strings, or isolating debugging from normal play more.

11
Modding Knowledge Base / Re: Random Notes
« on: October 29, 2007, 10:20:34 AM »
Thanks, KON_Air.  That was the thing I was wondering about that op.

Note from my previous work, I assume it's still this way in the new version... if the agent is at zero HP, then he dies as soon as he takes any hit - even one which does zero damage.  So if you want to do damage which ignores armour, you can probably use:
Code: [Select]
(agent_get_hit_points, ":agent_hp", ":tgt_agent", const_absolute), # Absolute = 1, relative = 0.
(val_sub, ":agent_hp", ":damage_value_ignoring_armour"),
(val_max, ":agent_hp", 0),
(agent_set_hit_points, ":this_agent", ":agent_hp", const_absolute),
(agent_deliver_damage_to_agent", ":source_agent", ":tgt_agent", 0),
... basically using the deliver_damage to force a check for "is it dead".

Have you checked whether (set_show_messages) works on the damage output messages?

12
Discussion / Re: health and everyone on the battlefield
« on: October 29, 2007, 10:06:58 AM »
I'm not sure where to pull the questions out of there, but...

There is no formal equivalent to the "return" statement.  These aren't functions in the sense that they have a return value; they really are scripts, which execute without being assigned a value.  Some people like to assign a return value to reg(0), in mimicry of the way Native operations handle this; others (including me) prefer a single global variable "$return" for the same use.

However, there is one exception.  These scripts can return a boolean - more specifically, they can succeed/fail in the same way that (eq) or (troop_slot_gt) can do so.  They return "true" if the uppermost layer completed all its operations successfully - the normal case, you do everything in the body of the script, hit the closing bracket, and stop.  They return "false" if their uppermost layer - that is, outside of any try statements - hits a statement which fails (aka returns false).  (Also note that if it does so, just like a try block, the script itself will abort immediately and will not execute any code which follows the failed statement.)  So, for example, in your code, tidying and adding one crucial line:
Code: [Select]
("has_ranged",
  [
  (store_script_param_1, ":agent_no"),
  (try_for_range, ":ranged_wpn", ranged_weapons_begin, ranged_weapons_end), # Clarity is good.
     (agent_has_item_equipped, ":agent_no", ":ranged_wpn"),
     (assign, ":has_ranged_wpn", 1),
  (else_try),
     (assign, ":has_ranged_wpn", 0),
  (try_end),
  (eq, ":has_ranged_wpn", 1),  # The important bit - a boolean op not enclosed by any tries.
  ]),
... means that you can just call (has_ranged, ":this_agent"), and if they have a ranged weapon you'll carry on, if they don't then this will stop the current try block just as if the script call itself had been an (eq, 0, 1), statement.

Obviously in this case you'd want the inverse of this.  I'm not sure, but I suspect that you could use (neg|call_script, "script_has_ranged", ":this_agent"), to get the correct result.  Test it with something simple - (neg|call_script, "script_does_one_equal_zero") or something.

13
Modding Knowledge Base / Re: 0.89x game_menus - index
« on: October 25, 2007, 04:09:27 PM »
Correct.

14
Discussion / Re: health and everyone on the battlefield
« on: October 25, 2007, 03:07:29 PM »
Erm... your code right now will (each time it evaluates) only heal until it comes to an agent on the list who can't be healed, and then stop.

The statement (assign, ":do_nothing", 0) is basically a comment.  It's not required and could be omitted without changing anything; I assumed you were more comfortable having it there than having the block actually have nothing in it other than tests.  But you shouldn't be checking it!  There's no need; just drop the (neq, ":do_nothing", 0) entirely.

Oh, and BTW - "eloquence" is fancy speech, wise or witty or persuasive use of language.  "Elegance" is a quality of conciseness and efficiency which can be possessed by, among other things, code.  I think you mean the latter.

15
Discussion / Re: health and everyone on the battlefield
« on: October 25, 2007, 12:55:49 PM »
I suggest an explicit check.  Set up a trigger to call up your horse's agentID, get its troopID, assign that to a register, and display it in a debug script.

If the answer is that (agent_get_troop_ID) is returning the troop_ID of its rider, then that may be your double-tap, yeah.  Sounds consistent with what you're seeing.

I don't know if you've noticed this op or not, but you can explicitly exclude horses easily with (agent_is_human).  Sounds like once you're done debugging (or stuck) you should definitely be using that as a filter on the whole shebang.

Pages: [1] 2 3 ... 16