Forum posts

In Half-Life 1, you'll find the player movement code in sources prefixed with pm_, as it stands for "player movement".
For example, pm_shared.cpp. There, you will see player movement for GoldSrc, which you'd have to adapt for your Source mod.

Also, what exact errors are you getting? Are you opening a single .cpp file then trying to compile it, or do you open the appropriate .sln (solution) file and then compile?

As for DLLs, you can't "explore" them, because they're compiled. For a beginner, let's just say they're executable, just like .exe, but you can't execute them directly. The SDK code is meant to compile new DLL files (client and server), so if you wanna know how some entities work, you would look at the source code in the Source SDK.
Alternatively, you can disassemble a DLL with some programs, but for someone who's new to programming and modding in general, let's not talk about them.

Bosnian village roads.
Also, an offroad variant:

"I tried coding, whatever I do, I can't get it to compile."

Which exact source code were you compiling, and what compiler did you use? Chances are, you used Visual Studio 2017's toolset on something that can't compile on anything after Visual Studio 6.0 from 1998. Or even something totally different, like Dev-C++ or Code::Blocks.

Precisely, that'd be FCVAR_ARCHIVE.
If the hud_color console variable doesn't have that flag enabled, it won't get saved. So, we'd have to look at the SOHL source code then. Think of hud.cpp or any place like that.

So, next up: physics.You might notice that the boxes clip into the floor by approximately 1 or 2 units. That's because I currently don't have a proper thing for map collision. Instead, I made a phys_staticplane to prevent the boxes from falling through what we see as the floor.
I'll resort to an external mesh for this type of stuff. Reading geometry from the BSP is cool and all that, but what if we want a separate physics mesh for the map? Eh?
As of right now, the system goes like this:

mapname.bsp - actual map
mapname.bsp.obj - .obj model file made from an exported .map file. It's easy to do with tools like Crafty or Noesis or whatever you use.

However, I might end up writing a tool that reads a .map file and just converts the thing to .obj. It'd be kinda cool to add new stuff to my mapping workflow. (or whoever ends up working on the mod, or using the mod base)
Obviously, I'm not planning to replace GoldSrc's physics anyhow. Just adding special physics entities on top of the whole thing. And NO, no ragdolls. I know I'm crazy, but not THAT crazy.

Of course, maps will have the option to have or not have physics. It's as simple as that. Vehicles may or may not require physics. I'll have to see about that at some point. Probably not though!

Either way, currently I'm juggling through pointer hell, because there seems to be some stuff about the map collision mesh. Pretty sure it's a null pointer somewhere. Read access violations can be a beach. (you know what I really wanted to say)
bvtBvhTriangleMeshShape is being used. Though I guess I just need to read the documentation a bit more.

Pretty much that. ^
Log to the console whenever you can or are having trouble.

Sometimes you can also use a debugger, for stuff that goes too fast or is too complicated to track via the console. (e.g. buncha nested for loops or a dozen variables you gotta keep tracking)

Well, something could be done about that too, though I can't say much right now.

I used the number 1 because each "finger" has two bones: its own bone, and its child bone. Each finger attaches itself to a child bone.
So I was thinking of a chain, where each finger has a parent and a child. Finger A is the parent, finger B is the child, but a parent to finger C, for example.However, of course, you can easily achieve a swarm like what you said. In theory, at least.
It'd look something like this:At least the way I imagined it.

I think you'd still have to change the angles, but nonetheless, it'd be a really flexible system where you can detach a group from the parent to have its own AI, for example.

Also, LOL, yeah, I learn fast when I'm panicking for my future. I've been learning programming since 2015, I just had a chance to start doing it practically last year.

There we go:For example, you could make a "chain" of entities that attach to each bone.
Those entities could use the 'target' as the parent bone entity.

What this means is, you would do something like this:

CBaseEntity *pParent = UTIL_FindEntityByTargetname( NULL, STRING( pev->target ) );

GET_BONE_POSITION( ENT( pParent->pev ), 1, pev->origin, pev->angles );
UTIL_SetOrigin( pev, pev->origin );

This is the most basic way. Of course, there would have to be more checks, and stuff.
For example, you can write the entity class to have m_pParent instead of allocating it in the Think() function every time.
A think function is required for the entity to update its position fast enough, basically, or else it'll appear choppy.

So here's what you could do: (alert: this isn't the finished code, it needs some extra security checks to avoid crashing etc.)

CAbbadonChain::SpawnThink( void )
{
    m_pParent = UTIL_FindEntityByTargetname( NULL, STRING( pev->target ) ); // find our target

    SetThink( &CAbbadonChain::Think ); // we've spawnthought, now it's time to attach to the bones
    pev->nextthink = gpGlobals->time + 0.1;
}

CAbbadonChain::Think( void )
{
    GET_BONE_POSITION( ENT( m_pParent->pev ), 1, pev->origin, pev->angles );
    UTIL_SetOrigin( pev, pev->origin ); // to make me physically move to that origin, after I've visually moved there

   pev->nextthink = gpGlobals->time + 0.01;
}

And of course, somewhere in the Spawn() function, you'll SetThink( &CAbbadonChain::SpawnThink ); and maybe pev->flags ^= FL_ALWAYSTHINK; if you want your entity to think every frame.
Don't forget to put EXPORT in the declarations too:

void EXPORT SpawnThink( void );
void EXPORT Think( void );

Lastly, remember that this method might be a little bit network performance unfriendly, because you're now managing 3 or more entities instead of just 1. But if it's a singleplayer mod, then go for it.

I'm surprised you haven't heard of this one before.

Basically, you can use a certain macro that calls an engine function, to attach stuff to a bone, or attachment if you use that. I'll post more about it when I wake up, as it's currently very late at my place. xd

You can always attach stuff to bones, though. Either via attachments or directly attaching to a bone.

Yes.

I had a fascinating playtest session with my brother last night. The vehicles work rather well in multiplayer. So yeah, vehicle deathmatch is definitely gonna be a thing. Sure, it's never gonna be as smooth as it is in singleplayer, but the vehicles are very driveable.

Originally, I was going to do a simulation for cars, but hey, this is an action comedy type of thing (apart from the other characteristics of the mod). So I'll do a bit of more liberal car physics. Think of GTA: San Andreas for reference.

I could do what Gran Turismo 1 & 2 did, which is having a separate mode for arcade and simulation driving, though that's pretty much 2x more work. On top of that, you gotta remember that racing sims use really high-poly tracks so that they're smooth enough for the simulation to be accurate. It'd require QUITE some clipnodes for that. Unless I use Bullet for the simulation mode, where I could easily use the external physics mesh.

Hmm... for now, let's just stick to GTA:SA style arcade driving. Also, for the sake of network performance, I'll have to ditch the idea of assembling a car out of different pieces. I mean, let's take into account a veh_car_base, with 4 veh_wheel entities, and a player in the car. That's 6 whole entities! That means it'll take 3x more origin and angles sets. According to my calculations, that's 96 bytes + vehicle itself + the player = 144 bytes total. (only taking into account sending the floats in pev->origin and pev->angles).
Now, sure, I'll keep all the functionality, but for MP maps, you're just gonna have to use 'whole' vehicles if you want better network performance.

For the entire picture, here's the plan:

• veh_car - car entity that supports all kinds of parameters set by the mapper: model, seat number, engine characteristics etc. Only potential issue with this entity is the fact that this is gonna take up quite some data in the entity lump. There are gonna be many parameters to be defined, most of which should have default values, however.
• veh_car_base - car entity that "assembles". You attach other entities onto it so it can become drivable. (implemented)
• veh_[insert a real-world car name] - a preset car entity. For example, veh_yugo - acts like a Yugo 45, looks like a Yugo 45, drives like a Yugo 45.
• veh_base - the original drivable chair entity. (implemented)
• veh_base_ms - the original drivable couch, multi-seated entity. These two might get removed or renamed. (implemented)
• veh_seat - a seat that you can place. This would be a normal chair that you can sit on. No driving. By itself, it's actually an invisible point entity, and yes, you can use it to attach to veh_car_base. (implemented)
• veh_wheel - a wheel. By itself, it does nothing. Naturally, it might roll away if it's on a slope. In a veh_car_base, it'll act like it's supposed to. (implemented)

Now, if we go a bit farther into the future:

• veh_tank - self-explanatory.
• veh_boat - regular boat. You can choose it to be a motorised boat or a boat that you row, which you'd have to use a special weapon for.
• veh_boatmg - boat with a mounted machine gun on it. Motorised by default, but you can also choose to row it.
• veh_sub - a submarine type of vehicle. Moves only under water, and players in it won't drown.
• veh_heli - a helicopter type of vehicle. W and S control it vertically, while A and D rotate it left-right. To steer left, for example, you'd have to pull your mouse to the left, rolling the helicopter left. Then you'd push the mouse backward (or forward) to tilt the helicopter up. Think of it as a joystick.
• veh_plane - an airplane type of vehicle. Controls are just like the helicopter's.
• veh_ufo - imagine the submarine, but in the air. It's basically not affected by gravity. It's controlled like a helicopter.
• veh_sship - a spaceship type of vehicle. It's controlled like a plane, except it isn't affected by gravity.
• veh_bike - a bicycle or motorcycle type of vehicle, depending on the mode. Just like the boat, it can be motorised (hence it acts like a motorcycle), or it can be powered by cycling, which would act rather similarly to GTA:SA. If you hold W down, it's cycled normally. If you tap W fast, you'll cycle faster.

Lastly, imagine almost all of them with "mg" variants. There would be some sort of weapon, either a machine gun type, laser type, or rocket launching type. Now, of course, you'll be able to choose whether the vehicle will have the driver as the gunner (like in HL2 when you use the airboat, or the buggy), or if you'd rather have a separate seat for the driver and the gunner.
In the far future, we might have NPCs that drive vehicles, and, heck, even ride-able NPCs. Imagine riding a Gargantua, LOL.

You might be asking, why all of this? Will all of them be used in UAS? Not all in the singleplayer campaign. Vehicles that the SP campaign doesn't utilise can be found in some of the MP maps, as well as minigames, which are accessible in singleplayer. However, keep in mind that this is not only a SP-MP mod, but also a mod base which others could use in the future. :3 (the 'base' can be downloaded separately)

Anyway, I mentioned rowing a boat. A row would not be a weapon in this case. This mod's gonna have 'tools', which are basically weapons but instead of damaging entities, they provide certain functionality with them.
The most obvious example is a paddle tool to row a non-motorised boat. Of course, it can be used as a melee weapon. Some tools can double as weapons.
Other tools will include:

• Worldcraft WC2.0 (original) - yes, a multimetre. You'll have to measure electricity in the mod at some point. You'll see why. If you don't mind the spoilers, I'll tell ya right away.
• Lockpick. This is pretty self-explanatory.
• Rock. To distract enemies a la Far Cry 1.
• Car keys. Logically, to start a car, you need its keys. Either that, or try jump-starting the engine, which is gonna take longer.
• Phone. You heard it right. A phone is going to be quite useful in the mod. Organise actions in missions, call people, and whatnot. Unlike GTA, however, you'll have to charge it wherever you find a power source. Some sockets won't have voltage in them, and you'll use your trusty WC2.0 to check if they have them. But don't worry, the battery should last long enough.
• Universal Remote. Simply put, imagine controlling a little rocket launcher from the distance, or a mini RC car.
• Grappling hook. Very good for setting up a rope to the top of a tower. Or if you wanna do bungee jumping. However, don't let someone shoot it. It has its counterpart.
• Climbing axes. You can climb walls with ease.
• Parachute. Self explanatory.

There's more stuff than this, but I don't want to count all of them. Now, you might say that's a lot. And you're right. But you can't carry it all at once. Well, you can, but you'd be VERY slow. Items, tools and weapons will have their own masses, and the greater the mass, the bigger the slowdown will be.

Since you mentioned epolys, you could flip EF_NODRAW in pev->effects.
The entity will remain in the memory, and it will "live", but it shouldn't be rendered, so you can use the same one again.

However, if you want to remove them from memory, just kill them.

That place is amazing. uwu

I was thinking of a more primitive one at first, then you pick up, or upgrade to a compound bow later. And of course, there will be different types of arrows.

FMOD now works.

Long story short, now I can play music with it. There's a special "music" folder inside the mod folder, so when you use a sound name like "abcd.ogg" in a music entity's keyvalues, it'll look for modfolder/music/abcd.ogg
Also, the DLL file is now in cl_dlls, instead of the Half-Life directory! Yay! (big thanks to Solokiller)

Currently, it works by sending a user message with a string. What this means is, it would be very far from optimal when it comes to network performance. So for entities that emit sound, like monsters, breakables etc., that would be a lot of bandwidth. So I'm thinking about replacing a variable number of bytes with just 2. Up to 65535 sounds should be able to be precached per map, cuz' c'mon, who's gonna precache more than that in a GoldSrc mod? Sheesh.
Now, I believe that I could stick to sending strings for music entities, as long as short filenames are used. But then again, 65k is more than enough IMO, so I guess music could go to the "sound cache" as well.

Now, something more conceptual, that I haven't started working on yet.
Do you like bows in games? I personally do, especially the one in Crysis 3. ^^
I think a lot of cool puzzles could be made for it. There will be a jungle area where the player is alone most of the time, so it'd be pretty nice to have that instead of firearms.

Man, man, what a fool I was.

"The FMOD implementation is so-so. It loads the library, starts the system, creates and loads a sound, but fails to play it."

When I tried to do FMOD, I was doing it upside down.

I tried implementing it on the server side. XD
The sound entity would basically directly call FMOD's sound playing functions. Horrid. D:

It'd look something like this:

void CNewSound::Use( CBaseEntity *pActivator, CBaseEntity *pCaller, USE_TYPE useType, float value )
{
    g_SoundSystem.PlaySound( m_sound );
}
// where m_sound is a member variable of this sound entity

// meanwhile PlaySound is defined as:
void CSoundSystem::PlaySound( FMOD::Sound *snd )
{
    result = system->playSound( snd, NULL, 0, NULL );
    ERRCHECK( result );

    result = system->update();
    ERRCHECK( result );
}

Something like that. Point is, this is entirely server side.
Yes. I was an idiot. Laugh at me as much as you want.
Gonna quote Shepard on this one: "My god! What are you doing?"
Back then though, I didn't quite know how to do client messages yet. Now that I do, though, I might as well try it the proper way.

For now, I'm planning to do a simple "music player" on the clientside, then I'll try to do more than that. FMOD Studio seems really pretty.

Also, in DevVideo 3, I mentioned some stuff about bounding boxes and vehicles. TL;DR you can't rotate an AABB with pev->angles properly. But, a friend told me about a special model flag, that's used by monster_tentacle, which essentially uses hitboxes for collision. Mmm, definitely seems better than AABB, even though I'm pretty sure this will have its own flaws too. But I'm more willing to accept those flaws than the ones of AABB.

Also, something I haven't shown in the video, but probably have shown here (or not?), physics.
Here's a link. The Bullet physics engine integration is going fine enough. Just gotta set up some debugging lines so I can see my collision shapes. Stuff seems somewhat off already.

"Goldsource is quite robust and there is no need to stick to the terribly outdated WorldCraft 2.0 prefabs."

Pretty much. ^

The GitHub repo there contains the source code, at least. So if there are no DLLs, one can always compile them manually.

If you don't know how, I could do it if you want.

As I said, AK47nator, there's a map file that contains each WorldCraft prefab, so you can just select a group of brushes, copy, go back into your map, and paste. uwu

Personally though, as I'm trying to be outside of HL's universe as much as possible, I got no use of the vanilla prefabs.

Therefore, if you wanna compensate for the lack of prefab libraries, make a separate folder called "Prefabs" and save map files there that only contain prefabs.

Prefabs are for pussies. Lol.
There are, however, all of the WC prefabs packed together in a single .map file somewhere, so you can just copy them into your map.

Once I'm done with the brushwork, I'll definitely have to make some textures for this stuff.

J.A.C.K., VHLT v34 (Vluzacn's Half-Life Tools), and HL Texture Tools.

J.A.C.K. provides a nice set of features:Direction arrows for light_spot, light_environment and other entities that need such a thing, faithful model rendering, long file path support (Hammer never liked paths with spaces or ones that were too long, no more need to store stuff in C:/Hammer ), a much more comfortable-to-use Vertex Manipulation tool that now finally selects all parallel vertices when you try to select multiple ones with a single click, still runs on my 2005 HP Compaq yadda yadda yadda.
It's free, the paid version on Steam is... not something you'd wanna invest into right now. It's on hlfx.ru somewhere. Here, to be exact.

Either way, it has less quirks than Hammer. One of the quirks is to install J.A.C.K. somewhere NOT in Program Files or Program Files (x86) because it then wouldn't be able to write to its config files. Otherwise, should work just fine and peachy.

Vluzacn's fork of ZHLT, called VHLT, latest version being v34, is the state-of-the-art set of compilers for GoldSrc mapping. Basically, CSG, BSP and VIS are much faster, RAD takes a bit longer but delivers more beautiful lighting. It has func_detail, which is often useful if you've used func_wall a lot for small props and whatnot, though this feature has been available for a while, I believe. Same thing goes for ZHLT 2.x era light flags, where "blue" masked textures can cast shadows.HL Texture Tools is pretty straightforward for WAD and sprite creation. WADs are standard, you just gotta have 8-bit BMPs, and in the case of masked textures, appropriate colour palettes. HL Texture Tools with sprites also allows you to easily change their orientation settings, something that can be pretty useful if you want 'fixed' sprites that don't face the player, but rather only a specific direction:Welcome back to the glorious mapping land. ^^

Oh wow.
Nice.

Well, it's both fortunate and sad. Fortunate because now you can make HUGE maps.
Sad because it's gonna be a lot more complex, buuut, it's UE4 after all.

Keep going, mate.

Well then, for that matter, I'm gonna use my phone for the review.

"I didnt even know Wally could do that."

Since when? I don't remember Wally having a feature like that. Though there's this program called AutoSeamer that I once used in 2015. (it's not really good, lol)

"But if you are more experienced one, just use Wally."

Or HL Texture Tools.

Personally, I don't like the idea of web apps, but hey, it's really good for beginners who wanna make a WAD real quick. I will post a review sometime soon.

Been using a knife since I was 8. Did quite some things with it, accidentally cut myself quite a few times, but never badly.
Live your life, just don't live it fast.

But this is fun! I'm only 17, I wanna have fun before real life catches up. Besides, this thing is now off my bucket list, probably won't attempt it again.

Edit: Also, it was just one neighbour. I was basically showing this stuff off to my cousins and other kids in the village. I wanted them to see it once in their life.

sigh

Good thing Mum didn't find out, lol. I would've done it again, but... the neighbours found out and told me to not do it again. D:

Remember that talk about guns we had a couple of years ago?

Today I tried a homemade "flamethrower".As calm as I usually am, I like being crazy too sometimes. :3

It looks nice. :3

"I don't even know if it's free cause the one I had is a trial version."

Visual Studio Community Edition is free.
You only need a free Microsoft account to unlock the trial.

When I used Visual Studio 2010 Express, it actually had a trial which required an activation key, but all I had to do was create a MS account to get access to the key.

Looks like...
SoHL but for HL2? COOL!

Edit: Just watched the entire thing. Yep. It's A M A Z I N G for Source mappers.
I seriously hope it won't have many bugs.

P.S. it's not a set of tools (Hammer, compiling tools etc.), but rather new and improved entities.

Update time.

New features:

• trigger_date, an entity that can only trigger something whether the actual date matches the entity's properties (e.g. you trigger something every Christmas)
• trigger_date2, an entity like trigger_date, except for hours, minutes and seconds (3 AM horrors :D)
• func_loadbar, an entity that moves in a direction, and loads from 0 to 100%, has 5 trigger-able percentage levels defined by the mapper (e.g. trigger a "Just a little more!" sound when it reaches 90%)
• view bobbing + view camera overhaul
• horizontal offset of the thirdperson camera
• temporarily broke func_rotating
• trigger_timer, triggers something periodically, can trigger randomly between a min and max interval as well
• car prototype, with a working gearbox, needs steering implemented
• actual physics test - it's possible now
• new main menu UI colours

Physics test

I always wanted to say this:

In collaboration with Trempler and AlexCorruptor:What an honour this is.

Very, very surprising. Much better than I thought.

On average, there are 900-1300 wpolys, in some areas they're as low as 400 wpolys. In the worst case (only on one spot), almost 3000 wpolys. I'm getting 400 fps on my GTX 1050 Ti PC there.
The epolys, while playing alone, vary from 3k to 5k - take into consideration the giant cliffs, sand, rocks ("3D skybox") and the helicopter. The heli itself is probably about a 1000 tris, and the outer, inaccessible terrain model is about 1600 tris.

I'll test it on my 2007 laptop, because these numbers seem pretty good.

The map takes a while to compile, especially VIS, but with terrain like this, eh, I'm glad it compiles. This super open design needs at least about, I dunno, 30 minutes of VIS (with -full), but it's worth it. You cannot really optimise it further unless you turn it into some sort of maze.

ts_untergrund2019 is almost ready.

Me: Hey GoldSrc, will you open this map for me, pretty pleas-
GoldSrc: NO! NOOOOOOO! GET AWAY FROM ME! YOU MONSTER! YOU WILL KILL MEEEE!!! jumps and kicks all over the place
Me: It won't hurt, I promise. Come on... :3
GoldSrc: sigh Fiiiine. loads the map Holy hell, I never knew I can take so much. >-<

This is ts_untergrund. I'm finishing it this summer and it'll be released. I promise.

But then again, I haven't even tested what I proposed, so no-one knows if it's gonna really work.

All of this is just preparation, I believe. This is why I'm writing everything down. I need priorities. Back in 2015, I only had a rough idea and I was making things up as I was going. That clearly led to nowhere with potentially large projects like that.
The year after, I started working on a Far Cry mod that would act as a 'sequel' to this one, that failed in 2015. That is where I discovered the concept of planning.

The few rules I came up with were to first write some documentation, then develop and implement features. Only then, once those two are done, I can do the actual content (that is most of the assets). This is the principle I'm working by, and it's the reason why a relatively smaller project like de_kobbl managed to succeed, and I even managed to pile together a whole game demo in 2 months, mostly from scratch.

The difference is, this time I'm focusing a lot more on the 1st part, the documentation. And that involves planning, alongside everything else (the descriptions, the story, the missions, the designs). And this time, I'm not alone, unlike before.

Thanks a lot for reading, and for what you said. I know I've got a long way to go.

That would work too, but would require many path_corners for very precise fills.
Also, how would you handle the button that fills the bar more than the other buttons?

I realised that I should perhaps write things down. My mod failed in 2015-2016 because I didn't write almost anything. Seriously.
So I am trying to do something about it.Later on, I'll have to write a list of core features, then the actual story, individual missions, short mod design document and then I got a plan to stick to.

My teammate made a significant addition, having thought of a new character, which will definitely make the mod's story more interesting. (and for the player to care about and become allies with )

As for the vehicle system, I got a CBaseCar class now, with a different movement algorithm. I haven't yet tested it in-game, but it compiles fine. The vehicle engine is now more complete, with functions for acceleration, toggling etc., wheels now have a part of their own logic, and the vehicle manifests all that together.
The plan is to make a NEW test model because CBaseCar handles bones differently. It takes into account the root bone (that is bone 0), followed by potentially 4 wheel bones, so that's an offset of 5 bones. Therefore bones 5 and 6 will be driver and passenger, in this test model.
The model will actually be a bath tub, cuz' why not.

@zeeba-G
Thank you.

Here are some of the others:

I remember a map that had something similar.

My idea is a high-speed func_train, that stops itself automatically after either 0.05 seconds or 0.10 seconds, depending on the button.
More the time, the more distance the bar will travel.

Now, the way this would be done is not hard, I believe.
You've essentially got 3 main entities: a func_train and two func_buttons. Then you've got peripheral entities that do the logic: two multi_managers and two trigger_relays.

A func_button will trigger a multi_manager, which triggers the train, and the relay. The relay will, after 0.05 seconds, trigger the train, making it stop.
Another func_button will trigger a different multi_manager, which triggers the train, as usual, but this time, a different relay (the one with a 0.10 secs delay).

Essentially, what happens is the following:
If you press button A, the train will start moving, and stop moving after 0.05 seconds and move, say, 8 units. It'll give an effect that you are filling the progress bar with each press.
If you press button B, the train will start moving, and stop moving after 0.10 seconds, and move 16 units. Same effect, but with a bigger fill.

The func_train will have a set of 2 path_corners, and once it reaches the last one, it will halt, and it can then trigger something the moment it hits the end.

Early compile! And it runs like a charm. 4.5k wpolys max, averaging around 2k on the outdoors, and less than 1k on the indoors.
I'll try to reduce these numbers. Oh yeah, definitely.

Next thing to do would be to detail the indoors, and then I'll make the vegetation for the outdoor areas.

Any chance you could be more specific? ^^I'm assuming it's this one. But yeah, it'll probably get converted to a texture during the "great optimisation" phase.

Whew, this one will need AlexCorruptor levels of optimisation to get running on a 2007 laptop. But I can do it. I HAVE THE POWER.

You said "I don't know".
The moment you say "yes", then we're talking.

The new member I mentioned is someone I met a few weeks ago, they were interested in the mod, willing to work on it, contributing to the story and sharing their ideas (proposed a few vehicles, added a new character too, massively improved the plot and gave more sense to it). They make me happy.