129 replies to this topic

[Nertea]

Something that works, as it's used in the onCreate with no problems. But, if you're that curious...

-- function hides ALL peasant weapons
function HideAllPeasantWeapons(self)
	local objList1 = RetrievePeasantObjects("draftWeapons")
	local objList2 = RetrievePeasantObjects("normalWeapons")
	HideAllSubObjects(self,objList1)
	HideAllSubObjects(self,objList2)
end

-- PEASANT FUNCTIONS
-- aka. chris' "fun with lua" day

function RetrievePeasantObjects(category)
	-- Initialize table and keys because BFME's lua is a mess
	local objects = {}
	local a = "wearables"
	local b = "headParts"
	local c = "helmets"
	local d = "draftWeapons"
	local e = "normalWeapons"
	local f = "tools"
	local g = "draftedHeadParts"
	
	-- Assign values to each key
	objects[a] = {"CLOAK1","CLOAK2","CAP1","CAP2","HOOD"}
	objects[b] = {"BARE_HAIR","BARE_NBEARD","HELM_NBEARD","HELM_HAIR"}
	objects[c] = {"DHELM1","DHELM2","DHELM3","DHELM4","DHELM5"}
	objects[d] = {"SPEAR","NICESWORD","AXE1","AXE2"}
	objects[e] = {"PITCHFORK","SCYTHE","STAFF","ROUGHSWORD","CLEAVER","SICKLE","ROUGHAXE1","ROUGHAXE2"}
	objects[f] = {"HAMMER1","HAMMER2","LARGEHAMMER"}
	objects[g] = {"DBARE_HAIR","DBARE_NBEARD","DHELM_NBEARD","DHELM_HAIR"}
	
	
	-- Return wanted values
	return objects[category]
end

-- This function hides a set of subobjects
-- --------------------------------------------------
-- # Inputs: self: an instance of the object
-- #		 subObjectTable: a table containing strings naming all the subobjects to be hidden
function HideAllSubObjects(self,subObjectTable)
	-- for all objects in the subObjectTable
	
	local length = getn(subObjectTable)
	for i=1,length do
		-- hide the subobject.
		ObjectHideSubObjectPermanently( self, subObjectTable[i], true )
	end
	
end

I've found another way to do what I want (I think), so this isn't relevant anymore. However, I would still like to know what's going wrong...

[Gfire]

So, OnRohanPeasant2Drafted is not being called at all?

[Nertea]

Exactly.

[Gfire]

Hm... don't see any problems. Sorry, I'm don't have a whole lot of experience with the scripting.

[Radspakr Wolfbane]

There's an easier way to do all that

[Nertea]

If you tell me what that way is, I can tell you why it won't work.

My objective is to randomize subobjects on creation, hide those and randomize a different set of objects on an upgrade, hide those and randomize tools on a state entry, then CONDITIONALLY return to the previous set of randomized objects on state exit.

Edited by Nertea, 04 December 2009 - 06:08 AM.

[Radspakr Wolfbane]

And why are you doing all that?
Seems somewhat pointless.

[Nertea]

Because I like complex things? I don't want my pesaants with pitchforks or swords (drafted) hitting buildings with them to repair them, and I don't want my pesants with hammers hitting orcs with them. It just looks stupid.

[Radspakr Wolfbane]

In the normal game they don't.
You could hide all the random weapons when draft is used and use a standard sword (or different sword for each model).
A lot easier and you won't have to use needlessly complicated scripting to make it happen.

Edited by Radspakr, 06 December 2009 - 09:46 AM.

[Nertea]

In the normal game, they do look stupid. The bit where peasant 4 attacks orcs with a wood saw is just great, isn't it! So yeah... your solution is not ideal. See, I try not to cut any corners with my work - and thus I don't see spending a few days puzzling out how to get one unit working correctly as needless. I'd hope that some people (from your responses, not you) will appreciate that my peasants will actually look like a disorganized bundle of conscripts, with a large variety of randomized weapons, clothes, helmets and the like.

Regardless, nobody seems to know why that state isn't triggering. Too bad. Luckily, my workaround does work, though it's far more work than some simple function writing .

Edited by Nertea, 05 December 2009 - 06:11 AM.

[mike_]

Go Nert!

And I am one of those people

[Nertea]

I have a new question that I rather doubt anyone has any experience with (maybe Rad? GtO?). It concerns bases, walkable walls and passability.

We're running into a serious gamebreaking bug in TDH, which I really can't release the mod with - it concerns the Dwarf Castle.

Here's a summary of the bug:
1) The player builds a building (almost any) at a build plot in the castle, and closes the gate.
2) The AI immediately attacks the castle. Melee hordes mill around the map as normal, but archers find their way to the wall segment directly beside the building and stand beside it.
3) The bug manifests itself in one of two ways:
-The archers shoot through the wall (I haven't seen this in a while, so chances are this got fixed)
-The archers eventually jump up onto the wall

Here are a pair of images from one of my testers of what's going on:



The castle works almost PERFECTLY aside from this. There doesn't appear to be any geometry issues visible to pathing (if you close the gate, and order your units in/out, they will be unable to path anywhere - you get the invalid cursor and they don't move). The only time the bug occurs is if archers who can see a building inside the base are given an attack order to attack this building (again, this doesn't work with melee units).

So far, I have eliminated these causes:
1) Objects not added to AI lists (invalid because human players can do it too)
2) The walls are too close to the plot buildings (invalid - just checked the Gondor base distance and it's equal. Plus, Erebor walls are thicker.)
3) Wall geometry is incorrect (checked repeatedly - besides, wallkables use planes to define geometry)
4) Geometry of buildings inside the base is causing them to be targetable (building geometry is shorter than Gondor basics)

What I have left:
1) The fact that the walls have ramps instead of elevators is screwing up the pathfinding (this is likely not it, because MT has ramps. Of course, MT is heavily scripted, so...)
2) Some hardcoded behaviour/issue in the ini
3) Something missing in the model that doesn't get imported or show up in Wdump.

So yeah... pretty stumped, and have spent practically the whole week trying to get this working. ANY ideas at all will be welcome, as this is like... the one thing preventing TDH from getting released now.
I'll not post the code initially, as there are a lot of objects - if anybody thinks they can help, I'll post what they want

[Námo]

...
What I have left:
1) The fact that the walls have ramps instead of elevators is screwing up the pathfinding (this is likely not it, because MT has ramps. Of course, MT is heavily scripted, so...)
...

The German 'Elvenstar Mod' (English version 5.04) also have ramps instead of elevators for their Elven Castle. I think Sûl has worked with that mod, so he might know if they had any like problems with those ramps?!

... anyway, good luck with the debugging!

[Radspakr Wolfbane]

I have ramps in my mod as well (Rhun and DG I think).
Have a look at the Isengard walls which I think are the ones I based mine off of.
Another trick is to use the elevator bones as a ramp basically have the bones go up the incline and have it function as a normal elevator only changing the climbing anim code for walking.

[Nertea]

Yeah, I recoded them as elevators yesterday to test that and it didn't change anything.

I discovered an AABTree chunk in the w3ds using WDump for all wall sections that I suspect is the problem - Google tells me that AABTree is a pathing method. I don't know how to add this to my wall sections, nothing in the documentation or exporter about this (evidently different from AABox)

So Rad, you're using 100% new models for your walls? If so, I'd like to take a look at th w3ds/code if you wouldn't mind.

[m@tt]

Try PMing Deezire, from what I know he helped work on General's so he might know a bit about it.

[DeeZire]

Sorry cant help with your geometry thing, I'm a coder.

As for the random peasant thing, the LUA engine is a bit twitchy and undocumented, only certain things are wired to be triggered by a ModelConditionEvent and USER_ defined conditions don't trigger IIRC. You see the LUA engine is easily confused as it can distinguish between a ModelCondition (event) and an ObjectStatus (event) but an object can have both flags set identically at the same time and this screws LUA (e.g ATTACKING can be both a ModelCondition and an ObjectStatus at the same time, this conufes the LUA engine). You could try applying the model condition ARMORSET_PLAYER_UPGRADE or WEAPONSET_PLAYER_UPGRADE to the peasants and seeing if that triggers your LUA ModelConditionEvent instead. If not, try using an ObjectStatusEvent with the same trigger.

Edited by DeeZire, 22 December 2009 - 09:41 PM.

[morgoth946]

hmmm... I think I have an idea. Try to add a new walkable plane under the one you already have on the wall. It has to be more wide, anyway. The only problem that perhaps you're going to have is btt rams or siege towers. Nevertheless first it has to work, and I have serious doubts it will.

BTW Can human players do that too?

[Nertea]

Sorry cant help with your geometry thing, I'm a coder.

As for the random peasant thing, the LUA engine is a bit twitchy and undocumented, only certain things are wired to be triggered by a ModelConditionEvent and USER_ defined conditions don't trigger IIRC. You see the LUA engine is easily confused as it can distinguish between a ModelCondition (event) and an ObjectStatus (event) but an object can have both flags set identically at the same time and this screws LUA (e.g ATTACKING can be both a ModelCondition and an ObjectStatus at the same time, this conufes the LUA engine). You could try applying the model condition ARMORSET_PLAYER_UPGRADE or WEAPONSET_PLAYER_UPGRADE to the peasants and seeing if that triggers your LUA ModelConditionEvent instead. If not, try using an ObjectStatusEvent with the same trigger.

I have USER conditions triggering just fine for other units though, so it's kinda weird.

Could you explain the use of ObjectStatus events? There are none in the vanilla events list, though there is a note that they exist.

[DeeZire]

Use them the same as ModelCondition events, thus;-

<ObjectStatusEvent Name="OnFire">
	  <Conditions>+AFLAME</Conditions>
	</ObjectStatusEvent>

	<EventList Name="RohirrimFunctions" Inherit="CavalryFunctions">
	  <EventHandler EventName="OnCreated" ScriptFunctionName="OnRohirrimCreated" DebugSingleStep="false"/>
	  <EventHandler EventName="OnFire" ScriptFunctionName="OnRohirrimBurning" DebugSingleStep="false"/>
	</EventList>

The difference is that the event will be triggered on the appropriate ObjectStatus independently of any ModelCondition, in other words regardless of the ModelCondition that an object may have, the event will trigger when it's ObjectStatus is met as specified by the function.

As an example, an object may have the ModelCondition FIRING_OR_PREATTACK_A however at that same time it's ObjectStatus may be set to one (or more) of the following (this is the complete list of ObjectStatus types and you'll notice as I said that some are also valid ModelCondition types);-

DESTROYED
CAN_ATTACK
UNDER_CONSTRUCTION
UNSELECTABLE
NO_COLLISIONS
NO_ATTACK
AIRBORNE_TARGET
PARACHUTING
REPULSOR
HIJACKED
AFLAME
BURNED
WET
CANNOT_BE_SOLD
IS_FIRING_WEAPON
IS_BRAKING
STEALTHED
HIDDEN
DETECTED
CAN_STEALTH
SOLD
UNDERGOING_REPAIR
RECONSTRUCTING
IS_ATTACKING
NO_AUTO_ACQUIRE
USING_ABILITY
IS_AIMING_WEAPON
NO_ATTACK_FROM_AI
IGNORING_STEALTH
IS_MELEE_ATTACKING
GUARD_SELECTION
LEASHED_RETURNING
DEATH_1
DEATH_2
DEATH_3
DEATH_4
DEATH_5
CONTESTED
CONTESTING_BUILDING
HORDE_MEMBER
RIDERLESS
RIDER_IS_PILOT
RIDER1
RIDER2
RIDER3
RIDER4
RIDER5
RIDER6
RIDER7
RIDER8
IMMOBILE
FLEE_OFF_MAP
NOT_IN_WORLD
INAUDIBLE
CHANTING
ENRAGED
CREATE_DRAWABLE_WITH_LOW_DETAIL
SINKING
RAMPAGING
INSIDE_GARRISON
DEPLOYED
UNATTACKABLE
ENCLOSED
TEMPORARILY_DEFECTED
TAGGED
DEPLOYING
BLOODTHIRSTY
PORTER_TAGGED
GRAB_AND_DROP
STAND_GROUND
UNCONTROLLABLY_SCARED
SPECIAL_ABILITY_PACKING_UNPACKING_OR_USING
PLEASE_EAT_ME
UPDATING_AI
HUNT_WHEN_IDLE
IGNORE_AI_COMMAND
RUNNING_DOWN_FROM_BEHIND
DO_NOT_SCORE
CAN_NOT_WALK_ON
MARCH_OF_DEATH
DO_NOT_PICK_ME
INHERITED_FROM_ALLY_TEAM
SWITCHED_WEAPONS
END_FIRE_STATE
BOOKENDING
ELVISH_EXPRESSLY
INSIDE_CASTLE
BUILD_BEING_CANCELED
PENDING_CONSTRUCTION
PHANTOM_STRUCTURE
IN_FORMATION_TEMPLATE
IS_LEAVING_FACTORY
MOVING_TO_DISMOUNT
NO_HERO_PROPERTIES
CAN_ENTER_ANYTHING
HOLDING_THE_RING
INVISIBLE_DETECTED_BY_FRIEND
INVISIBLE_DETECTED
WORKER_REPAIRING
ATTACHED
WONT_RIDE_WITH_YOU
COMMAND_BUTTON_TOGGLED
IGNORE_PARALYZE_NUGGET
SUMMONING_REPLACEMENT
HOLDING_THE_SHARD
USER_DEFINED_1
USER_DEFINED_2
FRONT_DESTROYED
RIGHT_DESTROYED
BACK_DESTROYED
LEFT_DESTROYED

Edited by DeeZire, 24 December 2009 - 06:54 PM.