搜索结果: *

Drift 说:

lol well I think we pretty much know the problem now, it seems to be the calulation only really takes into account the number of units, rather then the types. Ideally the algorithm should even take into account what happens when units like spearmen go up against horses (obviously spearman have an advantage), but I doubt it touches on that atm.

点击展开...

It definitely doesn't. The only consideration that's made to the actual troops present is their level.

Basically it works like this:

- The defender makes a number of attacks equal to the number of troops they have (but not less than 30)
- Each attack is made against a random member of the opposing party
- The chance the attack has an effect is  1 / n+5 (where n is the targets level)
- Attacks that have an effect will be 50-50 wounded / killed target
- After defender makes all their attacks the attacker-party repeats the procedure (only counts troops not wounded/killed by the defenders attacks)


Farmers have a level of 4, which gives them an 11% chance of being affected by an attack ( 1/(4+5) = 1/9 = 11.111%). On pretty much the other end of the spectrum are the Hired Blades, which at level 25 has about a 3% chance of being affected by an attack (1/(25+5) = 1/30 = 3.333%).


On average, 10 Hired Blades attacking a party of 100 farmers would expect to see an average result something like this:
- 100 farmers make 100 attacks
- Each attack has a 3.33333...% chance of inflicting a casualty, so 3 Hired Blades would be hit by the attacks. You'd expect to see 1 wounded, 1 killed, and 1 either wounded or killed.
- The remaining 7 Hired Blades (wounded troops don't attack) make 30 attacks (a party never makes less than 30 attacks).
- Each attack has an 11% chance of inflicting a casualty, so with 30 attacks you'd expect to see 3.3 casualties. So 1 wounded, 1 killed and 1 either wounded or killed.


The scripts themselves are fairly straightforward, and shouldn't be too hard to mod if someone felt motivated to do so.

Most likely you're playing the game on reduced difficulty (friendly troops take less than normal damage). The difficulty settings are not considered in battles you are not active in.

It's also probably worth mentioning that the types of troops in a party does not affect the amount of damage that party deals out, only the chances that your troops are injured/killed in the fighting.

mod(x,y) take the value of x modulo y and puts it in x.

Basically, it puts the remainder of x/y in x.
For instance, 7 mod 3 does: 7 / 3 = 2, with a remainder of 1 ((3*2)+1 = 7), so the value 1 is put in x.

I got the impression Rathyr meant "I'm already addicted and dread how badly I'll be addicted when it gets to 1.0".
I know that I, for one, feel that way.

A trigger basically looks like this:
(check_interval, delay, cooldown, [conditions], [statements]),

Where check_interval is how long (in hours) between each time the trigger is checked.
delay is the amount of time between the trigger-check is performed and the trigger-statements are executed.
cooldown is how long between a trigger is fires before it can be fired again.
conditions are a set of statements that must be "true" for the statements to be executed.
statements are what the trigger "does".

So,
Means: "Every 1 hour fire this trigger. When the trigger is fired assign the value 6 to the global variable $peak_my_type_of_guys".
The ti_once bit means the trigger will only trigger once, once it's triggered it will never be checked again.

means
Every 3.7 hours fire this trigger if:
- the number of parties from the template pt_my_type_of_guys is less than $peak_my_type_of_guys (which the first trigger set to be 6).
When it triggers:
- Spawn a new party from the template pt_my_type_of_guys


Together the two triggers spawn a new party every 3.7 hours as long as the number of parties from that template is less than 6.
So, never more than 6 of the guys out, if less than 6 guys are out spawn a new one about every 4 hours.


Hope that makes sense.

Dwinny, I can't see any specific errors in the code you posted, so I'm as much in the dark here as you are, I'm afraid.

Try sticking the store_conversation_troop and item_kind_count in the check-portion of the dialog-entries, rather than the result-portion of the previous dialog.
Basically,
instead of

From just thinking about it that shouldn't do anything, as as far as I know registers keep their values between dialog-entries, but it's the only thing I can think of so should be worth a try.
At least you definitely rule out problems in the dialog-entries themselves if you try that and it still doesn't work, which is better than nothing.


PS. I want to apologize for perhaps sounding slightly acerbic in my last post, it was wholly unintentional.

Dwinny, since you didn't say what the actual problem was I'm forced to resort to psychic debugging, so here goes...

I'm getting a name .. Bob, an old man, perhaps your father? Or an uncle? No, wait, that was something else.
Let me try again...

I'm going to assume that "Dory" is supposed to be "Doru" (dory is a type of boat, a doru is a greek spear).

Are you sure your troops don't have multiple spears/swords? AFAIK troop_remove_item will only remove 1 if they have multiple (although I could be wrong about that).
Are you sure your troops have both swords and spears?

As you can no doubt tell my psychic powers are a bit on the poor side this week, so I feel forced to ask you to explain what the problem actually is.
Does the dialog itself not work? Does the dialog work, but your troops are using a different weapon than you're asking? Are items not properly added/removed? Do you not get the dialog at all?
Please, more details.

If you look in the module_game_menus.py file, at around line 340, you'll see the following code:
Simply do a call_script between the (gt, reg0, 0), and (change_screen_loot, "trp_temp_troop"), lines that calls a function you make. In that function you can modify the items shown in the loot-screen by playing around with the inventory of the trp_temp_troop troop.

Bryce: Scopes in m&b are somewhat looser defined than that. You could think of the scope as the outmost block of code containing the statement. That sentence is a bit vague, I realize; in practice each script consists of one block. Any local variable referenced in a script is defined for all portions of that script, regardless of try-blocks.
For trigger the conditions are one scope, and the "body" is another separate scope. The same principle holds for dialogs, etc.

Morgoth: String registers have two uses, and two uses only:
1) You can put values in them using the various str_store_xxx commands (which you can find in header_operations.py); and you can clear them using the str_clear command.
2) They can be referenced in strings displayed using the display_message command, using the notation {s#} where '#' is the number of the string-register.

For instance, if you have an entry in your module_strings.py file that looks like this:
and a script with the following code:
then that piece of code will display the message
when it's executed.

The {s10} part in the string-entry means "put the current contents of string-register 10 here", while the (str_store_party_name, 10, "p_zendar") part means "store the name of the party p_zendar in string-register 10".

The only trigger(s) I've found that deals with river-pirates spawning are these:
Creating similar triggers like this should work:

If your code doesn't work perhaps you could post it here, as psychic debugging is kinda tough.

I believe he wants ideas for hero-NPC's to include in his mod, but without giving any sort of details as to the setting of the mod that's going to be a bit of a hit-and-miss afair to supply, IMO.

It might be worth asking yourself the question of wether it's necessarily important for players to design the coat-of-arms in-game, or wether it's better to have a third-party app to design the coat-of-arms and have the game decide when you can have it available.
This probably precludes the possibility of having a national "pool" of possibly designs, but a free-standing app will have none of the limitations that M&B would enforce due to its user-interface.

Just a thought.

I meant in the existing mb script-language.
For the thing I'm working on there is currently language-support for multiple return-values, but only because some of the built-in scripts in the module-system returns multiple values and interopability is a major concern for me. It does give me the shivers to work on, though, as it introduces a lot of complexities I'm not terribly fond of, but that's them breaks.

Yoshi: Yeah, currently operators only support 3 operands, which would obviously have to change to allow passing more than 2 arguments directly, but I am after all asking for things to change to begin with.

Helle: Yeah, all blocks including scripts end on a false statement, but only the innermost block, so this:
which is roughly equivalent to
won't work, as the (eq,1,0), part only breaks you out of the try-block, not the script itself. Currently there is no reliable and simple way to end a script from within a try-block, which is fairly cumbersome.

Bryce: Returning values from scripts would be nice, but it would require a statement that would both assign a value to a variable and call a script in a single go. Including supporting scripts returning multiple values (for instance, the native script "calculate_party_shares" returns two values), and multiple return-values is not exactly trivial to support.
I can't for the life of me think of a reasonable syntax conforming to the general mb-script syntax that would let that happen.
In the meantime, registers and global variables for the win, I suppose.

A reliable way to exit a script without letting it run to the finish-line. A (script_exit) command, basically.

Support for passing more then 2 script-parameters via the call_script function rather than having to use global variables.
Speaking of which, would like to see (store_script_param_1,":var"), (store_script_param_2,"ther_var") replacable by (store_script_param, 1, ":var"), (store_script_param, 2, "ther_var").

A proper loop-construct.

I tested it, and it worked fine.

I was actually a bit surprised that it did, to be honest, as trying to manually tinker with the "iterator" value fails miserably in a try_for_range loop (I'm guessing the script-engine explicitly resets the "iterator" to the expected value each loop). Nevertheless, it appears to check the actual value each time if the end-value is given as a variable.

Wanted: While-loops...
Something that works like this, for instance:
Basically, if any condition inside the (try_while)...(try_end) block fails the loop breaks out. If the code reaches the (try_end) without any conditions failing, jump to the beginning of the block again.

While (try_for_range) is very useful the lack of a proper while-loop is fairly limiting.

I agree, there's not UI-design reason that the dialog-options should be buttons, in fact it's rather distracting (I assume there's a programming reason for it, though).

I really have a lot more knowledge and experience in this than is likely for many people to have, and talking to you it is quite obvious you do not but very few people do

点击展开...

You do seem to have a habit of making completely unwarranted assumptions about people.
As I already mentioned, you're not the only person in this conversation with experience in UI-design (although you do seem to be the only person who feels the need to continuously mention the fact even when no-one is accusing you of having little experience).
As a matter of fact I've spent the last 5 years in a job where I'd estimate I spend about 25% of my time designing user-interfaces in co-operation with what I will blindly assume I can accurately call "people like you" (I don't mean that in a diminutive way, only to say that they spend most/all of their time designing UI's), and the rest of my time actually implementing said user-interfaces programatically.

My contention is still that given the current state of the M&B dialog-UI it is a lot more intuitive and simple for people to use it with scrollbars on option-overflow than it would be to use pagination instead. It certainly is so for me (no matter how many times you try to make claims to the contrary, I do know what I myself would prefer better than you do).

From a strictly design-point-of-view scrollbars are generally something you resort to when you have a design that is in some way already defective, generally as a "quick fix" to the problem rather than a real full solution, as you will nearly always get a better result re-designing the UI so that you can present more information on a single screen, or so you don't need to present as much information in the first place. From this point of view you can generally get away with calling scrollbars awkward.

The dialog-UI has a lot better options for improvement than trying to get rid of the scrollbars, though, including (as you have already pointed out) giving more screen-space to the display of the dialog-options, and making the options themselves clickable text rather than buttons in order to fit more of them in.

No, I want it to stay the same oh my god what will I do!

点击展开...

That is indeed a common problem when talking to "average" users about changes to user-interfaces, but for you to assume I fall into that category, even when I have contended that I do not and provided at least some indication that I'm not completely brainless, is quite frankly a bit insulting.

In my opinion the following should be done with the dialog-UI:
- Increase the screen-space given to the display of dialog-options
- Decrease the amount of screen-space necessary for each option (make it clickable text rather than buttons)
- Keep using scrollbars when there are more options than can be displayed simultaneously
- Optionally allow a dialog-option to have a small icon next to it, that can be used as an indication of the result of the dialog (crossed swords for starting battle, or whatever)

I think that was perhaps the single most condescending reply I've read on these forums...

You only think you would prefer that because you haven't used the other option and can't imagine how much better it would be

点击展开...

I'm not sure where you're getting the feeling from that you know more about what I'm thinking, and why, than I do, but I can assure you that you are incorrect.

In fact if you aren't a modder it's very unlikely to have come up as an issue because it sucks so much people avoid it like the plague.

点击展开...

Actually, I *am* a modder, and the issue *has* come up. I'm not claiming scrollbars are the ultimate solution, but I would much rather have all available options on a single page than suffer through needless pagination.

Like I said it's a subect I know a lot about and these are not ideas that come out of my own head

点击展开...

You, sir, are not the only one with actual experience in the design of user-interfaces in this discussion. The fact that you automatically presumed I wasn't, hadn't even thought about the issues, and only think scrollbars are more usable to me than other options due to a lack of imagination speak volumes.

The fact is, how usable a user-interface is to someone is individual. Some people vastly prefer scrollbars (they may be lazy and can't be arsed to hit the place where you put your "more" button and would much rather just scroll wildly on the scroll-wheel, for instance), some see scrollbars as an indication of lack of overall continuity of design of the information they're presented.
To some degree you can make certain assumptions about what people are likely to expect from a user-interface (and this will generally be what they like the UI to behave like; unexpected behavior makes people annoyed) based on things like how Windows does it (for a majority of users, how Gnome, KDE or other interfaces does it for some users), but these are merely basic assumptions, not gospel truths.

People who have taken courses in various forms of interface design, but have a lack of actual real-world experience with it, tend to take the maxims they have been taught as inviolable truths, and any instance of breaking them as "poor design". This sort of mind-set tends to clash rather abruptly with more real-world oriented designs, though, where a lot of actual practical issues needs to be considered and not just the theoretical "correctedness" of the design.
I'm not saying you're one of those people, but your attitude strongly reminds of the people I've run across who's had more education in UI design than experience.


So, basically, the fact that I personally prefer scrollbars over pagination in a situation that happens to include rows of buttons should in no way be ascribed to a lack of imagination on my part. Seriously, where did you get that idea from?


And in an effort to not completely and utterly derail this thread from the original (highly useful) purpose of the modding community giving feedback to the developers of this game I hope the sidebar on how unimaginative I obviously am because I like scrollbars can be put to a rest at this point, and we can let the thread get back on topic...

You speak as if the design of user interface elements are objectively good or bad, which is not always the case; very often it's the expectations and past experience of the user that determines the usability of UI elements for that person.

In this specific case, for instance, I personally would massively prefer keeping the scrollbar and binding it to the scroll-wheel than having one or more "more" buttons at the top and bottom of the list of options.