site banner
ArjinFerman  Tinfoil Gigachad  7mo ago (text post)   748 thread views

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
Top Bottom Old Controversial Comments
Jump in the discussion.

No email address required.

We now have Real-time ship movement, both sub-space and conventional.

Conventional-drive movement will require some extra work (for the AI, if nothing else) because a straight line isn't necessarily the quickest way to get somewhere, when the entire system is in motion (or maybe the solution is just more speed). On the other hand it looks like it opens some interesting possibilities. For example, if sub-space jumps can only be done away from gravity wells, planets would be partly a refuge offering you cover from long range sensors, but partly a trap where you might get cornered. It's hard to say if the idea pans out in practice, but I'd like to try it out.

This took way too long, but the simplified physics ended up being a bit counter-intuitive, and I had to come up with a solution that looked realistic-ish while still being simplified, but: you can now get caught in the orbit of another body as you move.

I also couldn't resist the temptation to add glowy bits to the frigate

@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.

Alright, I imported the models, they all seem to work!

There were no more issues with textures. The game seems to be case-insensitive when it comes to filenames, so I could even rename the files without modifying the models. Once you know what you're doing, the turret setup is pretty easy. Turns out that animated turrets are handled automatically by the engine, when you make them multipart. So if you want a fixed turret, the barrel will need to be defined as the base. I think the rotation / translation properties are there for non-turret animated subsystems (or, I guess you could attach a fixed turret to subsystem with animation code, if you want something more complex).

How were you thinking the guns on the Cruiser are supposed to work? Fully rotatable, or mostly forward facing?

The changes are in a development branch for now, but if you don't plan on making further changes or making more tests, I can merge them to master.

P.S.: I'm starting to think - wouldn't it make sense, as a matter of practicality, for these long thin ships to be able to fire backwards, so they can maximize the amount of time the enemy is under fire before they close in?

P.S.: I'm starting to think - wouldn't it make sense, as a matter of practicality, for these long thin ships to be able to fire backwards, so they can maximize the amount of time the enemy is under fire before they close in?

Forgot to respond to this part. What's the scenario you have in mind here? Like, burning at max speed away from pursuers, firing on them as they close? This used to be a preferred defensive tactic when I was playing gun-navy games like navyfield or World of Warships, but I think it's a bit more problematic in space.

The short version is that we can do it, but there's some moderate-to-serious tradeoffs, and I'm not sure how worthwhile it would be as a tactic, either gameplay-wise or fluff-wise, without a clearer idea of how FTL and the other ship mechanics work.

The long version:

Tail-away from the enemy is a pretty disadvantaged position; if you're doing focused armor/defenses, the armor's probably mostly going to be up front, and all these designs so far have the drive and reactors in the back. Taking damage to either can take a ship out of the fight completely, so this is a pretty rough situation to be in, which means you want to get out of it as quickly as possible. If you're running, where are you running to? Playing for time, keeping the enemy at max range as long as possible? Trying to get the FTL charged/get to a jump point? Something else?

Superposition turrets can shoot "over the shoulder", so if you can burn mostly away and still bring a closing enemy under fire. This is going to involve trading space/time for firepower, whether you burn at angles to the enemy, or tack back and forth to alternate fire and acceleration, you're going to be getting less acceleration than if you just burned straight away, and probably cost you some firepower too as the maneuvering cuts into your guns' optimal cycle time.

The other option, depending on the scenario, would be to burn toward the enemy. You get your armor and full guns toward them, and you minimize the engagement time. The head-on engagement is going to suck, but if you make it past them you're continuing to accelerate while they have to decel, flip, and accelerate from scratch, which means you could open up enough space to break contact entirely, if your ship isn't absolutely swiss-cheesed in passing. Definately a high-risk option; short-range spaceship combat could very well be unsurvivably lethal.

Also, missiles and torpedoes don't mind this scenario at all; in fact, you could probably get a pretty decent weapon specialization out of torpedoes optimized for use against pursuing ships; you can use a much smaller drive, since the enemy is accelerating hard into them from relatively short range.

Anyhow, the basic problem with making full-360 turrets is that only one turret mounted on the highest point of a given hull surface can work this way. Turrets mounted in superposition block each other, any sort of external protrusion or superstructure gets in the way... there's no ideal way to do it, just tradeoffs. For the current cruiser in particular, the sides can't take turrets this way, because the external fuel tanks and other components stick out too much, so you're stuck with just the top and bottom surface for turret mounts. A couple options.

  • Use the current turret layout, but space the turrets out more to reduce the dead zone at the rear as much as possible, maybe to something like 30 degrees.

  • Use the current turret layout, but move the turrets up and back until the rear turret is high enough to clear all superstructure, allowing full rotation. move radars and other infrastructure to the sides... but then, at least fluff-wise, the sensors and guns have different blind spots, which is kinda annoying. meh.

  • Switch back to side-by-side turrets, move the turrets up and back until they clear everything. All four turrets can fire full salvoes in a 40 degree arc both ahead and behind, but broadsides can only use two turrets at a time. This is probably a better method than superposition since broadside engagements are the worst possible scenario in terms of survivability, but it still leaves the sensor problem at least from a fluff perspective.

  • Possibly do a "superturret", mount the turrets to a rotating assembly that can swing them around as a unit to face whichever direction? It'd be kind of a weird design, but weird designs can be interesting. I'm not sure I'd want all or even most capitals to use it as a core part of their philosophy, though. Alternatively, turrets mounted on tracks or on swing-out superstructure to allow them to adjust firing angle.

Hmm...

Anyhow, the basic problem with making full-360 turrets is that only one turret mounted on the highest point of a given hull surface can work this way.

The superfiring problem only arises if all the guns' primary rotation planes are the same, including the sign of the area vector. That is a required premise to get "you can't have gun A above gun B and also gun B above gun A" - if "up" means different things for each turret, it is indeed possible for gun A to be above gun B from gun A's point of view and gun B to be above gun A from gun B's point of view.

...If I'm understanding you correctly, this was what I was getting at with "a given hull surface". The current cruiser has a square cross-section, so you could do a set of superfiring turrets on each of the four sides, but only the back turret of each set would actually be fully reversible.

Seems I screwed up. Sorry. Carry on.

Like, burning at max speed away from pursuers, firing on them as they close? This used to be a preferred defensive tactic when I was playing gun-navy games like navyfield or World of Warships, but I think it's a bit more problematic in space.

Yes, exactly. I don't particularly like the idea of this tactic, but it just felt natural when I watched ships fighting it out. It felt particularly viable when a larger ship is pursued by a number of smaller faster ones, and tries to pick them off in order to be able to face the remaining ones.

Tail-away from the enemy is a pretty disadvantaged position; if you're doing focused armor/defenses, the armor's probably mostly going to be up front, and all these designs so far have the drive and reactors in the back.

On the other hand, I'm happy to leave it at that. Having an organic way to punish cowardice sounds great to me! Maybe with the exception of:

Trying to get the FTL charged/get to a jump point? Something else?

Yes, that's pretty much how FTL works according to FS lore:

  • You can jump out more or less instantaneously, unless your drive is charged, and hasn't been disabled.
  • Jumps discharge the drives, and require a recharge period after exit

So buying time for the drives to charge sounds like a valid use of the tactic. I like the idea of having the tradoffs you mentioned here. Maybe, with power management, it's better to redirect all power from the weapons to the enignes anyway. Maybe if you want to retreat you'll have to leave some of your ships behind, so they can buy time for the more valuable assets, etc.

Specific jump points are for interstellar travel, so I think the most common scenario involving these will be running blockades.

Also, missiles and torpedoes don't mind this scenario at all; in fact, you could probably get a pretty decent weapon specialization out of torpedoes optimized for use against pursuing ships; you can use a much smaller drive, since the enemy is accelerating hard into them from relatively short range.

Haven't thought of that, that sounds good.

Possibly do a "superturret", mount the turrets to a rotating assembly that can swing them around as a unit to face whichever direction? It'd be kind of a weird design, but weird designs can be interesting. I'm not sure I'd want all or even most capitals to use it as a core part of their philosophy, though. Alternatively, turrets mounted on tracks or on swing-out superstructure to allow them to adjust firing angle.

I love the idea, but I agree it should be limited to special ships. They'd also take more time to implement - we'd need to crack the animation code, and probably write a dedicated AI for them.

Alright, I imported the models, they all seem to work!

Heck yeah! ...I'm uncertain about the current flatcolor paint-jobs, but eh, they probably work for the moment.

How were you thinking the guns on the Cruiser are supposed to work? Fully rotatable, or mostly forward facing?

It looks like Freespace actually does allow you to set traverse and elevation limits separately. The cruiser's turrets are currently modelled to have a traverse of 142 degrees to either side of centerline, leaving a 76-degree dead zone where traversing further would run the gun barrels into the hull. Elevation range should be +40/-1. I swear, I am actually going to dig into POF tools more so I can actually handle the setup for these myself and free you up for more on the code end.

The changes are in a development branch for now, but if you don't plan on making further changes or making more tests, I can merge them to master.

Go ahead and merge to master, I'd say; I can make more changes if there's anything specific you'd like to see, but at the moment I figure the hulls are probably good for the moment. The major thing they're currently missing is the rest of the maps, but if I understand it correctly we can drop those in once I get them figured out.

I am planning on eventually doing a final pass on these, when we have all the components figured out and I'm doing finished, full-detail, fully-optimized and -mapped models.

For now, I guess the bigger question is what would you prefer the priority be on the art side?

  • Concepting more fighters and capital ships is my favorite thing to do, and I default to that when there's nothing more pressing. If you have a preference for more of either fighters/light craft or capitals, let me know. I'll try to get the chunky fighter concept loaded up sometime this next week so it's on-hand if we need it.

  • The existing hulls probably need additional components at some point. I have a file full of turret concepts, I've considered making destructible armor plate components, ships need debris and shield objects, shield meshes and so on.

  • Digging into the texture/mapping workflow for existing hulls, to improve the current cartoony visuals of the ships we have.

  • We probably need UI art at some point; is that point now?

In other news, I got a new laptop, and need to actually get the mod installed so I can see this stuff myself.

...I read the description you gave of a test scenario below, and it sounds quite excellent to me. Is there anything I can do on my end to help make it happen? Is that your current longer-term goal?

It looks like Freespace actually does allow you to set traverse and elevation limits separately. The cruiser's turrets are currently modelled to have a traverse of 142 degrees to either side of centerline, leaving a 76-degree dead zone where traversing further would run the gun barrels into the hull. Elevation range should be +40/-1.

Yeah, I saw that, but you also asked about fixed guns, so I wanted to ask what are these meant to be. I actually wish you could have the dead-zones be dependent on each other - in theory these turrets should be able to do a 360 rotation if the barrel is raised high enough.

Go ahead and merge to master, I'd say;

Done!

Since I started the project as a personal repository, but have since set up an organization, there's a bit of a mess that I think we should clean up. I think the easiest way to go about this is to rename your current repository on github to something like HighSpace-Backup, also rename your current local folder you've been working in, fork the org repo, clone the fork to your machine, and copy over any uncommitted changes to the new local folder. If you work on a repository that's marked as fork of the official one, you'll be able to create pull requests. I also sent you an invite to the organization itself, which should give you admin rights.

The directory structure has changed a little, so ships are in core/data/models, and textures are in core/data/maps. It might also make sense to work in a feature branch. Our work shouldn't conflict, but it's pretty annoying to have to resolve one, when you pull upstream changes.

For now, I guess the bigger question is what would you prefer the priority be on the art side?

Pretty much what you outlined, in exactly the order you listed. I'd reallyleave the UI art for last, I have a bunch of building blocks from other mods / vanilla, and they're perfectly fine to test things out. I expect we'll be changing the interface a lot anyway, as we add features, and figure out what info is useful for the player to see.

For ship models, I think it would be useful to add a few fighter types (1 of each for fighter / bomber/ interceptor maybe), then we can see how they interact with each other. The scenario will also require a freighter.

I swear, I am actually going to dig into POF tools more so I can actually handle the setup for these myself and free you up for more on the code end.

...I read the description you gave of a test scenario below, and it sounds quite excellent to me. Is there anything I can do on my end to help make it happen?

Heh, when I saw how much is involved in making a model and importing it into the game, originally I wanted to do something to free you up, but I have to admit, the more features I add, the more I have to keep track of, so I might have to take you up on that. After playing around with POF-Tools I think the import process shouldn't be so complicated, and tables aren't that hard to figure out either, once you get the hang of it. So if you're up for it, you can take the ship creation end-to-end, and I'll deal with the code.

If you want a working fully-featured example to reverse engineer how POF-Tools works, you can try this ship, there's a download link at the bottom, and you can just extract it, without having to also figure how deal with .vp packages. And of course if you get stuck on something let me know.

Is that your current longer-term goal?

Yes! Even longer term I'd love to do a full campaign, but let's see how long this scenario takes first.

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.

I've just pushed up flat-color textures for the frigate and its two primary turrets. Let me know if they're working. I'm going to try to get the rest of the capital ships unwrapped and textured in a similar fashion this week, if that works for you.

Ships are now moving along an orbit. Battle groups do not, and I still need to iron out some kinks that resulted from merging the ship and satellite classes.

Nice. How did you do the orbits? Kepler parameters, or something simpler?

Yeah, at the moment the orbital parameters are entered manually. Years ago I was working on a Kerbal Space Program clone, so I still have Sol's parameters, and I also have the code to calculate orbits from position and velocity, etc., but here it's going to get drastically simplified. I wanted the orbits to be circular only, so the only relevant parameters, if memory serves, will be current location, and the planet's mass.

Maybe later we can go Newtonian, but a) I don't know if that will actually make for more fun mechanics, and b) the in-mission physics are non-Newtonian, so I feel like the discrepancy might be weird.

IMO this level of simplicity is just right for the job. Sure, highly elliptical or inclined orbits can be fun to look at, think about and play with in orbital simulations, but I somewhat doubt that it's really within scope here.

It pains me, but is probably the right choice. Add me back to the dev list if and only if I manage to make a PR.

Feel free to ping me if you need any help figuring it out!

I was also trying to come up with a scenario where we could test some of the game mechanics we've been discussing. I was thinking about something along the lines of:

Tensions between [our Glorious Motherland] and [Evil Empire] have been rising. Hostilities have not broken out, but both sides are obviously preparing for war. As a result, the prices of [strategic resource] have skyrocketed, which in turn caused an increase in pirate activity. [Interstellar Mining Corporation] has requested military assistance in securing a recently established [strategic resource] mining base. Pirates have been raiding their freighters en route to [industrial center], and the frequency of the raids suggests they managed to set up a base in the same system the [Corporation] mine is located. Your orders are to locate and destroy the pirate base.

The rules would be:

  • Subspace jumps give away the ship's location at long range, unless line of site is broken by a large body like a planet/moon.
  • Depending on the distance between the detecting and jumping ship, and/or the quality of it's sensors, the destination of the jump can be estimated.
  • Infra-red sensors can pick up moving ships at short distances without giving away their own location
  • Radar can pick up static ships at short distances, but gives away it's own location
  • Ships can be pulled out of subspace with a warp inhibitor
  • No communication is possible with a ship in subspace.

Every once in a while a freighter would arrive to pick up the cargo, and then try to make it to a jump node at the outskirts of the system. If the pirates manage to figure out where it's going, they can pull it out of subspace and attack it, and if they're equipped with a signal jammer, you won't be able to tell anything is off until the ETA at the destination. You can counter with making a series of shorter jumps letting you confirm the status of the freighter, and narrowing down the location of the attack if one does happen, but almost certainly giving away the freighter's route.

You'd be judged by how many freighters make it out of the system before you destroy the pirate base, and any delays your security measures might have caused. The idea is that you'll have to make some sacrifices in order to learn where the pirates are launching their attacks from.

I think a scenario like that should be manageable in terms of development, would let us test which mechanics work and which don't, and would be a decent first mission for a larger campaign when we get to that point.

What is this place?

This website is a place for people who want to move past shady thinking and test their ideas in a court of people who don't all share the same biases. Our goal is to optimize for light, not heat; this is a group effort, and all commentators are asked to do their part.

The weekly Culture War threads host the most controversial topics and are the most visible aspect of The Motte. However, many other topics are appropriate here. We encourage people to post anything related to science, politics, or philosophy; if in doubt, post!

Check out The Vault for an archive of old quality posts. You are encouraged to crosspost these elsewhere.


Why are you called The Motte?

A motte is a stone keep on a raised earthwork common in early medieval fortifications. More pertinently, it's an element in a rhetorical move called a "Motte-and-Bailey", originally identified by philosopher Nicholas Shackel. It describes the tendency in discourse for people to move from a controversial but high value claim to a defensible but less exciting one upon any resistance to the former. He likens this to the medieval fortification, where a desirable land (the bailey) is abandoned when in danger for the more easily defended motte. In Shackel's words, "The Motte represents the defensible but undesired propositions to which one retreats when hard pressed."

On The Motte, always attempt to remain inside your defensible territory, even if you are not being pressed.


New post guidelines

If you're posting something that isn't related to the culture war, we encourage you to post a thread for it. A submission statement is highly appreciated, but isn't necessary for text posts or links to largely-text posts such as blogs or news articles; if we're unsure of the value of your post, we might remove it until you add a submission statement. A submission statement is required for non-text sources (videos, podcasts, images).

Culture war posts go in the culture war thread; all links must either include a submission statement or significant commentary. Bare links without those will be removed.

If in doubt, please post it!


Rules


Recommended Posts And Communities

Recommended Realtime Chats