a9902957@nepwk.com wrote: ↑Sun Jul 24, 2022 8:24 am
"Fix support for bot attitude in different game modes"
Sweet, when I played HolyWars and MushMatch I had the hunch that some(?) vehicles made 'em
aggro too much against some bad choices.
Thanks for all your work on this! Same to Feralidragon before you!
Man riding shotgun on top of the Heli (you better not get dizzy from spinning lol, nice one) or Manta is fun.
This screams for a BotChatCommand extension for issuing a bot order to disembark/eject from a vehicle (or to "deliver" a vehicle
to a certain spot).
https://unrealadmin.org/forums/archive/ ... 31029.html http://www.ut-files.com/index.php?dir=Mods/
Tacticool gaming options on big maps with gametype objectives.
If you do another release Manta projectiles getting some light-emitting effects would be sweet (dynamic lights performance drain, but not lighting up pitch black areas looks weird).
Sadly, there are still some complications with using MushMatch with XVehicles.
For one, TraceIdentity (the ability to see one's name and other details when looking at them) doesn't look when looking at someone from inside a vehicle, even though it works from people outside the vehicle when they are looking at you. This is the only thing I think I can blame XVehicles for.
Also, Sporifier spore shot and suspicion beacons can't get to people behind vehicles, making it impossible to use these mechanics on them – which is to be expected for an infectious liquid, but maybe not the beacons!
Also, bots in vehicles don't leave the vehicles to use the suspicion beacon or sporifier. This is not a large problem, since they might as well kill the person anyway, but can lead to issues.
Also, since CanSee is used when judging whether someone is fit for being suspected on, I'm pretty sure bots can't suspect on you if you shoot humans from inside a vehicle.
Of course, most of those can be fixed from within Mush Match.
It would be nice if X-Vehicles provided an API for being able to configure some XV behaivour that could be implemented by the gametype author as a subclass. For example, Mush Match would disable the team icons and colours on the vehicles, and, perhaps, would allow multiple vehicles to spawn in the map—or at the very least make an unused vehicle last substantially longer to respawn in original position.
This wallaby has been through the code jungle enough times that he knows to always be prepared each times he makes a trek through it. He always sprays the anti-mosquito lotion, fills his backpack with what would seem like an excessive amount of water bottles to someone with less experience, and puts on his best pair of programmer socks.
(And no, he's not trans. Yet, anyway.)
The UnrealScript object-oriented API is certainly appealing at first glance, especially when compared to Quake's purely procedural QuakeC approach, let alone Doom's state machines. But what it has aplenty in accessibility, it lacks in flexibility and performance. Composition will trump inheritance most of the time when it comes to healthy software design, and video game logic is no exception.
In fact, it's a pretty big reason behind paradigms like Entity-Component-System, which have challenged the king of the hill, object-oriented programming, due to its inherent extensibility, flexibility, and performance.
Unfortunately, as we all know, Unreal Tournament predates the very concept of ECS itself by at least half a decade, and even when it first came around, it was developed for real-time strategy games, with thousands—nay, millions!—of tiny little units marching across the screen.
And there is no good way, or reason, to cram ECS into the engine. Either you make an ECS engine that is completely on top of from the game itself, in either UnrealScript or native, which would be very awkward (and probably just result in many Actors being spawned and moved around by the ECS driver used, slow at best and buggy at worst!), or you replace the core UnrealVM with an ECS engine and try to shoehorn existing classes—
and support for existing mods, mind you!—into it, which... is just unfeasible, I mean, come on.
Why do I say all that?
Well, mod interoperability is very difficult to accomplish with a simple, inheritance-oriented extension structure, like the one we see in UT. And we can't blame the mod authors, since to implement proper universal interoperability, they'd either need a time machine, or to have tried (and understand the innards of) every mod that has ever existed for UT... or, really, both.
Luckily, there are many ways to achieve composition from within the object-oriented paradigm.
The main one is
interfaces – a sort of standard, or 'concession', for common kinds of access that an object of a certain type should provide. For example, all classes which are animals, instead of subclassing
Pawn, could provide (implement) an
Animal interface. It'd include things such as
PlayIdleSound and so.
UnrealScript has something similar to that, in which there are
abstract classes meant to represent a common kind of thing (like a Pawn or a Pickup), including "abstract functions", which subclasses are supposed to provide their own versions of. For example, the Shock Rifle's version of the
Weapon.AltFire function at some point fires a round bolt of plasma.
In languages like Java (which USc was heavily inspired by), however, those interfaces can often be separate from the ancestry of classes which implement them. A Class can implement an Interface without being a subclass of that Interface, or otherwise related at all. UnrealScript sadly lacks a native alternative, but there are certainly workarounds for that.
An abstract class can be subclassed, then used by a class outside the abstract class's hierarchy. For example, we could have a mod that implements temperature, and an abstract class '
ThermalDescriptor', with a subclass for each kind of tangible object – from animals to bots, to weapons, and possibly map-specific subclasses for each ZoneInfo. Then it'd have a static function with the purpose of iterating over every matching actor.
I wonder how this could help with mod interoperability for our thing here.
