• Post Your Current WIP!: V5 "it's a Gumpert Apollo"
    5,031 replies, posted
Strange, E2 doesn't seem to drop server framerate near as much as complex physical systems. I wasn't able to get more than two REX walkers spawned due to sbox max ACF ammo limits, but two had no effect on server framerate when walking side-by-side. Two tanks with solid axle suspensions, 7 tires on each side, was enough to drop server framerate down to high 40s without moving very fast at all. Will this stop people from building solid axle suspensions, or tanks with many tires? No. Will this stop people from building mechs because someone claimed they caused lag? Evidently, yes. ( Edited for proof ) [T]https://puu.sh/riTrP/3414fde5fd.jpg[/T] ( Not my tank. Forgot where I got it exactly. ) [T]https://puu.sh/riTkx/6bf3436c66.jpg[/T] Looks like the holograms used for RedReaper's track E2 drop significant client framerate as well. It becomes much worse when using the lua tracks tool. ( Edited for overkill ) [T]https://puu.sh/riTZP/ecaad75703.png[/T] Infact, it seems bfw_v5 has no effect on the server at all -- The physical mech itself lags more than the E2 [T]https://puu.sh/riUcO/0c5c5ada17.png[/T] It only takes one tank to drop my framerate substantially however, and also raise ping noticably. I can't get a reliable screencap of it, but the server framerate fluctuates slightly even though the tank is frozen and has less E2 chips in total than REX. I'm chalking this up to the hologram treads in this case, however... Let's take them both for a joyride. [T]https://puu.sh/riUpf/1864207730.jpg[/T] [T]https://puu.sh/riUAF/ad10d988fe.jpg[/T]
You do know there's a tool for tank treads now right? Don't have to use red's chip anymore, lol. Also people generally don't like mechs because they're hideously unbalanced, not so much server impact. Mechs don't have spinning wheels, they lag less than tanks. However, they don't have any kind of balanced mobility aspect from ACF, and have considerably less surface area to armor (meaning tons of armor) and the fact that they shoot down on tanks, ripping through their roofs and nulling armor slope. That and very few people actually make the legs important to the mobility when damaged.
I was fairly specific when I said framerates are significantly worse with the tank treads tool. Not that it's bad -- just suboptimal for those with lesser computers. I won't argue balancing -- bfw_v5 does appear to clamp your mech max velocity to somewhere around 30kph by default, and requires indepth editing and knowledge of how it works to bypass, but it hardly takes legs into account for whether or not you've been crippled, only feet and hip and torso. When I rework REX I intend to re-write bfw's check entirely to require a minimum number of props be selected to function. Granted this won't truly fix anything but it's a step in the right direction for rendering a mech dead when it's lost a calf or thigh. Not speaking for anyone else, but any ACF legal mechs I'd build I'd limit them to about *1.5 the height of a Tiger tank, as a Tiger is relatively tall but not so tall as to have an advantage. And probably, I'd limit them to being very light, 10t at the most, simply because mechs don't have to abide by the laws of physics when carrying an entire battleship's worth in ammo up its' arse and suffer no speed or mobility consequences from having extreme weight parented to them. I at least understand that they're unfair in that regard and wouldn't play nasty if I were pitted against era-authentic armor. ( I don't really like the ice-skating either. ) Well, I also wouldn't build bipedal either unless I'm already planning to basically build another Metal Gear anyways. Bipedal mechs are much harder to design for legal competition than quadrupedal or beyond, simply because they tend to have the legs underneath them lest they look very funny.
[QUOTE=lintz;51083598]mechs are just 90% more likely to be the cause of that than a tank[/QUOTE] The chip I mentioned runs at roughly 1-2k ops which is more than a fair amount for a mech chip and the skeleton only needs a maximum of 8 constraints, excluding the seat weld. Bodies need nocollide ticked on multiparent so the chip can detect props properly without tick quota crash - if anyone has a better way of doing this, inform Dakota. But nocollides on parented props don't cause any bit of serverlag whatsoever, since parented props can only drain fps but have no hitbox to cause server lag. About skating and jetpack abuse, if you see people like that on a war server, why not kick them? Jumpjets can be useful if configured properly (Mechwarrior 4, anyone?) but mechs shouldn't be frowned upon just because a few tardfaces fail to make them in a reasonable way. [QUOTE] I'm working on a heavily modified version of bfw I'm using for REX, if anyone cares for a copy. All I've truly modified is walk cycle speeds, max speed, and an imperial crunchroll of new sound triggers for various stuff.[/QUOTE] You should also change the controls from eyepod to cam controller. The chip is nice because it allows people to make quadro-leg mechs as well as regular bipedals but there doesn't seem to be any recent and useful version around.
[QUOTE=Oldrid;51083950]eyepod to cam controller[/QUOTE] While I'm not experienced enough to do that, at some point I did intend to try to hackjob a way to implement a smoother approach than what it does currently. Having it approach a desired angle rather than snap-to, and on-command free the user's eye angles from the mech to allow viewing from angles other than directly forwards. Remember, I'm not a professional nor a serious programmer, so don't expect too much. I'm practically just throwing the E2 at a wall and seeing what happens!
My biggest problem with mechs mostly what karbine described, crazy movement, no internal components that matter much aside from ammo, that can hide behind large amounts of armor due to said lack of internal components. I find the way WT handled the mech april fools joke really well. Slow, but capeable of crossing things tanks couldn't and internal engines that provide power.
[QUOTE=Danny1828;51084508]My biggest problem with mechs mostly what karbine described, crazy movement, no internal components that matter much aside from ammo, that can hide behind large amounts of armor due to said lack of internal components. I find the way WT handled the mech april fools joke really well. Slow, but capeable of crossing things tanks couldn't and internal engines that provide power.[/QUOTE] Will admit I was actually pondering over making an ST-1 a while back, either the motivation left or I just didn't bother finding a mech chip, though. Does seem overall that in terms of walking tank, that april fool's event was one of the better representations. Perhaps a fix would be having a chip that required linkage to an ACF engine and transmission or something, maybe. There's gotta be some way to fineagle it so if you want a 30t mech to move at a reasonable pace, you need an engine that can manage 300hp for at least 10hp/t, like a reasonable comparable tank. Only way you'd get a lighter mech to fly is if you stuffed it with a big bulky turbine or V12, and when that's shot out, you're dead. Or, at least, can't move. I dunno, I've never made a mech, don't know the intricacies or anything. Anyways, finished that armored arty; [t]http://images.akamai.steamusercontent.com/ugc/261596590537364708/192C49CE080B6EE9A75EE2ECEEAFF1139D277F79/[/t][t]http://images.akamai.steamusercontent.com/ugc/261596590537369655/B7CA170DA236AB6DDF4D5DB848A70714B201BE47/[/t] It is rather on the short side for a 32-ton tank, but it gets the job of toting around a 150mm mortar done well. Pod is a pilot seat stuck in vertically, just about fits in the fighting compartment. Still only carries ten shots, still has 200mm effective on the front and 80mm sides. Pretty nice little thing, all things considered. [t]http://images.akamai.steamusercontent.com/ugc/261596590537371709/E92A97DBEA28C83915E2DF5CBF340FE9B932576E/[/t] Arty? What Arty? No Arty here, just us bushes...
Mechs are kinda of a tough spot with balance against ACF right now; typically you have a chip that controls movement instead of an ACF power source, and damaging the legs doesn't affect movement ability. This contrasts poorly with ACr requiring an engine and breakable wheels for traditional tanks. While some servers have restricted much specs in an attempt to balance them, and there are several pub chips out there that have their own built-in balancing mechanics, these aren't particularly elegant or reliable solutions. The problem is actually coming up with a viable way to balance mechs that is relatively easy to code, lightweight serverside, and is agreed upon by the community.
[QUOTE=Danny1828;51084508]My biggest problem with mechs mostly what karbine described, crazy movement, no internal components that matter much aside from ammo, that can hide behind large amounts of armor due to said lack of internal components. I find the way WT handled the mech april fools joke really well. Slow, but capeable of crossing things tanks couldn't and internal engines that provide power.[/QUOTE] At least the mechs made with Dak's chip don't really need internal components. They stumble and fall as soon as you destroy one part of a leg, the torso or hip.
[QUOTE=Danny1828;51084508]mech stuff[/QUOTE] I had an idea I'm going to try soon where bfw derives the walk cycle speed from how fast a flywheel is spinning. Using applyAngForce to provide resistance based on the speed of bfw's walk cycle, an ACF engine would have to work against that resistance to enable the walker to move -- This would mean the more armour is placed on, the weaker the ACF engine, the slower the mech walks. This, in theory, would almost entirely resolve the main disparity between mechs and tanks: Mechs being able to hold infinite amounts of armour with no penalty. Furthermore, this same flywheel could have even more resistance applied to it based on the weight of the baseprop, and the hold force of the baseprop increases based on flywheel speed so the entire mech's movement is dependent upon whether the flywheel is spinning at high enough RPM or not. This would lead to amusing walker setups, mechs with an entire compartment dedicated to their precious horsepower that allows them to walk to begin with, possibly even entire rows of smaller engines to try to cheat their way into walking faster without using bigger, heavier engines. Likely, raw power would win over torque in this case, similar to the way aircraft in ACF currently work. Speaking of, here is my current WIP: [T]https://puu.sh/rj5w5/74c42b0d6a.png[/T] Not sure where this is heading, but the eventual end goal is something only slightly tank shaped that acts as the mech equivalent of a sports car, using that ACF flywheel method I described to determine the walk cycle of its' bfw chip. A prototype to test the idea. And for ACF legality I'm going to experiment with adding an additional check for the models the legs are made of. Perhaps tallying up the number of feet, and make the user link the E2 to a minimum of 2 additional props per each foot for the rig props that make up the legs. This doesn't stop cheating at all, as they can link the E2 to literally any prop they want at that point, but it would be easy as Hell to see when someone is cheating by whether or not their mech falls limp upon losing part of a leg.
[t]http://i.imgur.com/bpzw7yc.jpg[/t] I'll just leave this here
[T]https://puu.sh/rjyRa/b25a1248f5.png[/T] "I couldn't go fast."
content: Almost done 2000 Honda S2000, Still need to make a custom speedometer, do all the badges and that's about it [t]http://images.akamai.steamusercontent.com/ugc/259344255629885899/D03F84C977576F808992F631A2A6B990AB72E234/[/t] [t]http://images.akamai.steamusercontent.com/ugc/259344255629885455/2895C87BF597ED1F3ED9C121B6C1DA957BE62C27/[/t] [t]http://images.akamai.steamusercontent.com/ugc/259344255629885076/A834DA7A16782052FE940C9A1A5DC129E237C12E/[/t] Completely finished the 200SX S14 [t] http://images.akamai.steamusercontent.com/ugc/259344255638786817/135FE817AA075E8CF04D9B72C81C880FEDA48647/[/t] [t]http://images.akamai.steamusercontent.com/ugc/259344255638786302/A79A260778263A08C061F4375E95AA5A940EBEB8/[/t] and [t] http://images.akamai.steamusercontent.com/ugc/259344255650337094/76C329CFDCFF1F41D4DC6BDE8765A4A64117EDE4/[/t] [sp] sorry for the huge block of images, had multiple projects going and had a massive burst of motivation to finish them all within the space of 2 weeks, apologies for making your mousewheel fingers sore [/sp]
Just gonna pop this here. Yea [video=youtube;1laE9JoMPyQ]https://www.youtube.com/watch?v=1laE9JoMPyQ[/video] If anyone has a ball MG e2 that I could use it'd be very much appreciated :> Oh, and I'll have that video coming up tomorrow probably white :>
Really excellent video. Can you show us all the crew positions, perhaps? It looks like you really went to a lot of trouble to get the view positions just right, and it payed off. Reminds me a lot of how Red Orchestra did tanks.
[QUOTE=Svennex;51083487]I'm working on a heavily modified version of bfw I'm using for REX, if anyone cares for a copy. All I've truly modified is walk cycle speeds, max speed, and an imperial crunchroll of new sound triggers for various stuff. May bother making a tutorial for using bfw, and how to change more walk cycle parameters than the vanilla "step height multiplier" you're given by default -- I think it's actually extremely creatively limiting that bfw doesn't present max speed and max walk cycle parameters to you natively. There are more mechs that can be built than just big, heavy, slow moving armor-plods with guns. I might even make a stylized racing mech under 10t just to show it can be done without it looking like par farce garbage. I mean Hell, REX without the armor and ammo weighs a measly 4t. Perhaps I'm actually more upset that it seems there's a stigma against walkers because they /can/ cheat, and thus "will cheat" -- even if they don't and the user followed ACF legal rules to the T. ( For the sake of reference by the way, vanilla bfw restricts your max mech velocity anyways -- It will never run faster than a seemingly arbitrary speed that seems to be based on your hip height from the feet. It barely outpaces the HL2 Jeep, and the majority of tanks greatly outpace that. ) I don't know about you guys, but I don't have any "secret methods I don't share how I do things", I just throw random trash together until it acts like it isn't trash. Probably still is trash under the hood, but if nobody else knows that, do I really care?[/QUOTE] BFW's innards are pretty easy to find. There's a set of variables that are set after the initial data from the mech's layout is grabbed. I intended for it to be very easy to pick up and use, and I'm glad to see people are still using it. The "locked velocity" you're experiencing is actually the chip trying to figure out the current speed of the body and then making the mech's walk cycle [i]almost[/i] match that speed with a small amount of loss, allowing for deceleration, while at the same time adding in the new player-provided walk vector to push the mech's gait in the direction you want it. That's why it feels weirdly hard to control, like it has a ton of inertia behind it. It doesn't walk without actually scraping the ground with its feet. It needs friction to operate, so there's an upper limit on how fast it can run. I've had successful tests with other varieties of mech chip that use the same system, but I can't really tell you why one system works better than the other, there's a lot of variables at play. Eventually I settled on something a bit more brutally simple for my walking cycle and decided to devote most of my flair to how the mech operates with rotation (propellering was an issue with BFW) as well as a fuel-limited aux movement system. Modelled on the movement in Hawken, I wrote this e2: [code] @name Hawken Walkin' @inputs [ADV CAM EMARKER]:wirelink @outputs [POS DIR SHOOTHERE]:vector Sx Sy Sz BoostOut FUELAMT #inputs @persist W A S D Space Shift Active #entites @persist [Pod Torso Hip FL FR]:entity Vitals:array #direction vectors @persist [HF HR HU TF TR TU]:vector @persist Bearing Elevation X Y LX LY CX CY DivX DivY #quats @persist [HHQ THQ HTQ TTQ HCQ TCQ]:quaternion @persist [HRO TRO]:vector #Vector offsets @persist [FLTL FRTL FLO FRO]:vector #other variables @persist Perc Time WalkVec:vector Inputs N Total Kill Dran:ranger @persist SpikeVec:vector SpikeAmt XTog SpikeTot #Jumping @persist InitZ InitLen JOffset JZMove JForce:vector #Quick Turn @persist PunchPerc FPerc #Tweakables @persist StepS StepHM Throttle MaxXDiv MaxYDiv CamOffset:vector @persist HipTorque TorsoTorque FootMul HipMul BoostMul DodgeMul @persist HovHeight JPush FuelPerc Fuel #sound things @persist JINIT:string JLOOP:string BOOSTINIT:string BOOSTLOOP:string DODGE:string @persist QUICKROT:string @trigger none interval(20) if(dupefinished()) { reset() } if(first()) { rangerPersist(1) rangerFilter(entity():getConstraints()) Pod = ADV["Entity", entity] Torso = EMARKER["Entity1", entity] Hip = EMARKER["Entity2", entity] FL = EMARKER["Entity3", entity] FR = EMARKER["Entity4", entity] Vitals = EMARKER["Entities", array] Total = Vitals:count() HF = vec(0, 1, 0) HU = vec(0, 0, 1) HR = HF:cross(HU) TF = vec(0, 1, 0) TU = vec(0, 0, 1) TR = TF:cross(TU) #Held Quat Stuff HHQ = inv(quat(Hip)) * quat(HF, HU) THQ = inv(quat(Torso)) * quat(TF, TU) #Held Vector Stuff DispFL = Hip:massCenter() - FL:massCenter() FLTL = vec(DispFL:dot(HF), DispFL:dot(HR), DispFL:dot(HU)) DispFR = Hip:massCenter() - FR:massCenter() FRTL = vec(DispFR:dot(HF), DispFR:dot(HR), DispFL:dot(HU)) #Tweaking Variables StepS = 20 #Stepsize StepHM = 1.5 Throttle = 16 #Time increment HipTorque = 800 TorsoTorque = 800 FootMul = 8 HipMul = 8 BoostMul = 120 DodgeMul = 1200 HovHeight = 600 JPush = 8 JZMove = 10 MaxXDiv = 4 #Maximum bearing change per frame MaxYDiv = 4 #maximum elevation change per frame CamOffset = vec(-125, 0 , 75) #where you are with a camera. FuelPerc = 0.01 Fuel = 1 JINIT = "weapons/rocket_blackbox_explode2.wav" JLOOP = "weapons/flame_thrower_loop.wav" BOOSTINIT = "weapons/rocket_blackbox_explode2.wav" BOOSTLOOP = "weapons/gatling_spin.wav" DODGE = "weapons/ar2/npc_ar2_altfire.wav" QUICKROT = "weapons/metal_gloves_hit_world4.wav" timer("checkvitals", 10000) } #inputs and setup if(clk()) { W = ADV["W", number] A = ADV["A", number] S = ADV["S", number] D = ADV["D", number] Space = ADV["Space", number] Shift = ADV["Shift", number] Active = ADV["Active", number] #do wasd first, then space, then shift. #neyepod mechanics Eye = Pod:driver():eye() Flat = (Eye - Pod:up() * Pod:up():dot(Eye)):normalized() LX = X CX = acos(clamp(Flat:dot(Pod:forward()), -1, 1)) * sign(Flat:dot(Pod:right())) + XTog * 180 if(CX > 180) { CX = CX - 360 } if( (CX - LX) > 180 ) { DivX = (LX - CX) - 360 } elseif( (CX - LX) <= -180 ) { DivX = 360 - (LX - CX) } else { DivX = CX - LX } X = X + clamp(DivX, -1 * MaxXDiv * (8)^(PunchPerc > 0), MaxXDiv * (8)^(PunchPerc > 0)) Cost = 15 * FuelPerc if(Shift & (S & $S > 0) & (Fuel > Cost)) { #TODO:Add quick 180 sound Fuel = Fuel - Cost Hip:soundPlay(entity():id() + "quickrotate", 0, QUICKROT) soundPitch(entity():id() + "quickrotate", 75) PunchPerc = 1 XTog = !XTog } PunchPerc = clamp(PunchPerc - 0.08, 0, 1) if(X > 180) { X = X - 360 } elseif(X <= -180) { X = X + 360 } Cost = 0.5 * FuelPerc if(Shift & (W & $W > 0) & (Fuel > Cost)) { #TODO: Add boost loop Hip:soundPlay(entity():id() + "boostinit", 0, BOOSTINIT) soundPitch(entity():id() + "boostinit", 100) Hip:soundPlay(entity():id() + "boostloop", 0, BOOSTLOOP) soundPitch(entity():id() + "boostloop", 75) } if((!Shift & ($Shift < 0)) | (!W & ($W < 0)) | (Cost >= Fuel)) { #Stop boost loop soundStop(entity():id()+"boostloop", 0.25) } Bearing = X * Active LY = Y CY = acos(clamp(Eye:dot(Flat), -1, 1)) * sign(Eye:dot(Pod:up())) DivY = CY - LY Y = Y + clamp(DivY, -1 * MaxYDiv, MaxYDiv) Elevation = clamp(Y * Active, -45, 45) CF = vec(sin(CX)*cos(CY), cos(CX)*cos(CY), sin(CY)) CU = vec(0, 0, 1) CR = (CF:cross(CU)):normalized() CU = CR:cross(CF) CPOS = Torso:massCenter() + CF * CamOffset:x() + CR * CamOffset:y() + CU * CamOffset:z() CDIR = CF Dran = rangerOffset(Torso:massCenter(),
What I always did with BFW was make an E2 to input values from A/D that would normally be from the eyepod for hip turning, and then an aiming chip for a torso. It worked great.
Whenever I wanted a tank-type system, i did something like that with a simpler separate hip and torso e2. The problem is, for most applications, the simple mouse-aimed systems that you can make that mimic how players move usually made it easier move and fight intuitively than the tank control scheme. With the relative vulnerability and proclivities of mechs to carry mostly higher rate of fire weapons, more maneuverability means you're less likely to get pulped by heavier caliber rounds from more stationary tanks. Still I can understand why people don't like them very much.
Genuine inquiry regarding tanks. What scale do you use for you actual MBTs when you build them? ie (1:2)
Most tanks seem to be built around 3/4ths the size of real ones. probably the best way to describe the scale of tanks compared to real life in acf: [img]http://i.imgur.com/wQo6iSv.png[/img]
[QUOTE=MrWhite;51089201]Really excellent video. Can you show us all the crew positions, perhaps? It looks like you really went to a lot of trouble to get the view positions just right, and it payed off. Reminds me a lot of how Red Orchestra did tanks.[/QUOTE] Bam bada-boom. Here it is. [video=youtube;66DQQ4DpLdI]https://www.youtube.com/watch?v=66DQQ4DpLdI[/video] So basically, I just have cam controllers for everything and I just use a toggle to switch between 2 positions. 1 being FP and the other being the optics.
if you want things to be reasonably sized to the player, the thing i do is: get the real sizes, multiply them by 0.75 and then measure them out with the measuring stick tool. never failed for me
[QUOTE=Sestze;51090887]words[/QUOTE] Authentically baffled in a manner that I garnered a response, given how borderline arrogant I felt even touching bfw to begin with as if I expected to understand it despite hardly understanding most of the mathematics it was using. Hardly helped either that you had very clearly grown tired of helping others long ago in your other threads where you had replaced your posts with <derp>, which actually had me mildly concerned even mentioning I was doing anything with bfw to begin with, lest I be descended upon for some mysterious manner of heresy or for trudging up the past. Either way, my concept for using an ACF engine powered flywheel hasn't turned out the greatest, and I set out with the task of understanding bfw_v5 more -- I'll admit, I haven't learned a single thing about how it truly works beyond tweaking certain variables just makes it not work, and tweaking some others makes things seem to move faster at the expense of stability. Now that I know what's really revving under the hood, I understand why it came at that expense. I believe I have at least comprehended how it works conceptually, but you know what, my inexperience with programming means the code itself is still essentially Spanish to me. Spanish in the way that I understand only some parts of it, and the remainder is practically white noise. And, hm. You're right -- At first, I believed this line: [code] Time = Time + clamp(Adjusted:length() * 360 / (StepS * 2 * pi()), 0, ThrM*(1.5)^Boost) [/code] was clamping the evident maximum walk cycle to what at first to me appeared as being totally up to preference without any real reason, but somehow I had the feeling that wasn't quite it either with the amount of non-static operation going on. One of the greatest bothers to me has always been the way bfw locks its' baseprop to the Y axis similar to a keepupright. And that's the first thing I hoped to free bfw of, though as I come to understand it more, I also come to understand that may simply be impossible without working vastly more than I ever expected to from the start. Who knows, so far my understanding of it is exclusively that it's essentially an incredible amount of position offsetting taking place to give the illusion of "real" physics, with the baseprop as the frame of reference. Apologies if I'm coming off too eager; After having only just gotten into the building scene earlier this month, I'm very particular to making up for the lost time I had spent essentially doing everything /but/ building in this game. To everyone else, apologies for the Great Wall of Text. Have minor content. [T]https://puu.sh/rkUZ0/edf091afde.png[/T] A fair measure of pages ago, someone I forget their name posted a dupe of a chassis, saying something about not being able to figure out what to do with it. [T]https://puu.sh/rkV19/3f4be69324.jpg[/T] So, in light of the troubles I've had getting any of my other projects to work, I based a simple scout vehicle, tug-tug, fuel-carrier, or whatever the driver wants it to be, Half Life 2 Scout-Car inspired thing on the chassis they had released. Only modification I made to the base chassis was replacing the engine, the rest is aesthetic only. [T]https://puu.sh/rkV4I/a92de7a7de.jpg[/T] Makes no use of the gastanks on it, in favour of using them to refill other tanks. I've actually never experimented with how refilling other tanks works -- So I don't know if this vehicle actually does it's job at all. Anyone who knows, input would be appreciated. I've been stuck on how exactly to make it tug other things -- Grabber was my first obvious option, but large heavy things I've grabbed with the grabber have a propensity for simply explosively freaking out and taking me into the great blue yonder with them. Any suggestions?
This thread needs more Multi-track Drifting! [t]http://images.akamai.steamusercontent.com/ugc/482272972284679734/961B049138DD3BF724FC57AE7516BE44EA591509/[/t]
[QUOTE=hermanberk;51093039]if you want things to be reasonably sized to the player, the thing i do is: get the real sizes, multiply them by 0.75 and then measure them out with the measuring stick tool. never failed for me[/QUOTE] Do not do this. 1 unit is 1 inch, and the player model is 72 inches high. If that were on that were on the .75 basis, player would be 4'5".
And here I am keying the size of the vehicle off the size of the ACF powerplant I want to use :v:
i just grab real life measurements of tanks and convert them to inches. doesn't matter whether sprops is scaled to 1:1 or 3:4, my tank ends up scaled to sprops and that's really all that matters
[QUOTE=Svennex;51093095]Authentically baffled in a manner that I garnered a response, given how borderline arrogant I felt even touching bfw to begin with as if I expected to understand it despite hardly understanding most of the mathematics it was using. Hardly helped either that you had very clearly grown tired of helping others long ago in your other threads where you had replaced your posts with <derp>, which actually had me mildly concerned even mentioning I was doing anything with bfw to begin with, lest I be descended upon for some mysterious manner of heresy or for trudging up the past. Either way, my concept for using an ACF engine powered flywheel hasn't turned out the greatest, and I set out with the task of understanding bfw_v5 more -- I'll admit, I haven't learned a single thing about how it truly works beyond tweaking certain variables just makes it not work, and tweaking some others makes things seem to move faster at the expense of stability. Now that I know what's really revving under the hood, I understand why it came at that expense. I believe I have at least comprehended how it works conceptually, but you know what, my inexperience with programming means the code itself is still essentially Spanish to me. Spanish in the way that I understand only some parts of it, and the remainder is practically white noise.[/QUOTE] I'll gladly explain all the stuff that's going on if you add me on STEAM, I can even show you how to make your own from scratch using the same method. [QUOTE=Svennex;51093095] And, hm. You're right -- At first, I believed this line: [code] Time = Time + clamp(Adjusted:length() * 360 / (StepS * 2 * pi()), 0, ThrM*(1.5)^Boost) [/code] was clamping the evident maximum walk cycle to what at first to me appeared as being totally up to preference without any real reason, but somehow I had the feeling that wasn't quite it either with the amount of non-static operation going on. One of the greatest bothers to me has always been the way bfw locks its' baseprop to the Y axis similar to a keepupright. And that's the first thing I hoped to free bfw of, though as I come to understand it more, I also come to understand that may simply be impossible without working vastly more than I ever expected to from the start. Who knows, so far my understanding of it is exclusively that it's essentially an incredible amount of position offsetting taking place to give the illusion of "real" physics, with the baseprop as the frame of reference. [/QUOTE] It's not quite "fake" physics. Everything ties into Newton's Third at the end of the day, all of the forces being applied to the feet are reflected back on the hip. A large system of averaged springs for translational movement, with locked rotation via advanced ballsocket.
[B]You want ships and planes? I've got ships and planes![/B] The HS-E Family of ships, all based off of the same fictional hull. They were all intended to fill different roles and have slightly different characteristics to them. I'll probably fill out the specifics when each ship is done, but here is the stuff they all have in common: -Prop Count of 240-260 -1x40mm Autocannon -1x20mm RAC -1xSmall Spherical Radar -1x4xFIM-92 Rack(not pictured) -2x4xBGM-71E Launchers -2x40mm Flare Launchers [t]http://images.akamai.steamusercontent.com/ugc/252588856169785293/754C18ABBB401F157BF147118D0541EF2E5DEA1B/[/t][t]http://images.akamai.steamusercontent.com/ugc/252588856169785414/6CBC0446E4943C5F671906E49B81C9D2A5370B85/[/t] [t]http://images.akamai.steamusercontent.com/ugc/252588856169786028/9CEC361F127E3DB6D07EE2AC165EBE2B6935A559/[/t][t]http://images.akamai.steamusercontent.com/ugc/252588856169786226/60901CF66152C9DC0DF37F94AC4EC302980B19E1/[/t] [t]http://images.akamai.steamusercontent.com/ugc/252588856169786778/0A16D4F07E9224B1C0B8BD72B3D0B88EAA426D33/[/t][t]http://images.akamai.steamusercontent.com/ugc/252588856169786778/0A16D4F07E9224B1C0B8BD72B3D0B88EAA426D33/[/t] [t]http://images.akamai.steamusercontent.com/ugc/252588856169786356/6AFD6D46CE73AC7E24E3A421F9025122BF5C0A94/[/t][t]http://images.akamai.steamusercontent.com/ugc/252588856169786524/8815C019A0D483B06CF0B9FB0D6B51A1C260BAD0/[/t] [t]http://images.akamai.steamusercontent.com/ugc/252588856169786885/A7B23AD0DA9DC8E09FCAD0B0EE94B8B8559A4A78/[/t][t]http://images.akamai.steamusercontent.com/ugc/252588856169780911/7BC39F02B96245A98C45D5F8499DC93072431D97/[/t] HS-E1 is getting a UAV and better radar. HS-E2 is getting a VTOL and 24-VLS missiles cells. HS-E3 gets to keep its whopping 72-VLS missiles cells. *May or may not give them ACF propulsion, depends on how much longer the automated missile defence system takes. Need to take more pictures of the planes, but here is a little teaser. [t]http://images.akamai.steamusercontent.com/ugc/1616050420681306081/B934B9E85FA8C9B97A4E366FF8883ACF49EAEC45/[/t][t]http://images.akamai.steamusercontent.com/ugc/1616049762683534653/94D32FF215B83A54E6B327FE32BB45832907E955/[/t]
1992 Nissan Silvia S13 [t]http://images.akamai.steamusercontent.com/ugc/267226090078136534/A808686BE7C73868ECAC8000F702211929F14CA8/[/t]
Sorry, you need to Log In to post a reply to this thread.