Module System Requests

[othr]

Really simple request: detect missing/mismatched (try_end) statements.  As it stands right now the thing compiles fine with such errors and even runs.  This should be a priority, finding such statements is nearly impossible right now.

That and perhaps bring the new warband code up to snuff with the previous versions of the module system.  Some of it is terrible, such as (initialize_aristocracy), why this monstrosity?

 

[GetAssista]

Really simple request: detect missing/mismatched (try_end) statements.  As it stands right now the thing compiles fine with such errors and even runs.  This should be a priority, finding such statements is nearly impossible right now.

Write properly structured code (with all the indents and stuff), and you won't ever have this problem. I don't have it at all

 

[xenoargh]

I would like to have the following:

tf_is_infantry, tf_is_archer, tf_is_cavalry (auto-assigns Troop to that class, regardless of equipment). 

It is very annoying that you can't give infantry missile weapons via tf_guarantee_ranged without them suddenly becoming "archers", amongst other problems.  Players can fix this issue in-game, by manually re-assigning classes, but they shouldn't have to, imo.

tf_is_horse_archer:  auto-assigns to a new category for horse archers (they really need their own class), and assigns aisb_horse_archer to their Simple Behavior if they are given a charge order.  They are already doing some of this, but the engine classifies them as "cavalry", which is totally inappropriate to their battlefield role, and makes developing smarter tactical AI more difficult / inefficient than it probably should be.

 

[Kinsume]

I'd like to have a quest editing/adding feature that allows me to make new quests and implement them into the game. A bit like TweakMB or the Modding tool that can edit the values, troops, items, ect.

 

[Yoshiboy]

This already exists in the Module System

 

[xenoargh]

I would like a special script, script_get_agents_in_sphere_and_do.  This would have to be a special script, as it would entail adding some new functionality to the engine.

Arguments: a position (still packed), a radius, in centimeters, and the script ID of the script to run if any Agents were found.
Output: a flag state indicating whether the script ever was run (i.e., have it set reg0 to 0 or 1).

This would allow for faster sphere searches and better subroutine design.  I suppose this could also be an Operation as well (i.e., we could set the state of reg0 in the script before calling, and the subroutine could then set the state if condition was true), but I figure that as a script, it would lend itself to a little more flexibility.

Sphere searches via the standard for_agents technique in this engine seem to be really slow, because they have to brute-force iterate through every Agent, and this issue comes up a lot when trying to solve certain problems. 

Using an engine-side well-optimized spherical volume search would be faster, probably by a huge multiple, and allow for all sorts of clever things.  Ideally, it'd also be nice to be able to do this for props and weapons, which would allow for other cool things.

 

[othr]

Instead of the 'game_get_speed_multiplier' script I'd like something such as... set_global_travel_speed_multiplier to set the global travel speed multiplier for terrain tiles.  As in set_global_travel_speed_multiplier (multiplier, terrain_type).

The current method through the script is very CPU intensive and slows the game down if there are many parties present.

 

[guspav]

I'd like the new ti_on_missile_hit to be able to store the second parameter which would be hit agent id, as currently it only stores the position of the missile and the shooter agent :
from header_triggers.py:
ti_on_missile_hit        = -52.0 #can only be used in module_items triggers
# Position Register 1: Missile Position
# Trigger Param 1: shooter agent id
So a  Trigger Param 2: hit agent id would be really cool
(I am trying to make a magic mini-mod of sorts and that would greatly simplify many things).

 

[ealabor]

I'd like quite simply for new releases of the module system to be listed with what exactly has been changed.

It's really starting to get frustrating with trying to stay current. Would be alot easier if we knew what module files have been changed.

And for the files which have been changed, perhaps within them there can be #'d out comments such as " # updated v 1.125 here", and someone would tell us what it is, so we could just search string to those sections of code which have been edited, and simply copy/paste the entries into our modded files.

 

[xenoargh]

I would like the engine to continue to send the Skin uniform when running "body armor" types.  This will allow "body armor" to use the faceshader correctly. 

I did an experiment, and found that while multimesh armors can be built that serve as the "body", and that these can be sent the appropriate uniform if used as the base skin, that they no longer function when they are set as body armor.

This change would allow for modders or even the game developers to build multimesh armors that show skin that are racially-agnostic, and should not have a giant impact on the performance of the engine.

In addition, it appears that the specular shader used for a lot of armor (specular_shader_noskin_bump_high) is being sent that uniform, if part of the base mesh.  This seems to be in line with issues I've seen with multimesh armors in general- it almost appears that only one shader is being applied, even if the multimesh contains different materials and references more than one shader.  I realize that this probably wasn't in the design specifications for multimesh, that multimesh for armors is new, etc., so I won't hold my breath on that, but I thought I'd let you folks know what testing results I've seen.

 

[xenoargh]

If new items are added to flora_kinds.txt, they are valid, and can be used in the Scene Editor, but are never picked by the map randomizer when building autogenerated scenes. 

If the number of items is larger than X, then the random number needs to be auto-adjusted to use the correct range (imo).  If that is a matter of changing the numeric section (which I presume is related to scale / rotation) then please let me know what tuple needs to be altered.

In addition, adding new ground Materials fails.  Referencing new ones works just fine, but I'd like to have more if that can be done (I assume that this is non-trivial, though, given the way you folks implemented splat-maps, so I'm not holding my breath).

 

[GetAssista]

If new items are added to flora_kinds.txt, they are valid, and can be used in the Scene Editor, but are never picked by the map randomizer when building autogenerated scenes.

They do get used in random generation, at least in 1.011.
Try copy flags from existing trees, and you'll get new trees generated in a scenes too. I do get them. Did you increased the number at the beginning of flora_kinds.txt?

 

[xenoargh]

No, I didn't increase that number, it caused a crash, something about EOF.

I don't want new trees, I want more grass/bush variety.

 

[GetAssista]

No, I didn't increase that number, it caused a crash, something about EOF.
I don't want new trees, I want more grass/bush variety.

number = number of plants in a flora_kinds.txt file. If you add new ones, you better tell the system that there are more plants now.

New bushes work fine, just copy the flags from existing bushes. Grass is hardcoded to "grass_.." material it seems, other grass does not appear in the game no matter flags.

 

[xenoargh]

Grass is hardcoded to "grass_.." material it seems, other grass does not appear in the game no matter flags.

Well... that sure explains what's wrong

I guess I have some re-uvmapping and stuff to do, then.  Thanks for the info!

 

[Manakel]

I believe tales world should name each list of triggers in the module system.
This way we would not need to edit each and single mission to insert new triggers.
We could simply make an include with a script that append our triggers to the named lists

like
mp_trigger_list.append [mycustomtrigger1,mycustomtrigger2]
battle_trigger_list.append[....]

Basically, only 1 maintenance point for all our triggers instead of copy pasting the same line in tenths of places!!!

 

[RT2]

(agent_set_speed_limit, <agent_id>, <speed_limit(kilometers/hour)>), #Affects AI only  <=== Whhyyy??? 

It would be great if agent_set_speed_limit function wasn't limited to AI agents only. It's impossible to have a good control on players speed parameter, even by modifying the athletic skill.    I'm actually trying to make players walk when a specific key is clicked, and that's really horrible because without direct access to players speed parameter, I'm obliged to use crazy methods who don't really work correctly anyway. For example, my actual solution is to spawn a little scene prop in front of the player model, and make it advance slower than the player in order to block him and limit his speed (yeah, I know, that's really weird...). 

 

[Oldschool]

I would like to expand the list of available groups for battlefield commands.  Currently we have grc_infantry, grc_archers, grc_cavalry, grc_heroes, and grc_everyone.  Since we can assign 9 groups now, would be nice to have access to them in scripting.

Edit:  Also, now that I think of it, being able to assign a unit to a specific group through scripting would be great as well.

 

[Tul]

agent_set_speed_factor - obviously
position_is_on_ai_mesh or at least agent_is_on_ai_mesh
position_is_intersecting_with_scene_prop

 

[xenoargh]

I would like an operation that will reset Facegen DNA back to whatever is specified in troops.txt, as opposed to the savegame.  It's really annoying that any changes I make to faces can't be seen by players until they start a new game.