Fun with starlanes

Creation, discussion, and balancing of game content such as techs, buildings, ship parts.

Moderators: Oberlus, Committer

Post Reply
Message
Author
User avatar
Grummel7
Space Dragon
Posts: 335
Joined: Mon Oct 09, 2017 3:44 pm

Fun with starlanes

#1 Post by Grummel7 »

Some time ago I opened an issue at github, including this picture:
LongStarlane.png
LongStarlane.png (101.42 KiB) Viewed 1064 times
Yesterday I found much bigger problem: Star Lane Nexus can actually remove existing star lanes!

Then I started digging. As far as I understand the code, this is what is done:

Starlane Bore avoids, amongst others, star lanes that meet at less than roughly 30°.
I think this explains why the bore from winter did not link to the seemingly obvious open space node. I still do not know why it did not link to Bashkar instead. Still there may be a reason and the issue is actually just a documentation one. There is also a minor issue that Starlane Bore always says a new link has been created, even if it failed to do so.

Starlane Nexus first removes all existing lanes to the system, than creates all star lanes that follow the rules of a Starlane Bore and are not longer than 250uu
There are two problems with this:
  1. Since the 30°-rule is not used during universe creation, an existing link may not be re-created
  2. The script checks only against all other links, so some of the nexus created links may be very close to each other.
BadNexus.png
BadNexus.png (253.63 KiB) Viewed 1064 times
I suggest to change Starlane Nexus so that does keep the existing lanes and creates one lane after the other, following the rules of Starlane Bore. I.e. it creates the shortest possible lane that does not violate any rules, than does it again and again, until no new one can be added. I would even prefer to remove the length limit, so that Nexus simply does the same as if you build a lot of Star Lane Bores at once.

I also wonder whether it would make sense to apply the 30°-rule during Universe, too.

Finally, the Experimentor may also create weird lanes, but I think that fits them well...

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 13586
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: Fun with starlanes

#2 Post by Geoff the Medio »

Grummel7 wrote: Fri Dec 03, 2021 7:17 pmI suggest to change Starlane Nexus so that does keep the existing lanes and creates one lane after the other, following the rules of Starlane Bore [...] until no new one can be added
I think the problem is that the effects are applied to all target systems simultaneously. So it's not possible to script a loop with an "until" condition. A workaround might be to remove the RemoveStarlanes effect, and instead have about 20 copies of AddStarlane that each pick a single viable candidate object (using NumberOf to pick one randomly or reproducibly). If there are no viable candidates, then it would do nothing and move to the next attempt.
I also wonder whether it would make sense to apply the 30°-rule during Universe, too.
Universe generation has its own somewhat-more complicated rules for lane placement based on Delauney triangulation of the star locations for possible lanes, and then some additional filters based on potential lanes being too long or too angularly close (with the longer of a pair of conflicting lanes being then removed). This is implemented a bit different from during-the-game lane acceptability tests, which are based on existing lanes and a candidate new lane which is accepted or rejected, but which won't remove the existing lane as part of that test. It also uses a higher max dot product between the normalized lane vectors, 0.98 instead of 0.87 for the effect test. This restriction can be more relaxed since the triangulation has already filtered the candidate lanes to be not angularly closer than necessary, which isn't done during the game.

User avatar
Grummel7
Space Dragon
Posts: 335
Joined: Mon Oct 09, 2017 3:44 pm

Re: Fun with starlanes

#3 Post by Grummel7 »

Geoff the Medio wrote: Fri Dec 03, 2021 11:04 pm I think the problem is that the effects are applied to all target systems simultaneously. So it's not possible to script a loop with an "until" condition. A workaround might be to remove the RemoveStarlanes effect, and instead have about 20 copies of AddStarlane that each pick a single viable candidate object (using NumberOf to pick one randomly or reproducibly). If there are no viable candidates, then it would do nothing and move to the next attempt.
I know I cannot do it as loop, adding 11 copies of a macro was exactly what I had in mind. 11 is enough while the 30° is in place.

I intend to pick closet possible one in each iteration, just like a single star lane bore would do. That makes the result reproducible, too.

I'll prepare a pull request. Btw, is there a reason why https://github.com/freeorion/freeorion/pull/3604 is still open?

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 13586
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: Fun with starlanes

#4 Post by Geoff the Medio »

Grummel7 wrote: Sat Dec 04, 2021 9:02 pm...is there a reason why https://github.com/freeorion/freeorion/pull/3604 is still open?
I've had limited time in the last month or so, and will for the next few days / week or so. After that I should have a chance to look at some older pull requests that have lacked adequate attention...

NaIch
Space Krill
Posts: 7
Joined: Wed May 03, 2017 7:58 pm

Re: Fun with starlanes

#5 Post by NaIch »

I read some threads about starlanes recently. It seems it comes down to "where will my new starlane will go to?" most of the time. I have 2 thoughts about that i want to throw into discussion:

1) Could the "CanAddStarlanesTo" - condition be placed in the EnqueueLocation - section? If none can be added to the actual location you cant queue a starlanebore (or an nexus) in the first place. You probably dont need a "starlane construction failed" - message anymore as was discussed somewhere. I tried to do that in the focs but i'm to dull it seems...

Update
The following lines in the focs seem to work to some degree. By playing around with the distance value the bores can be queued or not. But it seems to me if the code checks if a starlane with this min length can be created anywhere in the empire. So all spots or none of them can actually queue the bores. Some hints would be much appreciated...

BuildingType
name = "BLD_STARLANE_BORE"
description = "BLD_STARLANE_BORE_DESC"
buildcost = (200 + 50 * Target.System.NumStarlanes) * [[BUILDING_COST_MULTIPLIER]]
buildtime = 2
location = And [
Planet
OwnedBy empire = Source.Owner
Not Contains Building name = "BLD_STARLANE_BORE"
Not Contains Building name = "BLD_STARLANE_NEXUS"
Not Enqueued type = Building name = "BLD_STARLANE_BORE"
Not Enqueued type = Building name = "BLD_STARLANE_NEXUS"
]
EnqueueLocation = And [
Number low = 1 condition = And [
System
WithinDistance distance = 37 condition = Source
CanAddStarlanesTo condition = Source
]
]
effectsgroups = [...


2) Could the check where the new starlane will go to be performed after the first production turn (or even better by the time the bore is queued - if that dont mess things up)? The new starlane could be created on the map as a (inoperational) render-dummy shown in different color or something. This way you could see immediately where your new starlane will go to. The render-dummy ist replaced by the final starlane upon its creation. I dont know if that would work for multiple starlanes under construction at once (or the nexus) but i think it should because the creation works fine. Maybe the bore should be restricted to one per time per location in the EnqueueLocation - section. It makes sense anyway for me because the bore ist supposed to get more expensive and take longer to construct with every starlane added to a system. The last part can be scripted in the focs but i have no clue how to do that for multiple-world-systems.

User avatar
Grummel7
Space Dragon
Posts: 335
Joined: Mon Oct 09, 2017 3:44 pm

Re: Fun with starlanes

#6 Post by Grummel7 »

Hi Nalch,

Good thinking in principle, but I see some problems:

1a) When fighting Experimentors, I sometimes intentionally enqueue a Bore or even a Nexus, although I cannot create a additional lane right now.
1b) A bore may also fail because some other planet has finished a bore before, possible even build by another player, which means that your client doesn't even know it is being built.

2a) Well, first of all, such a dummy would need to be added as a new GUI feature. That's not exactly my expertise.
2b) Adding such a dummy on the global map would give information to other players that they should not have.

The dummy could possibly been done as a feature that is only visible to the player that builds the bore, but I suspect that it would be too much effort.

The Not Contains/Enqueued stuff should be moved to EnqueueLocation. If Location yields false while the building is enqueued, it will never receive any PP.

Enqueuing it once per System? Not sure this would be a good idea, but I think it should be something like (haven't check it):

Code: Select all

    enqueuelocation = And [
       Planet 
       Number
           low = 0
           condition = And [
               Planet
               InSystem id = LocalCandidate.SystemID
               Contains Building name = "BLD_STARLANE_BORE"
               Contains Building name = "BLD_STARLANE_NEXUS"
               Enqueued type = Building name = "BLD_STARLANE_BORE"
               Enqueued type = Building name = "BLD_STARLANE_NEXUS"
           ]
       ]
Or perhaps check it per player, to avoid one player enqueuing and pausing a Starlane Bore to prevent another from building one in the same system :mrgreen:

NaIch
Space Krill
Posts: 7
Joined: Wed May 03, 2017 7:58 pm

Re: Fun with starlanes

#7 Post by NaIch »

Hi Grummel,

i see, i didnt catch some points...
1a) When fighting Experimentors, I sometimes intentionally enqueue a Bore or even a Nexus, although I cannot create a additional lane right now.
=> Because linking starlanes get deleted - you are right...
1b) A bore may also fail because some other planet has finished a bore before, possible even build by another player, which means that your client doesn't even know it is being built.
=> Correct. But does that happen frequently? And you would not lose more compared to what it is now...
2a) Well, first of all, such a dummy would need to be added as a new GUI feature. That's not exactly my expertise.
=> Not a simple scripting thing indeed. Thats why i was'nt sure if i should mention that at all. But the chance to get that in the game was to tempting :mrgreen:
2b) Adding such a dummy on the global map would give information to other players that they should not have.
=> There are different ways to see that. One side wants to perform surprise attacks this way others have strategic plans in plans if that could be seen (forcing an enemy to weaken one front by opening up a second one; ability to counter surprise attacks by having some turns to respond at least...) To which side i personaly belong to depends at (and changes with) situation.
The dummy could possibly been done as a feature that is only visible to the player that builds the bore, but I suspect that it would be too much effort.
=> Think the effort would not be worth it too. Things should be kept as simple as possible. The team here is doing an amazing job by the way!
The Not Contains/Enqueued stuff should be moved to EnqueueLocation. If Location yields false while the building is enqueued, it will never receive any PP.
=> I wondered what the diffence would be because i've seen same conditions in both sections - sometimes in the same file. I read the tutorials but how apply that is somewhat still a miracle to me. :?
Or perhaps check it per player, to avoid one player enqueuing and pausing a Starlane Bore to prevent another from building one in the same system :mrgreen:
=> I see i'm still playing too nice...

NaIch
Space Krill
Posts: 7
Joined: Wed May 03, 2017 7:58 pm

Re: Fun with starlanes

#8 Post by NaIch »

After heavy use of history analyzer on this forum and a lot of try and error i finally succeeded in breeding a seemingly working code. I tested it on a save but not in real game. It lets you enqueue bores and nexus' only if
- no bore or nexus is queued on any planet in system (tested - ok)
- no bore or nexus is present on any planet in system (tested indirectly by substituting bore and nexus with buildings completed on the planets of my save)
- the ownedby - condition was not tested because i had no systems with splitted ownership in my save; should be working though
- systems to be connected are in range (tested - ok)
=> the distance can be adjusted to one's prefences
=> remember - the enqueue - conditions have been tested, i did not build the starlanes actually
Maybe someone finds this useful.

Code: Select all

	location = Planet
	EnqueueLocation = And [
		Planet
		OwnedBy empire = Source.Owner
		Number low = 0 high = 0 condition = And [
			Planet
			OwnedBy empire = Source.Owner
			Containedby And [
				System
				Contains RootCandidate
			]
			Or [
				Contains Building name = "BLD_STARLANE_BORE"
				Contains Building name = "BLD_STARLANE_NEXUS"
				Enqueued
					type = Building
					name = "BLD_STARLANE_BORE"
					low = 1
				Enqueued
					type = Building
					name = "BLD_STARLANE_NEXUS"
					low = 1
			]
		]
		Number low = 1 condition = And [
			System
			WithinDistance distance = 100 condition = And [
				System
				Contains RootCandidate
			]
			CanAddStarlanesTo condition = And [
				System
				Contains RootCandidate
			]
		]
	]
	effectsgroups = [

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 13586
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: Fun with starlanes

#9 Post by Geoff the Medio »

NaIch wrote: Wed Jan 26, 2022 4:37 pm
Or perhaps check it per player, to avoid one player enqueuing and pausing a Starlane Bore to prevent another from building one in the same system :mrgreen:
=> I see i'm still playing too nice...
Checking per-player rather than considering enqueued stuff by any / all players also prevents some potential issues where the client-side UI lets one enqueue something because it doesn't know about a conflicting thing on another player's queue, but then the enqueue fails on the server due to the conflict that is only apparent when the full gamestate is known. Might or might not be an issue with the present game mechanics, but could be a confusing issue longer-term even if not now.

Also, if making such restrictions, some adjustment to make the conflicting buildings readily visible to other players is probably needed, otherwise the same issue could arise with hidden already-completed buildings by other players that exist on the turn a player tries to enqueue one of their own.

User avatar
Grummel7
Space Dragon
Posts: 335
Joined: Mon Oct 09, 2017 3:44 pm

Re: Fun with starlanes

#10 Post by Grummel7 »

NaIch wrote: Wed Jan 26, 2022 4:37 pm
1b) A bore may also fail because some other planet has finished a bore before, possible even build by another player, which means that your client doesn't even know it is being built.
=> Correct. But does that happen frequently? And you would not lose more compared to what it is now...
That part wasn't well written. You said maybe we would not even need the SitRep for Failure and I wanted to point out that we would need it anyway, that's all.
NaIch wrote: Wed Jan 26, 2022 4:37 pm
The Not Contains/Enqueued stuff should be moved to EnqueueLocation. If Location yields false while the building is enqueued, it will never receive any PP.
=> I wondered what the diffence would be because i've seen same conditions in both sections - sometimes in the same file. I read the tutorials but how apply that is somewhat still a miracle to me. :?
Well, we just had a discussion about that point.
At the moment, location must be true when production is assigned to a project, while both must be true for enqueuing it. And yes, the Scripts do contain some redundancies.

Post Reply