site banner

The Motte Moddes: HighSpace (October 2023)

The goal of this thread is to coordinate development on our project codenamed HighSpace - a mod for Freespace 2 that will be a mashup between it and High Fleet. A description of how the mechanics of the two games could be combined is available in the first thread.

Who we have

I hope you don't mind I moved you to Consultants for now, @netstack. I'm always torn between keeping people in their originally declared roles as encouragement, and not wanting to harass them into contributing, when writing the contributor list. I'll be more than happy to re-add you as a dev if you're still on board.

Who we need

The more the merrier, you are free to join in any capacity you wish! I can already identify a few distinct tasks for each position that we could split the work into

  • developers: “mission” code, “strategic” system map code

  • artists: 2D (user interface), 3D (space ships, weapons explosions)

  • writers: worldbuilding/lore, quests, characters

A small note if you want to contribute:

Don't be afraid to ask questions however small, or silly you might find them. This is literally one of the primary functions this thread has. The Hard Light documentation is... there... but it's not great, and between that, the peculiarities of LUA, the FS2 scripting API, RocketLib, and other parts of FS2 modding, it really might not be obvious how to resolve issues you run into. I might not be able to answer all questions, but I've dabbled in all these things, so there's good chances I might be able to help.

What we have

  1. Capital ships

  2. Fighters

  3. A cruiser, loaded in-game

  4. Turntable render for a cruiser

  5. Turntable render for a destroyer

  • A proof of concenpt for “strategic” system map we jump into on start of the campaign. It contains a friendly ship and 2 enemy ships, you can chose where to move / which enemy ship to attack.

  • A “tactical” RTS-like in-mission view where you can give commands to your ships.

  • A somewhat actual-game-like workflow. Attacking a ship launches a mission where the two ships are pitted against each other. If you win, the current health of your ship is saved, and you can launch the second attack. If you clean up the map you are greeted with a “You Win” message, or “You Lose” if you lose your ship.

Updates

It was another slow month, but things are finally starting to move. Literally. I added a current time display (set to the very beginning of the universe for now), and time can be paused / started / fast-forwarded. I also added a side bar with some help text (I thought the controls were relatively obvious, only to realize that what seemed obvious depended on the game I was most recently playing). The planets are the only things that move on their own for now, but I should be able to extend that feature to ships pretty soon. I'm not sure if this idea will go anywhere, but I'm thinking of having ships be able to move through conventional and subspace drives, the former obviously only being useful for planet-moon type distances.

Other than that I spent a lot of time optimizing. Brute-forcing my way through "find me the ship under the mouse cursor" was fine for a proof-of-concept, but I was finding myself making more and more "get me the nearest X" queries, so it was time to shove everything into a spatial index. I'm quite happy with the result, but it's not really something you can show off visually (well, unless you really want to).

What's next

  • Getting the ships to move along an orbit.

  • Real-time ship movement (sub-space, and conventional)

  • Obstacle mechanics for the planets

5
Jump in the discussion.

No email address required.

@ArjinFerman - Integrating ships turned into a bit of a rabbit hole, and then I had a bunch of personal nonsense the last week and a half. Plus my laptop died. I'm working on rebuilding the sandbox mod I was using for integration testing before, but in the meantime, I figured we could talk ship creation workflow, and what's involved.

On the art side, ultimately, I'm going to need to do finished models, normal baking and a full texture pass, LODs, debris, shield and thruster geometry, turrets, etc, etc. for each ship, and then we need a custom table entry, and probably custom weapons too. All of that is going to take a while, though, and in the meantime I'd like to get simpler versions of the ships in for testing and evaluation purposes, so we can actually see and shoot at them. So what's actually needed for a simple implementation?

I've pushed a frigate .pof file to my repository; it's got the hull and four turrets, and the turrets have firing points. I'm pretty sure the textures didn't make it into the file, since it's not stored in a proper hierarchy, but I'll fix that shortly. My question is, can you give me a list of what you need set up on my end to be able to drop ships into the mod on your end? I'd like to get all the current hulls ready for integration with at least basic textures and weapon setups if possible. Or if there's a better way to handle all this, I'm open to guidance.

Also, is there a way to do fixed guns on capital ships? do you just make a turret with no rotation?

I'm pretty sure the textures didn't make it into the file, since it's not stored in a proper hierarchy, but I'll fix that shortly

I only dabbled in them a little bit, but I think pof files only has store a reference to the texture. When I first imported one of your models into the game, I slapped a vanilla FS texture on it, and I did that by adding a .dds file in the 'maps' folder, that had the same name as the texture in the model. Seems like the docs are saying the same thing:

Contents: All the textures used by 3D *.POF models. *.POF models use textures to "paint" their surfaces and to simulate glow points. *.POF files only have links to the names of their used textures, they don't have embedded textures. All their used textures are read from this folder.


My question is, can you give me a list of what you need set up on my end to be able to drop ships into the mod on your end?

For me the .POF models and .DDS textures are enough, I'm happy to handle the ships and weapons tables (well, to start I'd just use vanilla weapons).

Also, is there a way to do fixed guns on capital ships? do you just make a turret with no rotation?

I'll need to look into how it's normally done, but I think so. Most guns in FS2 seem to be just fixed "exit points", they're not even particularly gun shaped. Everything I read up on (modelling, turret setup, animation code) seems to indicate that fixed turrets are the default, and animated ones is what takes additional setup.

.POF of the escort Cruiser is pushed up, along with flatcolor maps for the hull and turrets. If you have trouble attaching the maps for the gunship frigate, let me know; I think I figured out something on the workflow on this one: you need to rename the materials on the meshes in blender if you want them to transfer to POFtools cleanly. I haven't confirmed whether it matters in FS2 or not, but if it does I'll re-export that one.

I figured out something on the workflow on this one: you need to rename the materials on the meshes in blender if you want them to transfer to POFtools cleanly.

Yeah, I imported the frigate and ran into this problem too. The material names were different from the file names of the textures you pushed. There was also a default_obj texture the game was expecting.

I also wanted to test the turrets but I didn't have time yet. I'll try to give an update later today.

fixed version of the frigate POF is pushed up. I also pushed up a POF and map for one of the destroyers.

Nice!

Again, I only checked the frigate so far, the default_obj texture is no longer required, but there still seems to be an issue with the file names. The file is called frigate_gunship01_MAP.dds, but the game expects frigate_gunship01.dds:

WARNING: "Couldn't open texture 'frigate_gunship01' referenced by model 'frigate_gunship02.pof'

Also this isn't very important at the moment, but can we keep the filenames lower case for consistency? You might also need to rebase your branch once we merge your models to master, to keep the directory structure consistent.