Jump to content


  • Content count

  • Joined

  • Last visited

Everything posted by Ravendark

  1. 1. treads basicly use 4 meshes with a scolling texture shader. turn left(you flip the UV so it scrolls i nthe right direction), turn right(same but in reverse) stop(no scrolling texture) and move (both uv aligned in the same direction) there are some tutorials linked before on these forums, should be somewhere in topics related to basic modeling in 3dmax. 2. if the barrel isnt moving it means the mesh of the barrel hasnt got its vertexs linked to that bone. so the bone is recoiling as intended, it isnt effected the correct barre mesh.
  2. IIRC, you need to change: <WeaponTemplate id="ZoneTrooperFireJumpJets" Name="ZoneTrooperFireJumpJets" IdleAfterFiringDelaySeconds="0s" AttackRange="999999.0" MinimumAttackRange="20" WeaponSpeed="160" /* this controls the flightspeed */ ProjectileSelf="true" ClipSize="=$UNLIMITED_CLIP_SIZE" AutoReloadsClip="AUTO" PreAttackType="PER_SHOT" HitPercentage="0%" > <PreAttackDelay MinSeconds="0.1s" MaxSeconds="0.1s" /> <FiringDuration MinSeconds="0.1s" MaxSeconds="0.1s" /> <ClipReloadTime MinSeconds="0.1s" MaxSeconds="0.1s" /> <Nuggets> <ProjectileNugget WarheadTemplate="ZoneTrooperJumpJetWarhead" /> </Nuggets> </WeaponTemplate> As for the flight characteristics it will always be some sort of bezier curve if done with a self projectile style like it uses, but try something like: <BezierProjectile id="ModuleTag_Projectile" FirstHeightMin="50" FirstHeightMax="50" SecondHeightMin="50" SecondHeightMax="50" FirstPercentIndent="30" /* change these values */ SecondPercentIndent="70" /* change these values */ TumbleRandomly="true" CrushStyle="true" BounceCount="0" FinalStuckTime="1.766s" GroundHitFX="FX_ZoneTrooperJumpJetHitsGround" PreLandingStateTime="0.3s" /> i would try setting these values to something low, i had a vertical launched (silo based ) missile ones that flew more or less like your drawing. I had those set to 1. you will need to experiment with those bezier settings.
  3. try this: add this to your weapon.xml <ProjectileNugget WarheadTemplate="MybombWarhead" ProjectileTemplate="MybombProjectile"> <AttackOffset x="0" y="0" z="-100"/> *the -z value should prob be something along the hover/flight height of your airship </ProjectileNugget> make sure your projectil bezier attributes make it fly in a strait line, so no curves or arcs....more or less set everything to 0 or 1 related to height curving etc.
  4. For sound there is a tutorial for that in the TW SDK documentation. for the visual weapon effects look into the fxlist(gdi/nod/alien).xml and fxlist.xml and fxparticlesystem.xml files and work form the existing examples. Exmaples for projectiles can be found with the respective factions prop folders and in the xml files found in there.
  5. I've seen that bug before, this usually happens when you force fire iirc? Anyway try adding RotatingTurret="true" to the weapon code and maybe ControlledWeaponSlots="PRIMARY_WEAPON" or such to the turretai module in the gameobject. But iirc, this is considered a game bug so not sure how much this is solvable.
  6. Just give it a scatterradius=1 or such attribute in the weapon, that should make it not homing.
  7. Might as well pin a topic like this, seeing it is a recurring question about the one of the basics of modding.
  8. So Runway2Parking1 and Runway2Parking2 don't work, one would assume those are a left over from generals? So you would have: Runway0Parking0 Runway0Parking1 Runway0Parking2 Runway1Parking0 Runway1Parking1 Runway1Parking2 Runway2Parking0 Runway2Parking1 Runway2Parking2 All the shit they left in the schematics, you would assume they would't bother removing/renaming those hardcoded bones?
  9. Have a look at the GDI firehawk how its used. As for OBJECT <> PLAYER i don't think there is a difference on how its used. What maybe differ is the following: If the Trigger Upgrade is local (OBJECT) it will only remove the upgrade on the unit/object it is triggered on. If the trigger upgrade is global(PLAYER) it will remove the upgrade from each object that has the module in its behavior section. The following i haven't tested yet myself so this is a assumption based on logic: Object A,B and C have a PLAYER Upgrade >>> then you trigger the remove upgrade with a OBJECT upgrade From Unit A, but not from B or C, the following effect should happen: Unit A looses the Player upgrade but unit B and C don't due to it being locally trigger (OBJECT upgrade) on unit A. If you want unit B and C to loose their upgrade aswell from the localy triggered upgrade in unit A (OBJECT upgrade) you can try to add RemoveFromAllPlayerObjects="true" to the module. Or ofc use a global (PLAYER) upgrade that effect all 3 units. the RemoveFromAllPlayerObjects Needs testing, i havent used that yet myself so far.
  10. Ravendark

    Forged Battalion

    GG was story driven? What a load of bullshit. 5 fucking missions per faction that didn't last long enough to get you involved for a total of 15 missions and a stupid short ass dlc months later? And what did most of those missions involve? Kill everything objectives? Boring crap of a game that didn't warrant a second play through. fuck i even played through Tiberium Twilight out of curiosity to see both GDI and NOD choices and that is saying a lot about my ability to tolerate shit story telling. Holy shit, I've seen porn with a more gripping story and that made me want to cum back to it. They probably also did more on a 50 dollar budget then you did with a million dollar + budget. And where did they put all that money they saved on story telling and cinematic in forged battalion? Not in the model and texture artists budget obviously. engine? doubt it very much. Map design and scripting? Highly unlikely as well. Also, really stop that self praise bullshit by quoting niche outlets and reviewers That dinosaur of a e-magazine that tries to stay relevant or that let's player/streamer getting free games/channel content, obviously they love to stroke your cock ego to keep their shit going. The average consumer that needs to pay and is only there for the content of your product thinks its a pile of shit. Fucking Petroglyph, you're the EA of developers.
  11. Basically if you want to compile a ini file with your custom mod you need to place the ini file at the following location: /whereYouInstalledYourModSDKFolder/ModSDK/BuiltMods/YourModName/Data/INI/ and not in your /documents/Tibwars/mods/ directory as your screenshot indicates. But make sure you installed the sdk + patch1.09 etc correctly.
  12. Ravendark

    Forged Battalion

    Wow Petroglyph must be the Logan Paul of game companies. Because they keep getting away with shit that would get others shut down. Like stealing..uh i mean being inspired by other peoples models/concept art. The apc looking vehicle at 5:32 seen that floating on the web for years, not sure if its part of the early c&c4 concept art. The Avatar(James Cameron not c&c3) mechs- wel ok i'll let mech thing slide, anyone who ever tried modeling a mech knows it comes out looking like something that prob exists all ready or something from the Mechwarrior universe, its the curse of mech design....the other models tho like the scout vehicles and tanks, it feels like they just browsed deviant art for those ones. Look its a upgrade tree...filled with mostly shitty % upgrades. Nothing against "retro" rts but how about not using the most shitty "retro" concept almost everybody disliked in the history of gaming : Empty % upgrade systems. So much diversity in unit design tho...all those weapons..that sound, look and feel alike for the most part. all those different units moving like a fucking blob and thrown against a opposing blob of units. I really like how most rts dev these days understand that "s" in RT-S stands for Shitloads and not strategy. More isn't always better. Even the title sounds like they stole it from 2 different games and glued them together to prey on nostalgia or "retro" memories. I so wanted to give this game the benefit of the doubt. I really liked the warzone, eart21xx games. But this game seems to fall short of the quality and thought that whent into previous titles. Not all the 21xx games were jewels, but they tried alot harder then this polished(well spitshined, i doubt they will try to polish it alot more) turd from Petroglyph..again.
  13. try startspaused but use the unpausespecialpowerupgrade module to trigger it. Additionaly add ObeyRechageOnTrigger= true to the unpausepsecialpower. Try that.
  14. Ravendark

    MOD.str not working

    For c&c 3 TW, you put a file called Mod.str in your modsdk/mods/yourmodsname/data/ folder, altho iirc you can put it aswell in the buildmods/mods/yourmodsname/data/ folder aswell iirc for c&c 3 KW you need to put it more or less where Egozi44 said : \source\Your mod name\Misc\DATA and you should call it mod.str aswell iirc
  15. Feels like its something like Halo wars 2 Blitz. Which i didn't find that enjoyable, specially not for long as it got repetitive fast. Also whenever i here developers say: "Let's make things simpler" it usually means dumber and/or shallower. Like alot of these type of games it probably will do well with streamers as the focus isn't as much on the actual gameplay but more on the streamcommunity/chat experience. While if you would play the game for the game itself you would loose interest fast.
  16. Very true, they can be a bit spammy depending on conditions. But in your case you are applying a very strong filter. Dmg state + none-spammy unit + range (perhaps), so there might be the occasional multiple harvesters getting targeted at the same time by your ironcurtain, but that would mean multiple harvester drop down in health to the dmg condition at the exact same moment (most likely if multiple harvesters get hit by a aoe of magnitude like a nuke or so). But like i said, that's from the top of my mind, without having worked on something similar. Probably better solutions out there.
  17. From the top of my head: Have the ironcurtain use a fireweaponupdate with a fireonobject nugget, target = PLAYER harvesters. with a ForbiddenTargetModelCondition="PRISTINE RUBBLE" so it only fires when the harvester is DAMAGED/REALLY_DAMAGED ? Give the weapon a AttributeModifierNugget that does the actual ironcurtain effect and invulnerability stuff. Have a dummy specialability SP. with a 30 second recharge, use the MonitorSpecialPowerTimerUpdate to set a modelcondition like (SPECIALPOWER1_READY), use that modelcondition to trigger a status through lua that enables/disables the weapon by using ForbiddenFiringObjectStatus or RequiredFiringObjectStatus in the weapon. Trigger the dummy sp to fire itself on whenever the ironcurtain attacks/fires its weapon (ATTACKING condition should trigger of the Fireweapon module iirc) , have that condition trigger the Dospecialpower function in lua firing the SP. Alternatively you might work of your prismforwarding coding, take the fire weapon on object coding in there and adapt it to fire on harvesters? Maybe...
  18. did you manage to SET a Status with that function? And what status did you set then? Shouldnt it be something along the lines of ExecuteAction("UNIT_CHANGE_OBJECT_STATUS",self, "UNATTACKABLE",1) then? Also is the %self a spelling error? Did he say you could use it like that or did you need his extended Lua mod for it?
  19. Been experimenting with it myself and i'm not rly getting anything satisfying either. For testing purposes i've been turning the firehawk into the orca and back. It does seem that the replaceself module wants to insta switch and isnt rly using its unpacktime like i hope/expected it would. So i tried to do a Oncreate Dospecialpower lua thing, but weirdly enough the firehawk doesn't seem to want to do that, the orca does tho....so i have a half working solution but with some additional bugs when its created on the helipad. I hae to rethink and retry somethings, might look into it later this week again. Also i don't think a dummy will do it, its a convoluted solution that most likely will create more issues then it solves.
  20. Well if you want Unit B to go back ito A aswell you can duplicate the code into B aswell. The process is the same, just make sure you use a object type upgrade and not a player type upgrade. Normaly the replace happens after "NewObjectUnpackTime"expires. Let us know if it works this time or not, maybe post a vid including what isnt working. Oftopic, the exhaust you use on your aricraft, where did you get it or did you create it yourself(looks like a combination of 2 particle systems the rings and the air distort texture ?) I've been working on and off on getting a nice railgun particle effect and that "air wobly effect" you have going looks rather nice. Edit: Nvm the above particle fx, managed to got it working (worked of the orca engine fx, got the result i wanted.)
  21. i think you need to take a step back and re-evaluate what you are trying to achieve. You are basically getting lost in the woods looking for a specific tree at this point. Just go back to basics. You don't need all that shield junk. From my understanding this is what you want: 1. You have a firehawk like unit and you want to turn it into a orca like unit, in regards to flight behavior and maybe this orca like thing has a different weapon. The problem you had is you don't want the unit to be attacked(idealy by ground units) while its changing from A to B right? How do we do that? Replace self module <!-- Object = per unit, PLAYER = globaly/army --> <UpgradeTemplate id="Upgrade_A_TO_B" Type="OBJECT" /> <!-- This ONLY goes into unit A, not into Unit B --> <ReplaceSelfUpgrade id="ModuleTag_ReplaceSelf" NewObjectUnpackTime="2.0s" CheckBuildAssistant="false"> <TriggeredBy>Upgrade_A_TO_B</TriggeredBy> <ReplacementTemplate>Unit_B</ReplacementTemplate> </ReplaceSelfUpgrade> <!-- Remember to add a LogicCommand, LogicCommandSet and a PlayerUpgradeButton --> Next , How de we prevent the unit from being attacked? <!-- This ONLY goes into Unit A Behavior section --> <StatusBitsUpgrade id="ModuleTag_StatusBitUpgrade" StatusToSet="UNATTACKABLE"> <TriggeredBy>Upgrade_A_TO_B</TriggeredBy> </StatusBitsUpgrade> <!-- Normally status isnt tranfered between different units so shouldnt need anything to clear it --> Now Lets assume i'm wrong inthe abve comment line and The replaceselfupgrade is hardcoded to transfer Object status to the new Unit B. We can do the following: <!-- This only goes into UNIT B --> <StatusBitsUpgrade id="ModuleTag_StatusBitUpgrade" StatusToClear="UNATTACKABLE"> <TriggeredBy>Upgrade_Remove_NoAttackStatus</TriggeredBy> </StatusBitsUpgrade> <UpgradeTemplate id="Upgrade_Remove_NoAttackStatus" Type="OBJECT" /> And you trigger Upgrade_Remove_NoAttackStatus through lua. Just use the Oncreate condition, look at the existing examples in lua.ini and ScriptedEventlist.xml Remember to add/update your unit B's AILuaEventsList="MyUnitB_Functions" in its <AI</JetAI></AI> section. Try that
  22. Are you putting that in the original unit or the replacement unit?
  23. 1. Keeping them grounded: Trigger a status like IMMOBILE or so once landed from the TAXI conditionstate maybe? Remove that status when exiting -RELOADING? 2. Map wise you can tell a aircraft to garrison its airfield and that makes it land (have a look at any of the sp maps that use that like the gdi first mission or the gdi mission with the battlebase /empy nod vehicles mission, see what script that is precisely and work from that), so maybe use lua to trigger that script on the Onclip empty condition? 2b. ive been experimenting with a remnant of the ZH aurora code to simulate aircraft fuel. It works pretty well so far but needs more work for my use but you might be able to use it to force AI aircraft home on clip empty aswell. Altho AI control might override it? <JetAIUpdate id="ModuleTag_JetAIUpdate" AutoAcquireEnemiesWhenIdle="YES" NeedsRunway="false" KeepsParkingSpaceWhenAirborne="true" OutOfAmmoDamagePerSecond="1.5" MinHeight="5" CirclesForAttack="true" ReturnForAmmoLocomotorType="SUPERSONIC" UseForOutOfAmmoCheck="SIGMA_DummyFuelWeapon" OutOfAmmoEvaEvent="AircraftOutOfAmmoDamage" ReturnToBaseWhenVictimDead="true" AILuaEventsList="GDIFirehawkFunctions"> <UnitAITargetChooserData SympathyRange="100.0" /> <LockonInfo /> </JetAIUpdate> <LocomotorSet Locomotor="FirehawkLocomotor" Condition="NORMAL" Speed="200.0" /> <LocomotorSet Locomotor="FirehawkLocomotor" Condition="SUPERSONIC" Speed="200.0" /> <LocomotorSet Locomotor="BasicHelicopterTaxiLocomotor" Condition="TAXIING" Speed="10" /> i just use the same locomotor for the supersonic condition as the aimodule needs that conition to work iirc. I use a dummy weapon for fuel count, my actual weapons on the aircraft autoreload, but you can use the normal weapon for Useforaotofammoceck=
  24. duration isn't a valid attribute of either the statusbitupgrade module nor the upgrade module it inherits of. In the ra3buildstudio or the normal tw compiler you would've gotten a error on a invalid attribute and it would've aborted the compile. Its a surprise its willing to work at all with that module at this point. Are you applying the status effect to the original unit or the replacement unit? If its the latter, then its not working because of the explained reason above, duration isn't a valid attribute. if you want a duration you are better of applying a attribute modifier with a duration and statuscondition. you can trigger that with a basic specialpower+atrib mod that you trigger Oncreate with a Dospecialpower lua command. Although you can maybe use a direct EXECUTE_ACTION lua script but from the top of my head im not sure if there is a status codition +duration script, iirc there is a modelcondition one tho, not sure about status.
  25. Ravendark

    Should you target strong or weak units first?

    Fair point in general. But i feel the video is more intended to consider a absolute scenario. Unit A vs Unit B strength and weakness. Alot of the tactical nuances that make a great "total"game aren't or shouldn't be considered. Things like player skill, terrain, economy strength, ruses, abilities etc. That aside something interesting related to this topic: I was working on my mod yesterday, haven't had alot of time this year so do so, but now i got sometime. so i decided to do a quick skirmish to refresh myself on what i ha done so far and some of the changes was working on. I have a infantry unit that basicly has 2 weapons: a rocket weapon (think along the line of a LAW) and a missile weapon (something like a JAVELIN). The rocket weapon is on by default and uses a sort of defragmentation warhead. Its basicly explosive dmg and some aoe dmg. Rather effective vs infantry (if it hits close enough, it isnt accurate vs infantry), light vehicles and medium armor. When the unit enters cover and a garrison it switches to its missile weapon. Shit vs infantry but does amazing dmg vs vehicles. Due to how the weapons work, the infantry gets decimated out in the open by most vehicles, strength in numbers determines most of the time who wins. But when that unit is in cover or a structure it melts armor like its nothing. So: open terrain: i it has strength of numbers its rockets can some serious dmg to anything depending on rng how they hit or miss. A good focus fire from something like a apc or buggy can counter that specially if those vehicles have a strength in numbers aswell. Something like a mammoth tank can withstand the rocket onslaught long enough to crush them with some micro. The explosive defrag warhead of the rocket is a treath to rifle infantry even. But in a urban environment: The missile weapon is 100% accurate to vehicles and 2-3 missiles can kill a apc like armor/hp vehicle. Garrisoned they are protected and cant be crushed, cover i tweaked the armor bonus so they have increased survivability even if you would focus them. But they are absolute shit vs infantry now. And riflemen can advance without effort onto them. I also changed my sniper to be able to clear (shot per shot) garrisons instead of grenadiers. So the sniper is a serious hardcounter in general to them. So in a ideal scenario like the above video...yes most in that video is accurate. But when you bring more complexity to a single units design those rules go out of the window partially or fully. Even with disregarding player aptitude.