1. Please be advised of a few specific rules and guidelines for this section.

RELEASED Decorative Vehicles 1.5.1

Cars

  1. KejaWicks

    KejaWicks Void-Bound Voyager

    KejaWicks submitted a new mod:

    Decorative Vehicles Mod - Cars

    Read more about this mod...
     
  2. bk3k

    bk3k Oxygen Tank

    One minor criticism/suggestion... I'd make those vehicle windows mostly transparent rather than opaque. But that's just me.

    Of course it would be cooler if they could technically be driven, that's a lot more work and wouldn't be especially useful except on flat terrain. It is still something nice to add flair to cities.
     
  3. KejaWicks

    KejaWicks Void-Bound Voyager

  4. KejaWicks

    KejaWicks Void-Bound Voyager

  5. KejaWicks

    KejaWicks Void-Bound Voyager

  6. universalist23

    universalist23 Scruffy Nerf-Herder

    i hope you can make it driveable because its kinda lame that it just a decoration (sorry my for my english)
     
  7. KejaWicks

    KejaWicks Void-Bound Voyager

  8. JT`

    JT` Phantasmal Quasar

    Cool beans! These would probably work great with the old school jeep Lua script, too. I'ma try it on my end and get back to you. =)
     
  9. beeedrill

    beeedrill Void-Bound Voyager

    May I suggest something? Maybe hi tech looking cars for future updates (hovercars and the like). Great mod btw :nuruhappy:
     
  10. JT`

    JT` Phantasmal Quasar

    This is just an FYI, since I have zero distribution rights -- I'll contribute my work to KejaWicks if s/he wants it, once I actually resolve the bugs. =)

    I currently have the Ambassador working wonderfully as an up-armoured limo, as a proof of concept. I wound up going all out and heavily hacking the unused Chucklefish jeep.lua script (calling the new script "vmcar.lua"). In addition to the typical headlights it also includes working brake lights: a dim red light shows at the back of the vehicle while the headlights are on, and a bright red light activates whenever the brakes are being pressed and deactivates when they're released. It also has a more car-like control scheme where accelerating or decelerating is done by pressing in the same or opposite direction -- unlike a hoverbike, the car won't flip around until you reduce horizontal velocity to zero -- and also distinguishes braking from accelerating in terms of the car's performance: it is faster to decelerate than accelerate.

    In trying to avoid going insane with the graphics, it simply re-uses the graphic from the decorative variant. That means that there are no separate graphical damage stages -- cars still smoke and burn like any other, of course, so that shouldn't be a huge problem. I did a bit of preliminary work on making damage states for the Ambassador and although my work was passable, it quickly became obvious that I wouldn't be able to create background and foreground images with all four damage states for every single car in anything approaching a reasonable amount of time, so I simply discarded it. =P

    There are a few bugs that I'm still working on:
    1) The occupants' feet stick out beneath the car Flintstones-style, although it should be possible to fix this by setting the alpha of all occupants to zero and restore them to visibility after they disembark. The problem with such a fix is the potential for Bad Things(TM) down the line, such as if the script fails to reset someone and they remain invisible until a reload.
    2) I'm having trouble disabling platform collision -- I have it set to drive across platforms by default, but it should be possible to pass through platforms by request so that players can choose upper or lower roads on bridges or tunnels (e.g., the United Systems Expansion truck tunnel). My code for this explicitly tells it to disable platform collision when the player holds the key... but it doesn't. So that still needs work.
    3) There's a bit of logspam in starbound.log about the large inventory image not having an "empty" state in its frames. Unfortunately the only fix to this would seem to be to create a duplicate of the object image in the vehicles folder and apply a new .frames file to it, since the existing graphic cannot have new names assigned without compromising the file structure.
    4) Although I have it designed to perform a stepped-gears pitch shift of the engine, it doesn't actually do anything. There's a lot of vestigial stuff in the CF original script that assigns pitch according to whether the vehicle is jumping or not that I'll probably have to hack further before it works the way I want it to.
    5) The vehicle can only overcome 1-tile-high obstacles and will be stranded/blocked on 2-tile-high obstacles, although to be fair this is actually quite realistic. The vehicle has a jump control and you can try to rock the car free, but you're probably better off getting out and despawning and respawning the vehicle with the controller once you're past the impassable terrain. The vehicle can still overcome 45-degree slopes of unlimited length and the car can make it all the way from the Ark to the Outpost just fine.

    All in all, good progress though!

    Anyhoo, mostly the reason for this post is that I'm trying to decide whether it would make more sense to allow the player to 1) "take" cars after they're purchased from the garage (i.e., after placing them in the world, convert them to interactive items which can then be activated to destroy the 'object' and spawn a vehicle in its place), or 2) to use a full vehicle-controller-based scheme where vehicles are simply spawned from nanites like in the base game. Option 1 is more realistic, but has the disadvantage that you can never remove the vehicle again once it is converted to a vehicle (I think -- it might be possible for the object script to detect a nearby player and set a hotkey to pop it back into an item, though this would discard all damage information). Option 2 is more vanilla friendly, but means there are redundant decorative vehicles versus functional vehicles. I'm leaning for option 2 but if there's interest in option 1 I could definitely make it available.


    [edit - 2018 Aug 14 18:00] Not including a day lost to a final exam, here's day two:
    1) Still have occupants' feet sticking out since I haven't touched that part of the code yet.
    2) Platform collision now works perfectly, although if the car is going too fast, the game's collision detection might miss the platform and drive right through. =) I assigned the "Special1" (F) key to the fallthrough, since I have brakes mapped to [Down] (so that it's possible to stop without changing direction accidentally), but could probably make [Down+Space] work too. I also made a codex purchasable from the garage that teaches the controls in an in-character, humorous fashion.
    3) Logspam gone. Apparently the default.frames in another asset folder doesn't apply to another asset folder with the same file path.
    4) Still working on pitch shifting, although there's been some improvement and bug fixes. Also introduced some fun easter eggs, and even connected those easter eggs to other parts of the game.
    5) The collision box is a little more refined now and it's harder to get stuck, but still possible, which is pretty much bang on where I want it. =)

    Once I get all of the kinks worked out of the Ambassador, it's smooth sailing for the rest of the /objects/cars folder, and then... try to take over the world!


    [edit - 2018 Aug 15 02:00] Hiding the occupants was easier than I thought!
    I was trying to batter the engine with a large, heavy, blunt object to add status effects to all the occupants with world.callScriptedEntity / world.sendScriptedMessage / hooks with player scripts / owmyheadhurts, when it occurred to me that all lounge positions already include native engine parameters to add status effects. Duh! I did have to create a custom status effect (which means that this addon/submod must be installed both server side and client side to work without disconnecting the client), but now all occupants gain a status effect which sets them to full transparency, making them completely invisible while inside the car: game entities still see them, which is hard-coded and unavoidable in general, of course, but they no longer have unsightly feet dangling below the car.

    In the case of the Ambassador, they'll also be immune to damage -- it's bulletproof -- but other cars won't be so lucky. That's not in just yet, but shouldn't take much more work.

    I also played artist and now there's a basic but nifty generic teleportation sprite for spawning in a car, avoiding the need for individual car-specific sprites. It uses the exact same vanilla style and sprite, but instead of a vehicle-shaped outline it uses an ellipse-shaped outline until the car appears. Think of it like a nanite bubble or something.

    Only thing left on my list is the pitch-shifting, which still doesn't work. I'm starting to think it's an engine limitation, like (0.5, 1.0] or something. Trying to set the pitch to 6.5x definitely does not work. At this point, I'm pretty much content to leave it as is and call it done.

    Next up is the Banger, and the rest of the cars folder. Now that the script is stable, I think I can probably knock off a half-dozen vehicle controllers every hour or two, although we'll see how that plays out in practice. I should probably try and get some sleep one of these days, too. ;-)


    [edit - 2018 Aug 17 06:00] Wasted most of Wednesday and Thursday actually playing the game, installing and tweaking some other mods, and working on a different mod of my own, but got back to work on this just before midnight. =)
    Although I've knocked off ten of the cars so far, I also spent a large amount of time preparing for the more novel vehicles that are coming, so my effective rate of two cars an hour is mostly because I spent a lot of time fiddling with things, testing and reloading the .lua script, and making sure that pixel offsets and bounding boxes were utterly perfect -- in other words, paying attention to details rather than just converting in a raw gruntwork effort.

    I went ahead and created headlight overlays for the cars, even though I originally wanted to avoid doing so (so as not to bog down dev time with insane amounts of graphics). This was reasonable because all the cars generally share the same front grille... except the Banger, whose headlights are one pixel closer together than the others and required its own dedicated headlight overlay. Not sure if KejaWicks will want to fix that or not. The redundant graphic isn't as bad as it sounds, though, since the indexed and compressed PNGs weigh in at a whopping 192 bytes (i.e., less than one third as much memory as this paragraph).

    I also made flood light and rallye light overlays for the respective forthcoming cars (e.g., the pickup, the Land Rover, the rally car, etc.), so that when the cars come up on the queue I can simply plop the overlay onto the sprite and ensure the offsets are correct, rather than having to break workflow again to draw more. Of course, once I get out of the cars folder and into the lorries, the vans, and the update folders, I'll have to uncap my pen again, but each hour of work on these foundations still makes the content easier to plop in.

    Most proudly, with some cool scriptwork, the taxi now has a beacon on top that works automatically (only the black cab is done, but the yankee doodle cab can easily re-use the same system with just a few cosmetic edits). If any entity is in a passenger seat, the light turns off, and turns back on again when there are no passengers. It also lights up only when there's a driver in the vehicle. In other words, it works like you'd expect a real taxi light to work! This is pure glitz, but was a lot of fun to work on, even if I had to pull my hair out now and then waiting for /reload to load all my mods after a test vehicle freezes due to a simple syntax error. =)

    I also refined the script to make high-centering even less likely by including a physics tweak: as the vehicle's angle approaches 45 degrees, its ride height is increased by sqrt(2), the same distance needed to traverse a diagonal in Euclidean space -- and interpolated downward from there as it levels off. Because this tended to make cars a bit floaty after traversing the top of a staircase, it also squares the interpolated value so that cars that are on shallow slopes receive much less correction and that the corrected ride height falls off much more quickly. I can proudly say that it is now possible to accelerate up a slope without grinding the collision polygon all the way up, and cars feel much more natural as a result.

    Since the original CF jeep.lua is just a cleverly disguised hoverbike script, gravity originally had no effect on the vehicle -- the hoverbike script is literally designed to fight gravity, after all. So, I also improved the script a bit so that gravity now has an effect on vehicles that are coasting -- you can just let your car roll downhill, and letting go of the gas while going uphill will cause your car to slow down gradually and then even roll backwards. Holding the brakes blocks this effect, of course. I also ignore gravity while the user is applying input, for responsiveness' sake, but I'll try it with it enabled to see if it contributes more realism. I'm still debating applying acceleration along the vehicle's longitudinal vector rather than along the world's X axis whenever the car accelerates or brakes, but I'm worried that might allow vehicles to scale vertical slopes. I'll play with that tomorrow after some sleep. ;-)

    Speaking of jeeps, those are next to convert. I can re-use the vanilla headlights for these, so that's good -- shouldn't take more than a half hour to do both. After the jeeps, it's the convertibles. Convertibles will be interesting because I can no longer get away with the occupant hider effect, and will absolutely have to create a foreground overlay for the occupants to appear correctly in their seats. Fortunately, the wheels cover up pretty much everything underneath the convertible, unlike the Ambassador which has a long wheelbase and a lot of dead space underneath. Dragging feet won't be visible... or won't be noticeable if they do end up being visible.

    Incidentally, this WIP script is 100% generic and based on Chucklefish code, so even though I'm adding features to it with KejaWicks' mod in mind, if I don't get permission to release this submod I can always just use the script elsewhere. =) When I'm done with it I intend to use the script to re-implement the vanilla jeeps as a proof of concept mod under a Simplified BSD licence (as I think that's the most permissive licence that still complies with Chucklefish's rights).


    [edit - 2018 Aug 24 11:00] More work on my other/own mods than on the conversion effort since last time, but little bits of progress through the week. =)
    Done since last update are the jeeps and convertibles (well, the red one, but the others are just colour swaps). That means the initial proof-of-concept offer to KejaWicks for approval only has the Land Rover, Limo, Bean Car, NYC Taxi, Pickups, Police Cars, Rally Car, and Reliant Robin left to go. I'm over halfway there, and what's there is already heavily tested and polished. When/if I receive approval for the first release (and/or just donate the mod to KejaWicks), I can then focus on the remaining folders. The full-sized tractor-trailers should be interesting. It might be worth looking into creating an articulated hinge joint... which is far more advanced physics than I've ever looked into before.

    The script now includes some additional robustness and genericisation. Although the "drivingSeat" is still required, properly-configured cars can now name their remaining passenger seats anything they want, and the script will simply iterate through the seats to apply "emotes" and "dances" to the passengers. Microgravity/zero gravity is now properly supported by cars -- they'll start drifting and there's no ability to do anything other than rev the engine or flick the headlights or what have you. That, I might add, makes this car script one of the most realistic scripts for the game now -- most other vehicles, from mods or vanilla, let vehicles operate in zero G with impunity. Refinements I've been considering are a submersion feature which would render the car inoperable if it stays underwater for more than a few seconds (requiring deconstitution/reconstitution), and would prevent it even from starting in an airless environment, but they currently bend the laws of physics to work. Gravity officially applies all the time now, rather than just when idle, because it did add quite a bit.

    Cars will now also shift their suspensions according to accelerations and decelerations. This is actually a "hacked" effect -- although this also rotates the car's collision polygon, meaning that it will subtly change the impact dynamics of running into a wall depending on whether you're braking or accelerating, it's otherwise just a "pencilled in" visual effect rather than an actual simulation of suspension -- but it adds a lot to the immersiveness and makes a quick rev-and-brake look aggressive rather than sedate. You won't be able to preload a suspension to increase jump height or anything, since the script isn't that advanced. (I've been contemplating a full physics-based solution, including suspension travel and drive wheels Cortex-Command-style, but that's a lot of work for a diversionary side project.)

    I added another Easter egg: a new car, tweaked from another car, just for fun. It's the car that I would own if I had $90 000 to throw around, and the fact that it recently featured prominently in one of my favourite modern movies only makes the car even more appealing to me... too bad I don't have $90 000.

    I mashed up some new sound effects, one of which was a wicked awesome idling Ford GT that provides both the idle sound for the car as well as the car starter sound effect. Although it was hard to get a long sound bite because the fellow starts revving the engine way too early, after the initial coolant warmup the car reaches steady idle for about a second, which is plenty enough to get a steady, seamless loop.

    I did some preliminary work on a car radio, and remuxed a public domain song (and a couple commercial -- those I can't distribute ;-)) to have a high pass/lo-fi effect, but didn't link it directly to the script. It's not that it's difficult, but Starbound doesn't support server-side sound effects very well: for clients to hear a sound effect when the car enters range of them, the car has to restart the audio loop. Since that's just silly, I wasn't going to bother accommodating that, but I'm considering not even bothering with the radio at all, since it's also just pure glitz for something that I'd rather listen to in Winamp anyway. =P

    I recorded a video, but I wound up recording from a bordered window including my taskbar, which I want to fix -- either by recording a new video or by downscaling the cropped video to 720p. Trying to figure out Blender video editing has been an absolute pain. Blender has the obnoxious privilege of having a user interface designed by programmers who already know the semantic, esoteric meaning of every button on the screen, rather than using context menus and a single modal interface like every other human being on the planet, so I've been intending to try OpenShot instead. In any case, I'll see if I can't throw out a preview video today or this weekend at the latest.
     
    Last edited: Aug 24, 2018
  11. KejaWicks

    KejaWicks Void-Bound Voyager

  12. KejaWicks

    KejaWicks Void-Bound Voyager

Share This Page