A couple tiny fixes

[Jem]

1) Set shortcut 'B' in selected planet to Urgent/InstantBuy current production
file > Stars in Shadow\Lua state\GUI\~GalaxyMap\@PlanetPane.lua

Code: Select all

  if char_pressed 'E'
    select_next_planet {planet=selected_planet}
  end
  -- add below --
  if char_pressed 'B'
    order.buy_production(selected_planet)
  end

2) Set new created planet name to [Star name] & romanized [orbit position]
file > Stars in Shadow\Lua state\Orders\production.lua

Code: Select all

    local new_planet = new_planet_ref {
      type='Barren',
      minerals='Normal',
      ..size,
      ..planet.star,
      ..kW_m2,
      ..orbit,
      day_length=32,
      rarity='common',
      temperature = get_temperature(kW_m2),
      -- comment off below --
      -- name = 'Artificial Planet' ,  
      -- add below --
      name = (star.name .. " " .. to_roman(orbit)),

The current release do not have some features I urgently needed, so went and took a look and made quick fixes for a faster & easier gameplay.
We can use [Q] & [E] key to navigate between previous/next planet but can't [Buy] (using keyboard), so with Fix#1, in sort by 'Activities', I can [E] & to quickly buy the productions. The only problem is the planets after [buying productions] will many times be sorted 'up' the list and the 'supposedly next' planet need some work finding......
Help yourself to these fixes if you want. Cheers!

[sven]

I can [E] & to quickly buy the productions.

That does seem handy. The code as you're written it has some bugs though, as order.buy_production is actually relatively low-level, and doesn't do any sanity checking. It's bit uglier -- but here's a patch for your patch that I believe does all the necessary exception checking (and I am putting this logic into our working candidate patch set, so it will likely roll out to Steam/GoG users in a week or two ):

Code: Select all

	if char_pressed 'B'
		local p=selected_planet

		local can_buy

		if p.current_production_cost
			local buyout,hammers,metal = p:buy_cost()
			if (buyout>0) or (metal>0)
				can_buy = (not planet_blockaded(p)) 
					and (buyout <= p.empire.credits)
					and (metal <= p.empire.metal)
			end
		end

		if can_buy
			order.buy_production(selected_planet)
			Sounds.PURCHASE_ITEM()
		else
			Sounds.INVALID_ACTION()
		end
	end

The only problem is the planets after [buying productions] will many times be sorted 'up' the list and the 'supposedly next' planet need some work finding......

I'm not entirely sure what you mean by this. In the case of activity sorting, planets are sorted first by activity, then by the name of their project (so, for example, all planets building factories will appear together). You can see the sorting order function in @PlanetListPane.lua:203. Do you think there's a better sorting mechanism we should be using in this case? Maybe it would be more convenient to sort activities with a completion meter by decreasing level of completion?

[Jem]

Sven, Thank you kindly for your patch on ... my 'patch'. haha

I took a look at the sort_funs.Activity() and replaced

Code: Select all

eq_project_rank(p2),eq_project_rank(p1),

with

Code: Select all

p2.raw_hammer_production, p1.raw_hammer_production,

and now the sort won't 'move' planets up the list after buying productions. Not sure this is what you had in mind.

Btw, is it possible to sort the [project_name] only by the 1st 8 character, i.e. strlen("Colonize")? As it seems [Colonize] [project_name] is concatenated with the colony/planet name and it sort of broke the [Colonize] grouping...

Cheers!

[sven]

2) Set new created planet name to [Star name] & romanized [orbit position]

The problem with this convention is that it's possible for a star to spawn with empty orbits. That means you can end up with a planet called, say, ''Alinoth II" in orbit slot 3. Thus, if you use this convention for naming artificial worlds, you can end up with two Alinoth II's. However, it's just occurred to me that if we just assume that planet-builders add a simple suffix to denote their creations as artificial, the problem pretty much disappears. For example:

Code: Select all

 name = (star.name .. " " .. to_roman(orbit) .. '-A'),

[Jem]

You are right, Sven. I've met that situation you've mentioned about 'repeating' planet names when the star-system isn't fully populated with planets. The only thing I can think of to smooth out this 'duplicate name' kink would be to do a star-system wide rename after a new planet is created.
i.e. all planet names that contain the star.name will be renamed to star.name+to_roman(orbit)
As there is only a max of 4 planets per star system, it is a slightly acceptable performance loss (to me) when creating new planets.

the code would look something like this, maybe?

Code: Select all

local i=1
for _, planet in star:planet_list()
  if string.find(planet.name,star.name)
    star.planets[i].name = star.name .. " " .. to_roman(i)
  end
  i++
end

(I don't know Lua, and only have a quick look at the online Reference Manual to lookup string functions, please forgive any mistakes. haha)

*Edit*
I've added the above below

Code: Select all

    add_rotation_fluff | new_planet
    add_distance_fluff (star, new_planet )

and tested it out by renaming 2 planets to the same as what the new planet would be named, and all of them got renamed as intended after the new planet is created, and a lone Gas Giant called "Ampi" remain untouched.
Happy day! Cheers!

[sven]

tested it out by renaming 2 planets to the same as what the new planet would be named, and all of them got renamed as intended after the new planet is created, and a lone Gas Giant called "Ampi" remain untouched.

Cool

One worry I have with a patch of this type is that I know some players will use the planet rename feature to add suffixes to planet names to remind them of their plans for a planet. So, for example, you might end up with a planet named 'Misam II-Mines'. That planet would be auto-renamed by your artificial world creator, which is not ideal. We could modify the renaming function to be more conservative, and that would fix that case, but, at a high level, I'm not sure if it's ever a good thing to rename planets in a situation where players might not expect their planets to be renamed.

It's a subtle point of design; but, I actually think giving the artificial planet a distinct new name, like 'Misam II-A', may be better than renaming the old Missam II to Missam III.

[Jem]

Hmm... You're right, Sven. There many different types of players and even more ways & styles to play a single game. What you have suggested (star.name+to_roman(orbit)+"-A") makes good sense in every way > star, orbit, artificial.
Unless... you have plans to 'improve' this by giving options to users to name (or regex) (new) planets according to various situation (size, type, bonus etc), and maybe a button [default] next to the 'Star' name when we edit it, that uses these settings to rename all planets. The possibilities are endless, yet so will the complications too... so, maybe let's not go there. Haha
Cheers!