129 replies to this topic

[Ringwraith Captain]

Try making an invisible mesh that extends above the wall mesh. Of course, if you make it too high, you could wind up with the appearance of projectiles colliding with thin air.
Or try altering the wall's geometry codes.

[Nertea]

So, despite the other two problems not being fixed, I've put them on the backburner for now. New problem:

Flying units - specifically those based on the Eagle skeleton, seem to appear from the sky when they're built. While this works as a summon, it's not good for places that train birds. Anyone know how to change this so that they'll launch from a buildin't defined exit point? It doesn't look like the locomotor has anything relevant, nor anything that I can find in the ini... but it seems like such a simple change that I'm probably just missing a little thing.

[Ringwraith Captain]

I've never made any flying units myself, but this is how the fellbeast heroes act when purchased. So it's not just the eagles.
One possible solution: make an "egg" object, and purchase it from the building. GIve it a lifetimeupdate so it dies immediately after being purchased, and have it trigger an ocl upon death. Have that ocl spawn your unit. You add an offset to the ocl, so just set the xyz coordinates to the building's exit point. Set z to 0, for example, to have them lift off from the ground.

[GothmogtheOrc]

The above is a good idea, that might also allow you to force the spawn location to not be ABOVE_TARGET_LOCATION which I suspect is what EA hard coded any of the flying objects to use upon spawn. My guess from briefly looking at the nazgul locomotor and unit code is that their spawn is controlled by the GiantBirdAI or whatever it's called. I know that the swoop ability is only usable when the object uses GiantBirdAI so likely their spawn location is hard coded there too.

-Gto

[Nertea]

Seems logical, I'll give it a shot

edit- worked nicely, thanks! now i have to solve the rest of the bugs with the unit

Edited by Nertea, 03 July 2009 - 06:49 PM.

[Nertea]

This may be a really simple question to answer, but is there any way to put global dependencies in? For example, I only want a certain unit to be available while a certain building is present on the map, or another unit's trainability to depend on another unit's presence. However, I don't want to do this with a global upgrade that is granted/removed when the unit is built (has issues for the way I want things to work)

[GothmogtheOrc]

I'm not sure how you'd do that. If you can't use upgrades (and don't want to script every map) then the only thing I can think of is somehow using the lua for that? But I'm not familar enough with it to offer any suggestions. Maybe Lauri or DlotS would know?

-Gto

[m@tt]

This is from RA's Haldir code:

Prerequisites;this is to prevent the player from building Haldir without picking the Lorien mini faction
		Object = LorienCamp
	End

But it isn't used for any of the Ithilien stuff, so I don't know whether or not it works.

[Nertea]

That works, but it interestingly enough actually removes the object from the commandset until the prerequisite is met. That's really not ideal, so I may just rework these systems to work with upgrades.

[m@tt]

Hmmm... ask Ched about it. He'll know more about it.

[Radspakr Wolfbane]

Does the Command Button happen to have HIDE_WHILE_DISBALED ?

This is how I would do it
First you have the building to set an upgrade once it is built then you have the unit need that upgrade to build in the Command Button

Options = NEED_UPGRADE
	NeededUpgrade		= Upgrade_Whatever

Edited by Radspakr, 11 July 2009 - 04:51 AM.

[Nertea]

That's the way I *didn't* want to do it Rad, but I guess it works ok.

Ok, a new and more complex question. I have a unit which I'm trying to make use a series of "orders" that you purchase at a unique (only one constructable) building. Essentially you'd be able to purchase an upgrade from that building that would affect all of the units on the map - easy enough with a player type upgrade. However, here's the catch - the upgrades should be exclusive and replaceable. At the structure, I want to be able to purchase Orders Type 1, then be able to, from there, purchase Orders Type 2... which would make purchasing orders Type 1 possible again. So basically, there's

Upgrade 1 OR Upgrade 2 OR Upgrade 3, with only one active at a time.

After screwing with wall upgrades for a long time, I'm pretty sure I know how to grant and remove upgrades using an ObjectCreationUpgrade. This seems to work... I can kill my speed upgrade with some code like this (on purchasing a sight range upgrade):

Behavior = ObjectCreationUpgrade TheSightUpgrade
		TriggeredBy		= Upgrade_RavenSight
		Delay			= RAVEN_PURCHASE_DELAY
		RemoveUpgrade	= Upgrade_RavenSpeed Upgrade_RavenStealth
End

I haven't extensively tested this mind you, because there's a larger problem - though this seems to remove the PLAYER upgrade from play, it doesn't refresh the commandset, so the RavenSpeed upgrade can't be repurchased. So, am I missing something? I have a hunch that I may need to find a different way to code this, but the only other way I can think of of doing this (objcet upgrade unpausing a speed, sight or stealth leadership upgrade) is messy.

[m@tt]

Would it be possible to create 4 different formations for the ravens? One normal, then one for each of the 3 upgrades. Each has their own stats.

You then have the 'upgrade' trigger the formation toggle using CommandTrigger = Command_RavenToggleStealth.

Where Command_RavenToggleStealth is a hidden command, so it appears in the raven commandset file, but not in the palentir.

And the upgrade is not actually an upgrade, just a fake button.

No idea if the toggle would work though on a global basis.

[GothmogtheOrc]

Could you add a CommandSetUpdate behavior that when your upgrade is triggered, updates the commandset?

So you'd end up with something like:

Behavior = ObjectCreationUpgrade TheSightUpgrade
		TriggeredBy		= Upgrade_RavenSight
		Delay			= RAVEN_PURCHASE_DELAY
		RemoveUpgrade	= Upgrade_RavenSpeed Upgrade_RavenStealth
End

Behavior = CommandSetUpgrade ModuleTag_something
	 TriggeredBy = Upgrade_RavenSight
	 CommandSet = RavenSightCommandSet
End

Wouldn't that 'refresh' the commandset so that you could then purchase the other options?

Edit: then you'd just copy that twice for the other two states. So you'd end up with 6 behaviors and 3 commandsets implementing the toggle.

-Gto

Edited by GothmogtheOrc, 13 July 2009 - 06:41 PM.

[Nertea]

Ok, that's pretty close to my current implementation, which has a new problem. Now, when you trigger the first command, everything is fine. However, when you buy a new upgrade, instead of purchasing that new upgrade, it just removes all the upgrades. At that point you can buy them all again.

Behavior = CommandSetUpgrade ModuleTag_RemoveAllSight
		TriggeredBy		= Upgrade_DwarfRavenSight		; Triggered by the sight upgrade
		RemovesUpgrades = Upgrade_DwarfRavenStealth Upgrade_DwarfRavenSpeed; disables the speed and stealth upgrades
		CommandSet = DwarfRookeryCommandSetSightOn								; change to the speed is on commandset
	End
	
	Behavior = AttributeModifierAuraUpdate ModuleTag_UpgradeSight
		TriggeredBy		= Upgrade_DwarfRavenSight
		ConflictsWith	= Upgrade_DwarfRavenSpeed Upgrade_DwarfRavenStealth
		StartsActive	= No
		BonusName		= RavenSightBonus
		RefreshDelay	= 1000
		Range		= 100000
		ObjectFilter	= NONE +DwarfRaven
	End

-edit: Ok, solved this I think in a rather awkward way. Now when you purchase an upgrade, I do this:

Behavior = ObjectCreationUpgrade StealthUpgrade02
		TriggeredBy		= Upgrade_DwarfRavenStealth
		Delay			= 0.1

		GrantUpgrade	= Upgrade_DwarfRavenStealth
		DestroyWhenSold = Yes
End

Which forces the thing to reuupgrade 0.1 seconds after you purchase an upgrade. So far it works, I'll let people know if there are any issues.

A pair of other questions have popped up though:
1) MaxSimultaneous of type doesn't seem to work on plot buildings. Anyone have any ideas for this? (Beyond a commandset upgrade when the building is built, because with all my upgrade hacks I fear the upgrade limit doth approach. Not to mention that I'm not sure how to remove such an upgrade when the building dies or is sold)
2) I'm 90% sure I'm going to hit the limit anyways; what kind of upgrades can be removed from the stock code to free up some slots?

Edited by Nertea, 13 July 2009 - 07:37 PM.

[GothmogtheOrc]

Well there should be a simple solution to both upgrade limit problems. First, you can use these:

CODE

;---------GOOD LVL 1--------;
Upgrade Upgrade_GoodHeroLV1Ability
Type = OBJECT
End

;---------GOOD LVL 2--------;
Upgrade Upgrade_GoodHeroLV2Ability
Type = OBJECT
End

;---------GOOD LVL 3--------;
Upgrade Upgrade_GoodHeroLV3Ability
Type = OBJECT
End

;---------GOOD LVL 4--------;
Upgrade Upgrade_GoodHeroLV4Ability
Type = OBJECT
End

;---------GOOD LVL 5--------;
Upgrade Upgrade_GoodHeroLV5Ability
Type = OBJECT
End

;---------GOOD LVL 6--------;
Upgrade Upgrade_GoodHeroLV6Ability
Type = OBJECT
End

;---------GOOD LVL 7--------;
Upgrade Upgrade_GoodHeroLV7Ability
Type = OBJECT
End

;---------GOOD LVL 8--------;
Upgrade Upgrade_GoodHeroLV8Ability
Type = OBJECT
End

;---------GOOD LVL 9--------;
Upgrade Upgrade_GoodHeroLV9Ability
Type = OBJECT
End

;---------GOOD LVL 10--------;
Upgrade Upgrade_GoodHeroLV10Ability
Type = OBJECT
End

;---------EVIL LVL 1--------;
Upgrade Upgrade_EvilHeroLV1Ability
Type = OBJECT
End

;---------EVIL LVL 2--------;
Upgrade Upgrade_EvilHeroLV2Ability
Type = OBJECT
End

;---------EVIL LVL 3--------;
Upgrade Upgrade_EvilHeroLV3Ability
Type = OBJECT
End

;---------EVIL LVL 4--------;
Upgrade Upgrade_EvilHeroLV4Ability
Type = OBJECT
End

;---------EVIL LVL 5--------;
Upgrade Upgrade_EvilHeroLV5Ability
Type = OBJECT
End

;---------EVIL LVL 6--------;
Upgrade Upgrade_EvilHeroLV6Ability
Type = OBJECT
End

;---------EVIL LVL 7--------;
Upgrade Upgrade_EvilHeroLV7Ability
Type = OBJECT
End

;---------EVIL LVL 8--------;
Upgrade Upgrade_EvilHeroLV8Ability
Type = OBJECT
End

;---------EVIL LVL 9--------;
Upgrade Upgrade_EvilHeroLV9Ability
Type = OBJECT
End

;---------EVIL LVL 10--------;
Upgrade Upgrade_EvilHeroLV10Ability
Type = OBJECT
End

[Nertea]

Ok, so if I understand you right, you'd have those generic upgrades and then you'd be able to get rid of things like Upgrade_LegolasKnifeFighter... and there's like 50 such upgrades. That should be plenty.

No idea on limiting the number of buildings of a type to one?

[GothmogtheOrc]

You got it. And no, I don't have any ideas on how to limit the number of buildings. But if I think of anything, I'll let you know

-Gto

[Nertea]

Alright, my massively convoluted method does not work... no matter what I do I can't seem to remove a PLAYER type upgrade. Here's what I'm doing now:

1) Granting a PLAYER upgrade (Upgrade_DwarfRookeryExists) when the building is constructed
2) The plot foundation has a commandset upgrade behaviour that swaps the commandset for one with a dummy button for the building that cannot be built, and removes Upgrade_DwarfRookeryDoesNotExist
3) On destruction of the building, it spawns an object that grants another PLAYER upgrade (Upgrade_DwarfRookeryDoesNotExist), then dies quickly
4) The plot foundation has a second commandset upgrade that swaps the commandset back to the original and theoretically removes the Upgrade_DwarfRookeryExists

That should work in theory; but it only works once. The upgrades don't get removed, and therefore if the building gets killed once you can rebuild an infinite amount of them. Not ideal. I can't find any occasion in the vanilla inis where a PLAYER upgrade is removed either, so this method is probably a no-go.

Thoughts?

[m@tt]

Could it be done through AI? I know that's a further release (if at all), but scripts could be used to say:

IF
Local Player has instances of DwarfRookery equal to 1
THEN
Local Player cannot build DwarfRookery

Have the script re-evaluate constantly.

So not a solution that could be used for a while. No guarantees it would work either, I don't know how much AI is used when the team is user-controlled.