Ravendark

So basicly create a new upgrade(type="OBJECT" if you want ti to apply to the shrine, type="PLAYER" if you want ti to apply to any object that has the <LevelUpUpgrade> ) name it something like Upgrade_secretshrineVet, create a new unitability button and logiccommand for that. Add the logic command to the commandset of the secret shrine. in the behavior section of the secret shrine(or the units you want to give the "PLAYER" upgrade to) add the following: <LevelUpUpgrade id="ModuleTag_LevelUpUpgrade" LevelCap="4" DoFlash="false" LevelsToGain="1"> <TriggeredBy>Upgrade_secretshrineVet</TriggeredBy> </LevelUpUpgrade>

I wonder if the reverse move was a planned feature or atleast a well worked out one. Because you can make units slide across the screen depending on when you click.

I didn't say attach models which you do in max....i said "link it to a existing bone in the original draw" which you just do in the xml. AttachToBoneInAnotherModule=""

The stealth effect is a separate model in a new draw. You either animate it or link it to a existing bone in the original draw. So either they neglected the animation or the 2 draws are not linked....it probably is one of those reason i reckon. Yeh that is a good point, you would also get weird contactpoint effects i imagine.

It has been kind of strange, the last month or more i've seen multiple channels that cover RTS or c&c related games go back and do RA/RA2 c&c95 content and the sorts. Like nostalgia kicking in like a flue season or such...everyone caught it at the same time. The reason for lower view counts might just be to that much coverage of a older genre at the same time.

Iirc both the juggernaught and spectre use the deployai and canfirewhilemoving=false....won't that combo prevent it from moving/turning while it prepares to attack? Now personaly i don't really like the deploy system in regards that it goes through its deploy animation everytime it targets a new unit, but that is a whole different issue.

Are you already familiar with adding/modifying commandsets/logiccommands, creating unit abilitybuttons and adding new behavior modules?

if you turn the whole chassis into a turret you might be able to mimic something of the sorts. You could try to make the ROOTTRANFORM the turretbone..altho i am not sure if that will work(well). Other then that would mean linking the body mesh/vertices to the TurretNameKey bone. And the barrel to the turretPitch bone. Because of the Deploystyle ai it should work only when deployed as in not moving.

The TW sdk has explanations for some of them. Read that. But do take into account those are just names thought up by the dev's you can name them differently if you create your own animations/models. It is just how the devs kept things recognisable. Some of the more common used: _SKN : the default/base model used for most models. _SKL: Skeleton, Bone data only, no mesh, no animation data, just pristine bone positions. Usually used as a recurring reference in animations. _IDL: Idle animations _BLD: buildup animations iirc. _D1.2.3: Damage model/animations iirc _TRNL: turn left _TRNR: turn right _HTRNL/R: highspeed turn left and right _WLKA/B: Walking A/B _FP: Formation preview (the grey'ish silhouette when you give a formation command) I don't really know if there is a list...there are alot of them, but as i said mostly its made up suffixes done by the devs into something they can relate to. You don't really need to follow they way of thinking if you understand what you models/animations suppose to do.

Those are basically the seams of your unwrap. Your borders. If they are white it more or less means they are stichted together, while green means it is not connected (within the uvw layout at least). I am not sure if i am explaining this right tbh. But basically your tread texture spans from the left border to the right border and scrolls seamlessly from left to right. If you make sure your uwv are inside the tread texture it should work as intended. If you need to reverse the direction you flip the unwrap 180degrees horizontally. I'm honestly finding it alot harder to explain then to do. If you do it a few times even with trial and error it explains itself automatically imo.

You are looking at the wrong thing in the predator files, but weirdly enough when i import the settings aswell from that file it doesnt import the correct settings. Best thing to do is just manually use the Defaultw3d.fx shader and use the following settings: Just make sure that texmap0 is set to 1 (scl/move) and uv0 scl/move set the color to R=1.0 G=1.0 and B(blue) the scroll direction to anything but 0.0...use something between 0.0 and 1.0 you also don't need to use a secondary texture iirc. That is for your moving treads. for your stationary treads set the blue color to 0.0 and it wont scroll. Those green lines in the picture of the tutorial are just your edges...

Iirc Sage2(RA3) uses a animated bone system right? Aside from that, i never tried it, you could do a animation/path constraint setup...you could still keep a one mesh tread layout, just increase it complexity a bit and i think the engine could still handle it? As long as you wwskin the correct vertices to the correct bones that follow the animation path i don't see an issue with the animation not working. The only issue would be..is it worth the trouble as most treads are obscured with parts of the chassis anyway and not importantly visible in game...

What result are you aiming for then? Because i don't understand the point of having a turret if it isn't allowed to rotate? That basically just makes it a hardpoint.

The w3d part is outdated in that tutorial i said that before. in TW and KW treads use a scrolling shader. where the texture scrolls in a certain direction in your uvw map. Have a look at this tutorial: http://cncguild.net/item-148 but basically like styggs said..open one of the sample max files from the TW sample art..i would recommend the predator or mammoth(the mammoth is a bit more convoluted in amount of sub objects and bones it uses) and see how they use the shader.

Try setting a AcceptableAimDelta in your weapon itself to go along with those settings....or change the turret angles to something like 1. I'm thinking it will need one of those settings to be able to target something. But honestly if you are not using the turret, remove all the turret coding and just use a <WeaponSlotHardpoint> instead together with a AcceptableAimDelta in your weapon.

From the top of my head: 1. duplicate the repairdrone spawn of the airtower, but make it spawn 1 dummy...now change the <GameDependency> <RequiredObject>GDIAirTower</RequiredObject> </GameDependency> in the call for transport SP to something like <GameDependency> <RequiredObject>GDIAirTower_Dummy</RequiredObject> </GameDependency> When ever the air tower gets underpowered/emp'ed the dummy drone dies....when the air tower comes back online it spawns a new drone..that dummy drone enables the SP dependancy.

1. For visible meshes you select export geometry, for invisible bones you select export transform...if you need both you select both for example a tankbarrel that also doubles as launch/fx bone. 2. What works in max doesn't necessarily work ingame..that is why you have the w3x modelviewer it more or less simulates how the engine will treat the model and animations. If it doesn't work properly in the viewer wit probably won't work ingame either. 3. You said it disappears earlier, but whatever. If it won't move it means your mesh isnt linked to your bones...which probably brings us back to your wwskin issue or your export settings for your mesh/subobjects, if you are animating your mesh directly you might have to export it as transform swell and not just geometry....if you are using a wwskin modifier you can export the mesh as geometry and your bones as transform.

EALA's studio was made for RA3, Bibber converted it for use with TW iirc, but not for KW....To compile mods in KW you need to use the buildmod.bat file that came with the KW sdk. Also do realise that KW has had some changes since vanilla TW. So looking at the TW xml's is a good place to start...along the line you are better off using the WE tool to browse the KW xmls and read them directly from the big. Due to changes where KW deviates from TW.

Make sure you are exporting your meshes as geometry and not just bones only. Test your model and animation in the w3xviewer as well. Make sure you didn't make any typos in your xml in regards to referencing your animation/models etc. Does your mesh disappear during the animation or at the end of it?

The things dev's try to get away with by calling it :"a design choice" or "artistic direction".

If you add a new kindof for identification purposes, that usually works fine enough....but if you need to use it for added effect (like the commando's C4 kindof that is needed for the special power and to display the c4 cursor icon) that depends on hardcoded engine functions and enless the sage engine knows what to do with it i won't work. Like Stygs mentioned in your case the radar thing seems hardcoded in the sage2 so enless it already existed before in sage1 it won't work.

Idd that works aswell. And in this case prob even better. Something like: <AnimationState ParseCondStateType="PARSE_DEFAULT"> <Script> CurDrawableShowSubObject("TV") </Script> </AnimationState> <AnimationState ParseCondStateType="UNDERPOWERED"> <Script> CurDrawableHideSubObject("TV") </Script> </AnimationState> you might have to add RetainSubObjects="true" to the modelconditionstates aswell or you will have to add the scriptig lines to every different modelcondition like really damaged etc. Something to try out, could be i am wrong and you need to add the scripting part to each conditionstate either way. Edit: made a mistake it should be ParseCondStateType="NORMAL" ConditionsYes="UNDERPOWERED"> and not ParseCondStateType="UNDERPOWERED"> as i stated above

Gonna post the TW code, converting it into KW is your work but the basics are the same: From the TW schematics: <xs:complexType name="QuantityModifier"> <xs:sequence></xs:sequence> <xs:attribute name="Name" type="GameObjectWeakRef" /> <xs:attribute name="Count" type="SageInt" /> </xs:complexType> <xs:complexType name="ProductionModifier"> <xs:sequence> <xs:element name="ModifierFilter" type="ObjectFilter" minOccurs="1" maxOccurs="1" /> </xs:sequence> <xs:attribute name="RequiredUpgrade" type="UpgradeTemplateRef" /> <xs:attribute name="CostMultiplier" type="SageReal" default="1.0" /> <xs:attribute name="TimeMultiplier" type="SageReal" default="1.0" /> <xs:attribute name="HeroPurchase" type="SageBool" default="false" /> <xs:attribute name="HeroRevive" type="SageBool" default="false" /> </xs:complexType> <xs:complexType name="ProductionUpdateModuleData"> <xs:complexContent> <xs:extension base="UpdateModuleData"> <xs:sequence> <xs:element name="QuantityModifier" type="QuantityModifier" minOccurs="0" maxOccurs="2" /> <xs:element name="ProductionModifier" type="ProductionModifier" minOccurs="0" maxOccurs="2" /> </xs:sequence> <xs:attribute name="MaxQueueEntries" type="SageUnsignedInt" default="99" /> <xs:attribute name="NumDoorAnimations" type="SageInt" default="0" /> <xs:attribute name="DoorOpeningTime" type="Time" default="0s" /> <xs:attribute name="DoorWaitOpenTime" type="Time" default="0s" /> <xs:attribute name="DoorCloseTime" type="Time" default="0s" /> <xs:attribute name="ConstructionCompleteDuration" type="SageUnsignedInt" default="0" /> <xs:attribute name="DisabledTypesToProcess" type="DisabledBitFlags" /> <xs:attribute name="GiveNoXP" type="SageBool" default="false" /> <xs:attribute name="UnitInvulnerableTime" type="SageUnsignedInt" default="0" /> <xs:attribute name="SpecialPrepModelconditionTime" type="SageUnsignedInt" default="0" /> <xs:attribute name="VeteranUnitsFromVeteranFactory" type="SageBool" default="false" /> <xs:attribute name="SetBonusModelConditionOnSpeedBonus" type="SageBool" default="false" /> <xs:attribute name="BonusForType" type="GameObjectWeakRef" /> <xs:attribute name="SpeedBonusAudioLoop" type="AudioEventInfoRef" /> <xs:attribute name="SecondaryQueue" type="SageBool" default="false" /> <xs:attribute name="Type" type="ProductionQueueType" default="INVALID" /> <xs:attribute name="IgnorePreReqs" type="SageBool" default="false" /> <xs:attribute name="ProductionTimeDelayScalar" type="Time" default="0s"/> </xs:extension> </xs:complexContent> </xs:complexType> i used the quantity modifier in my mod at it looks like this: <ProductionUpdate id="ModuleTag_06" GiveNoXP="true" Type="INFANTRY" VeteranUnitsFromVeteranFactory="false" NumDoorAnimations="1" DoorOpeningTime="0.66s" DoorWaitOpenTime="1.0s" DoorCloseTime="0.66s" > <QuantityModifier Name="OSR_Delta" Count="4" /> </ProductionUpdate> to use the productionmodifier it would look something like this if i'm correct: <ProductionUpdate id="ModuleTag_06" GiveNoXP="true" Type="INFANTRY" VeteranUnitsFromVeteranFactory="false" NumDoorAnimations="1" DoorOpeningTime="0.66s" DoorWaitOpenTime="1.0s" DoorCloseTime="0.66s" > <ProductionModifier CostMultiplier="2.0" TimeMultiplier="2.0"> <ModifierFilter Rule="NONE"> <IncludeThing>GDISniperSquad</IncludeThing> </ModifierFilter> </ProductionModifier> </ProductionUpdate> At the moment the schematics both for TW and KW are setup to only allow: 1 Objectfilter per productionmodifier max 2 productionmodifiers per productionupdate module. If you want more of those in the same productionmodifier you need to alter those schematics slightly, increase the max number or set the max to Unbound. Again i can't emphasize enough to take a few evenings to read through the schematics and put them side by side next to the xmls to understand what is possible. It is time well spend.

Did you add your scripts.lua and sciptevents.xml to your buildmods/mods/modname/data/scripts/ folder (tw) or to your /misc/data/scripts/ folder in KW?

Look at how the powerplant or other buildings do it. They use lua and the eventlist to hide subobjects. they use the OnPowerOutage and OnPowerRestored events to trigger the lua scripts for example: function OnNODSecretShrinePowerOutage(self) if ObjectHasUpgrade( self, "Upgrade_NODConfessorUpgrade" ) == 1 then ObjectHideSubObjectPermanently( self, "GLOWS", true ) end end function OnNODSecretShrinePowerRestored(self) if ObjectHasUpgrade( self, "Upgrade_NODConfessorUpgrade" ) == 1 then ObjectHideSubObjectPermanently( self, "GLOWS", false ) end end Have a look at some of the buildings how they do it.