Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - XTRMNTR2K

Pages: [1] 2
Modding / A bunch of modding questions
« on: February 01, 2015, 11:00:53 AM »
Since I've been toying around with a few ideas in the last few days there are a few things I would like to know. Depending on how bored I am I may or may not add more random questions later on. :P

1. How exactly does directional damage work and what can be done with it? I am particularly interested in these:
   a) How does area of effect damage work? Does it apply directional damage to just one hex? Or does it hit *all* external hexes at once?
   b) Is it possible to apply some sort of "damage patterns" to weapons? Meaning would it be possible to hit multiple adjacent, external hexes instead of just one? Or scatter damage between a randomly distributed number of hexes within, say, a certain radius?

2. Waaay back when I asked about it, it wasn't possible to simply swap the railgun effector graphics (the actual projectiles or their trails) with custom textures. After trying again earlier today it seems it still hasn't been implemented yet? Is there something I could be doing wrong or, if not, is there an ETA on this feature?

One more question:

3. Is the suppression gameplay mechanic still in place? I see that it's still mentioned for railguns, just set to 0.

While playing a game in build r4207 I noticed that there seems to be an error regarding the slipstream duration formula.

A slipstream generator with a hex size one 1 provides a rift duration of 90 seconds.
As I tried to increase this by making the generator bigger, I noticed that there was barely a difference - the improvement only ranged from less than a second to 3 or 4 seconds, if I remember correctly.

So I was curious to see what happened if I put more than one generator on my ship and  - lo and behold! - it effectively doubled the slipstream duration, adding another 90 seconds to it. Needless to say, I wasn't surprised to see that every additional generator added another 90 seconds.

Even though separate generators do cost more control I don't think this is intended... or is it?

On a small side note, something really weird happened during that game which wasn't related to the aforementioned issue. One of my fleets would suddenly omit extreme slingshot behavior, accelerating quickly but being unable to stop as quickly as it should. It was quite extreme, but with a bit of micromanagement (and a good deal of patience) I managed to retrofit the fleet which cured the problem.

Now I am not exactly sure how and why this happened, but it most likely had something to do with the fact that my flagship had more acceleration than some (most?) of its supports. It seems the ship was able to accelerate at full thrust, but decelerating was almost impossible. After retrofitting the fleet so the flagship would have less acceleration, it worked normally until I added some new (generated) support ships that happened to have but a tiny engine - the fleet slowed to a crawl, obviously (until I manually fixed that design as well).

tl:dr the exact circumstances are unclear, but if the flagship has a lot more acceleration than most of the support ships, the shit hits the fan. WAY worse than the movement solution of SR1. :P

Suggestions / A bucket full of feedback and suggestions
« on: December 22, 2014, 05:35:20 AM »
Hey everyone, it's been a while since I posted anything :D

Usually when I'm taking part in any form of early access I'm keeping my mouth shut for most of the time, especially when the development seems to be heading in the right direction. Obviously, this is also the case for Star Ruler 2. :) However, I've been playing a few other 4X games for a bit (i.e. Master of Orion I, StarDrive), to get some perspective and inspiration. So I was asking myself a few questions along the way: What is fun about those games? Why is it fun? Could and should it be applied to SR2? What does SR2 better? That kind of stuff.

Before I go crazy with suggestions, however, I would like to offer some general feedback. It's no secret that SR and SR2 are both very close to my heart... And because of that I am going to be completely honest, no matter if I like or dislike a particular feature.

Modding Tools
Holy shit, batman, I did not see those coming! I've only dabbled with them for a bit to see how they worked, and I think it's great these are being offered. Sure, doing more advanced crazy stuff still requires working with angelscript outside the modding tools, but I am sure these tools will get many more people started with modding. And once you've started... There's no going back. ;D
Combined with Steam workshop support modders and players alike just could not be asking for anything more!
Well done, BMS, well done!

Pixel art and icons in general
Good work on the new planet biome graphics. These look much better and more organic now.
As for the buildings, these are looking better as well (even if some - or most? - are still to be considered temporary art).
I also absolutely adore the pixel art for the subsystems. They look great, and it's rather easy to distinguish one from the other. However, the new weapon subsystem art (which I assume is pre-rendered from 3D models) looks absolutely atrocious. None of these fit in with the other subsystems as they stick out like a sore thumb. My suggestion? Get rid of them and go for something more simple (pixel art!). :P And I guess you could drop the different perspectives and go for a top-down look instead. That way only one image is needed even for rotating subsystems.

Secret research
Like I said above, I've been playing StarDrive for a bit and one of the more interesting things I discovered was that as I had destroyed a few Remnant ships, I got a message saying that doing so unlocked a new branch of research labelled "Secret". It hadn't been visible before, and I thought it was cool that the research unlocked several slightly more advanced subsystems (such as ancient shields, fuel cells and reactors) among other things.

Now here's what I am thinking: To make every new game more interesting and unique, a bunch of extra techs (or just improvements) could be hidden throughout the research tree. And once you do certain things - i.e. destroy a particular remnant fleet, scan a certain anomaly or activate a rare artifact - you unlock a random one of these. It gives more incentive to actively explore the galaxy, since no one else would get access to the same research (although they probably got their own share of unique extra tech!).

Time to think big

The following two suggestions are rather big and complex, and I've spent a fair bit thinking about these mechanics. The idea is to add certain features not for the sake of just adding stuff, but branching out in terms of tactical options.
Example: You got lots of time? Besiege a planet. Got lots of money and population? Send troops to conquer a planet. Don't care about your enemies gaining leverage on you? Bomb the shit out of them! Got a lot of pull in the galactic senate? Start a petition to gain ownership of your desired planets.

Ground troops and planetary invasion

- In addition to spawning support ships, planetary bases created by defense pressure also convert civilian population into troops at a rate of 100k/min per base. Launchpads convert at a rate of 150k/min.
- The maximum amount of troops per planet is 1 million troops per base. The maximum ratio of civilians:troops is 4:1.
- Troops still count as population for all purposes except colonization. When colonizing new worlds, only civilians are sent off via colony ships.
- To invade a hostile planet, both parties need to be at war with each other. The invading party sents their troops via dropships, which carry 100k troops each.
- Launching troops costs 25k of § per 100k troops to properly train and equip them, and is paid upfront. (so no spamming your enemies with troops just for the lulz unless you are filthy rich)
- Dropships have more acceleration than colony ships, but can be shot down all the same.
- If there are no defending troops present, the planet changes ownership once 1 million invading troops have landed.
- Conquering a planet via invasion resets planet loyalty to 0.
- A siege is canceled when troops land on the planet. As long as there is fighting on the ground, it is impossible to besiege a planet.
- In case of multiple allied invaders attacking a planet, the claim goes to the attacker whose troops first set foot on the planet; if all attacking troops are defeated, ownership remains with the defender and the claim resets after 2 minutes so another player may claim the planet.
- If the invader conquers the planet and more troops are remaining than bases present (if any) can sustain, troops will turn into civilians at a rate of 200k/minute until the number of troops reaches the limit of sustainable ground troops. Should no bases be present, all troops will be converted into civilians. If the number of civilians and troops combined after a successful invasion exceeds the maximum planet population, troops will first vanish at a rate of 200k/minute before they start to convert into civilians. Leftover troops may, however, be transferred to other planets; both relocation to friendly worlds as well as invading hostile ones is possible.
- The rate at which opposing troops are killed and kill each other is dependent on various factors, i.e.: Research, racial traits, planetary conditions, loyalty. Generally speaking, the rate of fighting is higher the more troops are present; if one or both sides have significantly less troops than the other, fighting will slow down (think guerrilla warfare).
- The more ground troops involved, the higher the chance that each "round" of combat also kills a number of civilians. Smaller conflicts may end without a single civilian dying.
- Both the attacker and defender may send additional troops during or after the invasion to reinforce their presence.
- Flagships may be used for planetary bombardment in two different ways:
     Regular weapons (laser, railguns, missiles) may be used with or without friendly ground troops present. However, these weapons do not discern civilians and combatants, and there is also a chance to hit friendly ground troops. Using these will also damage or destroy buildings.
     Bombardment weaponry deals less damage, but has a much smaller chance of hitting civilians or allied ground troops. These weapons are also much more unlikely to hit buildings except for defensive structures; if any are present, these are targeted first until destroyed.
- When orbital bombardment is used without ground support, the planet needs to be re-colonized once all population has been killed.
- In case that all civilians are dead but the attacker has less than 1 million troops remaining, the planet is considered unowned and additional troops (friend or foe) or civilians (friend) need to be sent to capture the planet. As long as the planet is unowned, the troops will remain on the ground but decay at a rate of 200k/minute.
- When ordering an invasion, the amount of troops to send is set at 1 million since it is the absolute minimum required to capture a planet. However, it can be increased or decreased in 100k steps (less is possible so multiple planets could send a few hundred thousand each to one destination and still conquer an undefended planet if 1 million is present on ground at the same time).
- Protect planet card also prevents planetary invasion as well as orbital bombardment in addition to siege.
- Using bombardment to kill off an entire planet's population grants one leverage card (against the attacker) to the planet's owner.
- Civilians may be transferred between any two established, friendly colonies. They are sent via colony ships just when colonizing unowned planets. The minimum amount to send is 1 million which can be increased in steps of 1 million each. If the difference between the current and maximum population on the destination planet is less than 1 million, the option to send additional colonists is unavailable. (Also more than 1 million population needs to be present to be able to send off any colonists, obviously.)

Fleet groups, positioning and supplies

- Multiple flagships can form a fleet group under the following condition:
     One ship needs to be designated "fleet group leader". Once that is done, its support command can only be used to coordinate other flagships instead of support ships. However, flagships count as twice their own size towards the support command limit.
- All other flagships get to keep their own support ships, but these will position themselves in the fleet around the core of all flagships instead of just one flagship alone.
- The flagships always form the core of the fleet group. They stick together closely, with the fleet group leader surrounded by the lesser flagships.
- Only one fleet group leader is allowed per group; stacking of fleet groups together is not allowed.
- All support ship designs get a setting for "positioning" inside a fleet or fleet group. These are possible: Default/dynamic (fill in where needed), vanguard, rearguard, flanks, center (surrounds core of the group in a circle formation), roam (may spread out further from the group), swarm (gets into close range of the target and attacks in circling and strafing patterns). Alternatively, make positioning available via check boxes (i.e. allow positioning in flanks and rearguards, but never as vanguard, etc.).
- When a fleet group is formed, all available supplies are pooled together.
- If a flagship is destroyed, its support ships are distributed among the other flagships if possible. If not enough support command is available, the supports are removed from the group and try to get to the nearest friendly planet.
- If the fleet leader is destroyed, the fleet group dissolves.
- When two allied fleets are close, one may transfer supplies to the other. The amount of supplies on the receiving end may not exceed the maximum supply capacity of the fleet/group. No special equipment is needed to do this, all flagships can transfer supplies between each other.
- FTL rules for fleet groups: When using Hyperdrive, all flagships in a group need to be equipped with one. The FTL speed is then limited to that of the slowest ship. For Fling and Hyperdrive purposes, subordinate flagships only need to pay 25% of their normal FTL cost, only the fleet leader costs the regular amount to FTL. Gates and Slipstreams function as normal.

Still there? Good! Guess I should give awards for reading through all that! ;D

Galactic Armory / Development of Galactic Armory 2.0 has ceased
« on: August 10, 2013, 08:59:11 AM »
Star Date S-Y2013-M08-D10-1337
Incoming Transmission:
Stasis initialized.
All non-vital systems powering down.
Life support redundancy... check.
Duration of stasis... UNKNOWN

We hereby announce the end of Galactic Armory's active development.
There are no plans to release further patches and releases for it.

The state of things

The most loyal of our followers may have been wondering about the lack of updates regarding the development of Galactic Armory 2.0. Unfortunately there is no nice way of saying this; simply put, the development is put on ice.

Now this may come surprising and as a huge shock for most of you, but for everyone on the team this was something that was visible on the horizon for a long time. In the end it boils down to real life interfering with our plans, combined with said plans being overly ambitious, and ultimately a lack of motivation that grew worse as time went on. There isn't a single person to blame for this (well, maybe except myself...), and a step we pretty much decided unanimously on.

What the future holds

With Blind Mind Studios having officially announced Star Ruler 2 just a few days ago, there is a possibility we - either as a whole or at least some of us - will be modding SR2 as well. However, the announcement of SR2 had absolutely nothing to do with our decision; it was made long before any news of SR2 had been released. It is also worth noting that it is still far too early to make any promises, so you may or may not see us working on an SR2 mod in the future.

With that being said I also can not rule out some further refinement of Galactic Armory for SR1. While there are no plans as of now, it is not entirely impossible that there will be some form of improvement in the future. No promises, though!


Since I do not now when or if I will post any official news regarding this mod again, I would like to say a final thank you to everyone who had been involved in the making of this mod over the course of the last years. This includes of course the team members and fellow modders, who contributed so much work and content to the mod, but also YOU as loyal fans and players of the mod, who would always give us valuable feedback and ideas, as well as the developers of Star Ruler, who have always been helpful in every possible way. It has been an interesting ride for sure, especially with such an awesome community!

Thank You!

Galactic Armory Mod Project Lead

Galactic Armory / MOVED: Galactic Armory 1.9.2 MP Import Dock Crash
« on: December 06, 2012, 04:58:11 AM »
This topic has been moved to GA: Help & Support.

Galactic Armory / Mod DB Mod of the Year Awards 2012 - Vote for us!
« on: December 02, 2012, 05:04:17 AM »
As many of you may know it's that time of the year again.

We hope that you have and are still enjoying our mod, Galactic Armory. If you do, consider voting for us in the Mod DB MOTY 2012 Awards. While we do understand that it is very unlikely for us to take a trophy home, there are still reasons to vote for us. Simply put, a vote for Galactic Armory is, in a way, a vote for Star Ruler. Getting a high rank - possibly even within the top 100 - would mean that a lot of people who have never even heard of Star Ruler would get a chance to check it (and Galactic Armory) out. For indie developers like Blind Mind Studios, success is heavily dependent on being known. Having the best games doesn't mean anything if no one knows about them in the first place. Since the release of Star Ruler over 2 years ago the developers have supported the game (and us as players and modders!) with incredible passion. I think it is safe to say that we should give something back now. :)

So, if you like Star Ruler and Galactic Armory consider heading over to Mod DB to vote for the Mod. It won't hurt a bit! ;)

Galactic Armory / GA 2.0 Dev Update #1 - Research explained
« on: October 07, 2012, 07:39:22 AM »
Galactic Armory 2.0 Research explained

One of the most extensive changes we are planning for the next major release of Galactic Armory is a complete overhaul of the existing research. This includes the technology tree of the game as well as the technology curve, better known as level gain curve.

In its current state, research in Star Ruler (and Galactic Armory) is neither really exciting nor very rewarding. The player basically queues his research (or lets the automated research feature do its thing) and simply waits until everything is unlocked. The flaws of this system become even more obvious when general science is queued repeatedly in combination with turning most of your planets into research worlds. What follows is usually sending out unstoppable fleets or even single ships that can clear out most of the galaxy from hostile forces without much resistance.

Why is that so? There are several reasons. First, to improve your existing technology you have to research one or multiple technologies. Repeatedly. However, this usually also unlocks a large number of more advanced technologies. In most cases this more complex technology is, despite drawbacks and increased cost, often almost a straight upgrade from existing technology. Long story short: There is enough reason to make players WANT to upgrade everything because it is easy AND rewarding. This is made even worse by the fact that general science has a huge impact on research rate as well.

Another reason for the aforementioned issues is the exponential levelling curve. Not only does research easily unlock dozens of new, better subsystems, it also increases everything by a whopping 35% over the previous level (default setting). The differences in overall fleet and empire strength resulting from even very small differences in research rate (and focus) often make intelligent ship design and efficient empire management irrelevant. Whoever has the most research wins more often than not. Even economical strength is mostly based on reserach, so no amount of good leadership will save you against a technologically superior foe. Is this fair? And is it fun? We believe this is not necessarily the case and have decided to change both the nature of the tech tree as well as the overall impact research has on the game.

Brace yourselves. Change is coming.

There are three main goals we want to achieve by redesigning the research in this game:
1. Research must allow for and reward specialization. Unlocking each and every last thing should not be expected in an average game.
2. The structure of the technology tree must be easy to understand.
3. Research should be important, but never be the single factor deciding over victory or defeat.

"Research must allow for and reward specialization." What does it mean? Simply put, subsystems will be spread out more over a larger tech tree. Not necessarily by level - we aim for a rather flat unlocking progress curve - but by research node. This makes it less likely that every player will end up with everything unlocked over the course of a game. Research takes time, and we want to set up research in such a way that it may be desirable for players to focus on few fields of research instead of researching a little of everything.

In addition, though it will still take some levels of research to unlock, we want more advanced subsystems to be more than just straight upgrades of previous ones. This will also require an extensive rebalancing and overhaul of all subsystems. One aspect of this approach is giving players more choices about what they actually want to upgrade instead of a simple "I'll take everything at once" approach. You want more precise weapons instead of only going for increased damage? No problem. Need more range? Or rate of fire? The choice is yours.

"The structure of the technology tree must be easy to understand." This one should be pretty self-explanatory, but it deserves a few words since it is so easily gotten wrong or forgotten about altogether.
When creating a mod or game, it is surprisingly easy for a developer to get lost in complex mechanics and formulae. In fact, this can make one lose track of seemingly obvious things - like making things understandable and accessible for someone outside the development team. While our research tree is still considered work in progress, we have already gone through several different layouts and versions during the concept phase until we managed to come up with one that isn't overkill, i.e. consists of several hundred nodes.

What are nodes? Basically each research node is either one of two: A root node or a branch/sub node. A root node is the main field of research for a whole set of fields. Currently each set consists of one root node and three sub nodes. For most subsystems, root nodes and sub nodes don't differ that much; research root nodes unlocks new subsystems, which also holds true for many sub nodes. Weapons, however, are a different matter. Weapon root nodes handle all of the unlocking for a set of weapons (i.e. beam energy weapons). They also improve some of the most basic features, which includes damage at the very least. Weapon sub nodes on the other hand do not unlock new subsystems but mainly serve to improve specific properties of a weapon system. The actual number and type of features improved by each weapon research node may vary between weapon groups, giving each weapon type more character.

"Research should be important, but never be the single factor deciding over victory or defeat." Like we examined before, research currently plays a major role in the game, often make designing clever ship layouts and countering enemy layouts completely moot. Sadly this does not do Star Rulers combat mechanics and blueprint design justice. Because we feel there is so much more to this game that is often neglected or simply not seen due to very few but far-reaching issues, we have decided to change this aspect of the game to something that favors the strengths of the game mentioned before. This is achieved by changing the exponential level gain curve (the formula that determines how much stuff improves per level) to a flat increase modifier. Though we haven't decided on specific values yet, here is a quick example to show the difference:

Code: [Select]
Level: Exponential @1.35 Linear @1.2
1 1 1
2 1.35 1.2
3 1.82 1.4
4 2.46 1.6
5 3.32 1.8
6 4.48 2.0
7 6.05 2.2
8 8.17 2.4
9 11.03 2.6
10 14.89 2.8

So, in a nutshell, the difference compared to level 1 becomes huge with an exponential system - especially at later levels. In this example, a 35% exponential increase would result in a 14.89 times higher value at level 10 than at level 1 - compared to just 2.8 times the original value with a flat 20% increase per level.

Closing words

All of the above should be considered work in progress for all intents and purposes. All of these mechanics is still subject to change, but we felt this was a good time to give you a general outlook of things to come. We hope you enjoyed this update and look forward to the next one!

This topic has been moved to GA Help & Support.


Galactic Armory / *** Incoming Transmission ***
« on: July 23, 2012, 05:34:28 AM »
***Incoming Transmission***
Sent: 4024.5
Sector Beta / 458.3-277.9-021.1
ID: Recon Drone TC-357
***End of Transmission***

This image was recorded and sent just moments before we lost contact to one of our recon drones. As of this time we have no further intel on the object depicted in this image; however, it seems to be firing some sort of beam weapon. Until we are able to gather more information on this matter, we should assume this to be the first contact with a hostile race.

A team has already been dispatched to locate and retrieve the drone's blackbox.

Suggestions / Modding-friendly suggestion: Charge-up weapon logic
« on: August 06, 2011, 12:37:23 PM »
I understand that the game won't see further changes beyond bug fixes from now, but there is something that I would like to suggest regardless, and which would add a feature helpful for modding.

Usually effectors in Star Ruler work like this: When the subsystem is ready and has a valid target, the effector is immediately activated, and a fire gfx (i.e. muzzle flash) is played at the same time as a sound effect.

What I propose is support for an additional pre-fire phase that would work like this: If the weapon condition is ready and a valid target is in range, the charge-up phase would begin, counting down for [ChargeTime] seconds. At the same time, an optional sound effect (ChargeSound) as well as an optional fire gfx (ChargeGfx) could be played, showing a audiovisual indication of the charging process.
If the ship, target or corresponding subsystem are destroyed before the weapon is fully charged, it will revert to the pre-charge up "ready" state (either aborting the current charge-up phase or having to complete it first, either one works).

Now I don't know how complex this is, but if it isn't too demanding it would be great to have this option available for modders.

Alternatively - if this isn't implemented officially, how can this exact functionality be achieved through means of modding?

Modding / Assigning colored empire backgrounds - how does it work?
« on: July 29, 2011, 02:17:54 PM »
Starting this patch, colored nebula backgrounds are assigned to each player color. What I need to know is how this works exactly. I know there's EmpireBackgrounds.txt where each of the backgrounds is assigned a color name - but how is this color name linked to the actual color itself?

The reason I'm asking is that I would like to make sure the backgrounds are assigned to the correct colors as well as provide more backgrounds for our next mod release. The way it is now, however, colors and backgrounds usually do not match each other.

Thanks in advance to anyone willing and able to help. :)

Star Ruler Discussion / Star Ruler Retail Cover
« on: July 29, 2011, 01:43:26 PM »
While browsing amazon, I just spotted this:

Is this the official, final cover for the retail version? Is this one limited to the German boxed release? To be honest, it looks ... strange. The cover IMHO neither reflects Star Ruler's quality nor its overall style. To be honest I would've expected something simpler, yet more elegant as cover.

Regardless, I just pre-ordered my copy from Iceberg Interactive. Just thought I'd throw this out there.

Modding / "Scalefrom:" How does it work?
« on: June 25, 2011, 04:22:49 PM »
When the erudite AI was introduced, I noticed that some ships in the respective AI personality files had an additional property called "scalefrom". For example, the erudite Defender has this entry:

Code: [Select]
<default file="Layouts/Default/Carrier" goal="Carrier" strikecraft="#SH_Assailant" replaces="#SH_Carrier" scalefrom="8.5" />
So I have two questions:

1) How exactly does scalefrom work? Is it the absolute minimum scale the ship starts at? Or is it the minimum scale factor that is used?

2) Is there an opposite function of this, i.e. "scaleto"? If a maximum absolute size or maximum scale factor could be defined, this would be very helpful indeed.

Bug Reports / [1080] Issues with some particle systems
« on: June 25, 2011, 05:49:02 AM »
Some particle effects seem borked in 1080. Most notably those that use the corona graphics, like fuel_cell_glow (I think). Instead of the usual "flare"-like appearance, the effect looks more like a ring. Pretty cool for some things, but probably not intended.

What was witnessed:
Some particle effects look like an expanding broken ring instead of a fiery explosion.

What was expected:
The effects should have looked like before.

Reproduction Steps:
  • Load up the game in developer mode
  • Start Particle Editor
  • Load the particle system overview

Suggestions / New function Tag: IgnoreLink:<Link Name>
« on: May 30, 2011, 01:50:36 PM »
Maybe something like this is already easily possible, but I'm throwing my idea in the ring anyway:

I propose the addition of a new kind of subsystem tag. This would basically tell the game to ignore a specific link type subsystem (or multiple links with the same tag). It could look like this:

Code: [Select]
Tags: Weapon, IgnoreLink:CoolantSys, BeamWeapon
Which would prevent the use of Coolant Systems with this particular weapon.

There are already several ways of making it impossible for a link subsystem to change certain subsystem's variables, i.e. changing the variable designations. However, this tag would IMHO made it a bit easier for modders.


Help & Support / Erudite AI - a few questions regarding modding
« on: May 18, 2011, 02:03:44 PM »
So we got the amazing new Erudite AI with the latest patch...

Since MDK and I wanted to get our mod to be 1076-compatible ASAP and make use of its new features (mainly the AI), there were a few things we stumbled across:

  • (How) can we define traits for an AI personality that uses the Erudite AI as base? Adding them via <traits>(...)</traits> doesn't seem to work for this new type of AI.
  • (How) can we define a specific shipset to use? I recall this being announced as an upcoming feature for the new game menu, but that was a while ago.
  • What does one need to know/consider when planning on using the Erudite AI for custom AI personalities?

The most pressing question here being the last one. After looking at the new (folder) structure caused by the addition of a second AI type, I applied most of the changes to our current development build. That means I created subfolders for the personality files within Script Data/Personalities/, updated empire_defaults.xml to make the new AIs accessible and modified each of the corresponding AI personality files. The only thing I did not do was creating separate folders for the AI layouts, instead using the same layouts the basic (or rather "poor") AI personalities use.

Starting a game with different AIs works, and the log does not show any errors. All of the AI types that were configured to use the Erudite AI, however, sat idle on their homeworlds doing nothing. Not even a single structure was build (apart from the pre-built ones).

Is there anything that I did wrong? Something I need to know if I want to make use of the new AI?

For the next version of Galactic Armory we (or rather MDK ;D) have been working on a new damage script that is a modification of the script our laser weapons use. We wanted to deal the full damage in one hit rather than split between several ticks, just like projectile weapons (i.e. railguns) do.

However, contrary to our expectation, whenever there is no duration defined in the effector - regardless of effect and script not using nor needing it - the script isn't even called. The sound and firing animation play, but nothing is applied (damage, heat). As long as we change the duration to anything larger than 0, it works. The question is... Why?

Here's the subsystem definition:

Code: [Select]
System: TachyonBlaster
Appearance: TachyonBlaster

Available: (Techs.Sensors.Level > 13) && (Techs.WarpPhysics.Level > 13) && (Techs.ParticlePhysics.Level >13) || Traits.remnants
Level: floor((Techs.Sensors.Level / 3) + (Techs.WarpPhysics.Level / 3) + (Techs.ParticlePhysics.Level / 3))
Size: Scale
HPLevel: Techs.Materials.Level-1 As Level
Durability: GAME_SUBSYS_MULT * 100 * Size * pow(HEALTH_CURVE,HPLevel)
Mass: 80 * Size * max((1 - (0.01 * (floor((Techs.Metallurgy.Level / 3) + (Techs.ShipConstruction.Level / 3) + (Techs.Chemistry.Level / 3))))), 0.6)

Tags: Weapon, BeamEnergyWeapon, Require:ThermalManagement
Tied To: Sensors 14, WarpPhysics 14, ParticlePhysics 14

Costs: Metals[100 * Size], Electronics[100 * Size], AdvParts[75 * Size], Labr[5 * Size]
Complexity: 5

vTachyonDamage: Size * 50 * 4 * pow(LEVEL_GAIN_CURVE, Level) * min((1 + (sqrt(Size) / 30)), 3) * GAME_DAMAGE_MULT
vTachyonDelay: (5) * (1 + decay(pow(LEVEL_GAIN_CURVE, Level), 100)) * min((1 + (sqrt(Size) / 20)), 4) * GAME_RELOAD_MULT
vDeviation: 0.2
vPowCost: Size * 40 * decay(pow(LEVEL_GAIN_CURVE,Level),22.5)
vTachyonRange: (600 * (1 + (Level * (0.01 * WEAP_RANGE_CURVE)))) * ((sqrt(1 + Size) / 10) + 1) * WEAP_RANGE_MULT
vEffectiveRange: 1
vMinDmg: 1
vWasteHeat: Size * 2.5 * 4 * min((1 + (sqrt(Size) / 20)), 3) * (1 / GAME_RELOAD_MULT)

Provides: EnergyWeaponInstant with Damage[vTachyonDamage], Delay[vTachyonDelay], PowCost[vPowCost], Range[vTachyonRange], Deviation[vDeviation],
effectiveRangeFactor[vEffectiveRange], minDamage[vMinDmg], wasteHeat[vWasteHeat]

To Run:
Control[40 * Size]

Hints: Alpha[vTachyonDamage * 0.25] , Power[-1 * vPowCost * 0.25], DPS[(vTachyonDamage * 0.25) / vTachyonDelay], Local/Range[vTachyonRange], Local/MinRange[vTachyonRange * 0.1], Local/DMGperShot[vTachyonDamage * 0.25], Local/Delay[vTachyonDelay], WasteHeat[(vWasteHeat * 0.25) / vTachyonDelay]

Not much special about it. The subsystem itself works, it was tested with different/modified effectors.

Code: [Select]
Effector: EnergyWeaponInstant
Value: Damage
Value: Delay
Value: PowCost
Value: Range
Value: Deviation
Value: effectiveRangeFactor
Value: minDamage
Value: wasteHeat

Range: Range
PotentialDamage: Damage

PhysicalType: Instant //was Beam
//Material: beam_empty
GfxSize: 0.1
GfxColor: fff
FireGfx: laser_emit, 0.5
HitGfx: tachyon_impact, 0.05
Sound: fighterlaser

Causes: TachyonDmg lasting 0.25 with Damage[Damage], Cost[PowCost], Range[Range], effectiveRangeFactor[effectiveRangeFactor], minDamage[minDamage], wasteHeat[wasteHeat]

AutoAttack: Enemy
CanAttack: CanAttack, GACanAttack::checkHeat, Combat::minimumRange
OnFire: Timed(Delay, Deviation)
Tick: Reload
Progress: TimedProgress

This is the corresponding effector definition. checkHeat has been tested and works flawlessly with others, and minimumRange hasn't been changed from vanilla. At first we thought it was the OnFire which prevented calling the script, but changing it to TimedShot didn't help, either.

Code: [Select]
Name: TachyonDmg
Value: Damage
Value: Cost
Value: Range
Value: effectiveRangeFactor
Value: minDamage
Value: wasteHeat

Tick: GACombatWeapons::EnergyDamageInstant

This is the effect.

Code: [Select]
void EnergyDamageInstant(Event@ evt, float Damage, float Cost, float Range, float effectiveRangeFactor, float minDamage, float wasteHeat) {
Object@ targ =;
if(@targ != null && @evt.obj != null) {

if(!handleHeat(evt, wasteHeat))

if(Cost > 0) {
float tickCost = Cost;
State@ power = evt.obj.getState(strPower);
float fireDuration = min(power.getAvailable() / tickCost, 1.f);
if(fireDuration > 0) {
power.val -= Cost * fireDuration;
dealDamage(evt, Damage * fireDuration * rangeMod(evt, Range, Range * effectiveRangeFactor, minDamage), DF_Energy);
else {
evt.state = ESC_DISABLE;
else {
dealDamage(evt, Damage * rangeMod(evt, Range, Range * effectiveRangeFactor, minDamage), DF_Energy);

The script does not make use of evt.time, so the duration shouldn't be needed.

It's not like this is super important, but to be honest, I'd sleep a whole lot better understanding at least why this happens. Would be great of one of the developers could shed some light on it. :)

Okay, I'm at my wits' end.

I don't think this is happening in the base game, but unfortunately it is still happening with our mod, Galactic Armory.

For some reason, when some tool-type subsystems (i.e. repair tools, superweapons) are mounted on a ship that is also equipped with a jump drive, the jump drive won't work. When a star is right-clicked, the right mouse button menu appears - but with a twist: Normally only the localized tool entries are shown, but in this case, the old "use tool..." menu also shows up. But it's empty.

When I click on one of the other tool orders, nothing happens. The order isn't even given to the ship (as opposed to an order that's given but not executed).

Now I don't expect anyone to solve this problem for me, but there's one bit of information I desperately need:

What determines if the 'old' submenu is shown or not?

Thanks in advance.

What was witnessed:
Strictly speaking, this is probably not a bug per se, but the behavior IS strange and may cause issues such as excessive ship spam:
When a carrier with Manage Docked order is manually ordered to "undock all", all strike craft immediately take off. As long as they are undocked, the carrier will try to fill up the ship bay again by ordering a full complement of strike craft at a nearby planet. Once the ship bay is full again (or enough strike craft have been produced, I think), the carrier stops ordering new ships.

What was expected:
Manually undocking the docked ships should not cause the carrier to order new ones. Although the carrier technically only does what it's configured to do, so being able to toggle this behavior without having to re-fit the ship would be very useful.

Reproduction Steps:
  • Build Carrier
  • Undock strike craft manually
  • Watch the fighter spam!

Extra Files:
Savegame with a carrier and pre-built strike craft.

Suggestions / Name comparison function for blueprint import window
« on: April 24, 2011, 05:13:33 AM »
Now that we're able to to import all available blueprints at once, I suggest the addition of another function. Imagine this:

You start playing a new game. As your tech level progresses and new technologies are unlocked, you want to import the two dozen blueprints you designed earlier. Since you don't know the exact level requirements of each of your blueprints, you just hit "import all", so that those that are working on your current tech level will be made available.
As the game progresses further, you need to repeat this to keep adding your pre-made blueprints. Normally this is all fine and dandy, BUT if you change one of your already imported blueprints during the game - i.e. exchange subsystems, optimize efficiency, change AI settings - you can't just keep hitting "import all"; if you do, your changed blueprints will be replaced by its original version (and the modified version will be marked as obsolete).

So, to remedy this, I propose adding a feature that allows to compare the names of the already existing blueprints with those that are to be imported. Something like a checkbox "ignore blueprints with duplicate names" could work for this. IMHO, this would reduce blueprint micromanagement to a minimum.

Modding / Particle Editor unable to load mod materials in 1074?
« on: April 18, 2011, 08:38:03 AM »
As some of you may know, I started tinkering with Star Ruler's particle editor a while ago. Specifying the mod to load in the commandline it is possible to load and save particle effects from mods. That was back on 1070. When I wanted to load some of my custom particle effects today, I realized that I couldn't. Despite checking and doublechecking the shortcut with which I was starting the game, the particle editor would only show me materials provided by the base game.

Has the particle editor been changed since 1070? Or am I simply missing something?

What was witnessed:
After opening the systems window and sorting the planets in descending order, the pulldown menu for governor selection starts appearing and disappearing randomly for each planet. Sometimes this even happens with ascending order.

What was expected:
Being able to select a governor for a planet.

Reproduction Steps:
  • Open Systems Window
  • Sort planets, i.e. descending by number of slots
  • Click a planet governor to open the pulldown list
  • Watch the pulldown list going crazy!

BTW I've seen this happening with the current development build of Galactic Armory, but it shouldn't be caused by the mod as there was no change to this window.

I've been trying to add two varations for each shipset for the next version of Galactic Armory. Getting the textures (or rather glowmaps) to work was no problem. With three selectable shipsets, I could still enter the empire customization screen. However, once I had four shipsets, the game crashed every time I tried to open empire customization to select the shipset.

The issue doesn't seem to be 4th shipset itself, as removing another shipset to reduce the number of shipsets to 3 enabled me to open it just fine. I could start a game with the shipset, and even after quitting the game and re-adding the one I removed earlier, I could load the savegame. The game still crashes every time I open the customization screen, though.

Is this an issue similar to the one with empire flags, i.e. would adding a 5th shipset remedy this?

Happy holidays! STEAM offers yet another MASSIVE 80% discount on Star Ruler, so I'm giving away ANOTHER TWO COPIES OF STAR RULER FOR FREE!
Rules are the same as always: First come, first served!

Already gave one to a friend today since giving is so much better than taking. ;D

Original Posts:

In celebration of today's amazing daily deal on STEAM I'll be giving away another free copy of Star Ruler RIGHT NOW.

Rules are simple: First come, first served.

Of course, other players are welcome to join in and do the same. ;D


Hey everyone,

in celebration of today's awesome daily deal on Impulse I've decided to give a away a free copy of this magnificient game. 10.45 USD / 7,59 € is an amazing price for this ever-improving piece of art, so I figured why not make this deal even sweeter for someone else and give it away as a gift? ;D

So, if anyone not already owning a copy of Star Ruler is reading this, I am willing to gift one Impulse copy of this game to the first person to post in this thread. :)

Suggestions / Support for more than 4 values for effects
« on: February 12, 2011, 05:45:06 PM »
While developing a method to give weapons hitrate and/or damage that decrease with distance-to-target beyond a certain effective range, MDK and I just discovered that you currently can not have more than 4 values for effects. If possible, it would be great if this could be increased to at least 5 values per effect (with the next patch?), since that would make things A LOT easier.

Can/will this be done?

For the next release of Galactic Armory, I was planning on replacing the Damage Booster by something a little more... interesting. To be precise, I want a subsystem modifier that changes the damage, delay and cost of the linked weapon - and, most importantly, makes it fire in bursts of 2 shots.
The basic idea is that the weapon would fire those two shots with only a short delay between them and then have a prolonged delay before being able to fire again. Based on the overall size of subsys and modifier, there would be a slightly larger damage bonus as well as a slightly shorter delay modifier with increasing overall size.

Now I'm not entirely sure if this is even possible, but maybe someone knows more about this or has ideas how it could be realized...?

Modding / Modding some resources without overwriting the base files - how?
« on: December 26, 2010, 04:50:05 PM »
Something has been bugging for quite a while now: How can we replace some of the resources without having to overwrite the base files? Or maybe I should ask the other way around: Which resources are currently off-limits to modders?

The reason I ask is I tried swapping the shield texture for a modified one a while ago. Having the appropriate entry in the materials.txt of the mod didn't work; temporarily swapping the new texture for the original one in the base game's images folder did, however.

Inspired by this thread and the fact that I had to tone down the brightness of my ridiculously powerful screen, I would actually like to supply Galactic Armory with a slightly brighter/higher contrast galaxy background. The realistic system generation mod also leads to much bigger distances between objects in space, making them less illuminated in most cases, and thus a lot harder to spot with the naked eye.
Once again, having the file and materials entry in the mod doesn't work... Is this because two entries of the same name can not be loaded? Changing the name of the entry along with the file that actually calls it would work, then... But where is it called? I suppose it is the same case as with shields - hardcoded?

BTW here are some screenshots to demonstrate what I mean.



I've also attached the modified skybox texture to this post, so anyone who's interested in it can try.

What was witnessed:
When ordering or force-ordering a ship to use it's repulsor, attractor or interdictor, nothing would happen. In fact, not even an order showed up in the list of planned actions.

What was expected:
The ship should have used the repulsor, attractor or interdictor on it's target.

Reproduction Steps:
  • Build a Ship using one of several of the aforementioned subsystems
  • Right-click on a target, select Use tool... and the appropriate subsystem
  • Watch nothing happen

The funny thing is, I only stumbled over the reason for this by pure chance. MDK and I were still experimenting with getting some weapons to work strictly via tool-order only for Galactic Armory. After trying pretty much everything without any success, I noticed some of the tools in the game or other mods had tags like this: "Superlaser, Tool:Superlaser", where I did not know the former tag was mandatory (duh!). So when I finally discovered this, I looked for the same mistake with the attractor, repulsor and interdictor - and found it. After adding the appropriate tags, I test-fired the weapons on my own ships, and it worked. Had to force the order by ctrl-clicking, though.

Suggestions / Automatic Research
« on: December 16, 2010, 03:52:37 PM »
(This may have been suggested before; if so, consider this support of the original idea.)

Players should be able to automate research (a governor for research, if you want).

Most of the time, I find myself manually managing the research only until I get every technology, or every field of research on approximately the same level (say, level 13 or something). Afterwards I tend to set it to "General Science" to avoid imbalances between different technologies (i.e. too much sociology for my farms to handle). Yes, I know you can queue research by ctrl-clicking, so that's not the point here. (In fact, I do it all the time.) ;D

To make things easier for the player once he gets to this point, it should be possible to automate research, so that each time a new tech level is reached, a different, randomly chosen tech gets researched. To make things even better, it would be great to be able to set one or two priority technologies and their research probability, much like the AI personalities have.

Of course I don't want a game that plays itself; but it'd be nice to lessen the burden of being a galactic emperor. ;D

Modding / Question regarding initial firing delay of missile racks
« on: December 10, 2010, 08:28:08 AM »
This is something I've been wondering about for quite some time now, and I couldn't really find an answer to this, so...

What defines the initial delay before missile racks fire their salvo? Is it always the same as vClipDelay? Or is it something completely else (maybe in the effector)?

The reason I'm asking is that I've been experimenting with missile racks, and it seems the initial delay is influenced by the reloading times between clips. Is there a way to change the initial delay independent from that?

Pages: [1] 2