[humor]The first ever player-built (huge) planetary settlement in ED universe! =)
- Thread starter djadjok
- Start date
Is it an attempt of naming the city? Hmm, a good one, btw. As I've said estimated amount of skimmers there - initially - was about
Last edited:
Animated gif of the first stage of construction (timelapse):
800x600 (~20 Mb)
http://i.imgur.com/ETfntzy.gifv
640x480 (~13 Mb)
(http://i.imgur.com/iVLdN5o.gifv)
I'll add this later to the fist post
800x600 (~20 Mb)
http://i.imgur.com/ETfntzy.gifv
640x480 (~13 Mb)
(http://i.imgur.com/iVLdN5o.gifv)
I'll add this later to the fist post
Last edited:
some more screenshots (for history)
"blue circles" above construction:
example of goodies
and a proper way to scan a DAP
Commander Nick Sticks and me after successful experiment of the "keeper role" transfer:
"Dungeon Keepers" on duty
I've made it=)
The City and it's keeper=)
Farewell, the city-mirage on Kumay
And yes, I must inform the community that after more than 48 hours of existence in "Open" ED Universe reality - and all the necessary tests performed by all participating commanders - the site has been voluntary shut down/disposed by the keeper.
"blue circles" above construction:
example of goodies
and a proper way to scan a DAP
Commander Nick Sticks and me after successful experiment of the "keeper role" transfer:
"Dungeon Keepers" on duty
I've made it=)
The City and it's keeper=)
Farewell, the city-mirage on Kumay
And yes, I must inform the community that after more than 48 hours of existence in "Open" ED Universe reality - and all the necessary tests performed by all participating commanders - the site has been voluntary shut down/disposed by the keeper.
Last edited:
Epic stuff - seeing something truly innovative in Elite is a rare thing these days!
Love it!
Love it!
@djadjok
I very much enjoyed my visits to your city. I'm pleased to say that on my last visit I left with no accessible skimmers alive (there were still a few hiding underground - I guess they'd heard the rumours of a skimmer killer doing the rounds).
I saw mention somewhere of a dancing Eagle, and maybe a video?
I'd very much like to see that if you have it! I have my side of the dance, but from the cockpit it doesn't look very interesting. I was actually trying to persuade the NPC into the planet, but it was having none of it. I did find it quite funny when I managed to steal it's preferred place, as then it simply danced around me as I watched!
By the way - your proper way to scan a DAP doesn't work in a Chieftain. I tried a couple of times, but it's simply too big. Much easier to approach from the side in a big(ger) ship. Or I need more practise...
I very much enjoyed my visits to your city. I'm pleased to say that on my last visit I left with no accessible skimmers alive (there were still a few hiding underground - I guess they'd heard the rumours of a skimmer killer doing the rounds).
I saw mention somewhere of a dancing Eagle, and maybe a video?
I'd very much like to see that if you have it! I have my side of the dance, but from the cockpit it doesn't look very interesting. I was actually trying to persuade the NPC into the planet, but it was having none of it. I did find it quite funny when I managed to steal it's preferred place, as then it simply danced around me as I watched!By the way - your proper way to scan a DAP doesn't work in a Chieftain. I tried a couple of times, but it's simply too big. Much easier to approach from the side in a big(ger) ship.
Or I need more practise...Note!!! this post doesn't contain real spoilers however I use spoiler tags to make further navigation in this "longread"-style article a bit easier.
Dja Co-P Mapping Service here, reporting:
Encoded transmission begins:------------------------------------------------------------------------------
Intermediate report of our current research activity state and detailed analysis of the multiple "Search Zone" (SZ) instance generation mechanics (SIMESZ method), overview of its possible applications in a cooperative approach to overcome some game-imposed unwelcome scenarios (so called "grinding") and a preliminary project of a proposal to the independent pilots.
Acknowledgements: I would like to thank all participants of The First Great Planetary Expedition (FGPE) - where this project was originally started - for all the helpful hints, fruitful discussions (support) and inspirational atmosphere, in particular - commander Alec Turner as the expedition head-master and the provided possibility to use the environment of the dedicated FGPE discord server, commander Tyrope as the first who have reacted to the "call for assistance" and with whom we have observed SZ-multiplication phenomena for the very first time, commander Kiwi Rob as the co-author of the second attempt, commanders Nick Sticks, Crank Larson and AltoOrbita for all the collaborative tests performed on the 4th construction site. Without your support, commanders, this project would be never possible! o7
Cmdr Dja
Introduction
First of all we must admit that "The first ever player-built (huge) planetary settlement in ED universe" and all the screenshots presented in this thread - are not the final goal of the on-going investigation but rather a "fun" sideproduct of a more profound and long-thinked attempt to grope more effective legal way/walk-around to overcome some well known situations when the present state of the game universe imposes on the independent commanders necessity to perform personally boring repetitive ("grinding") tasks. And we hope that the method described below is one of that ways. More also this approach by its nature is usable only as strictly co-operative solution and can be beneficial only in that case, adds more playability and diversity to the existing game universe and one can say even fells good into the announced trend of "quality of life" improvements that we can all observe during recent official game updates.
Part I. Our research scope
Chapter 1.1 Object study history review
Chapter 1.2. Search zone contact
Chapter 1.2. Proof of concept
Part II. Building a planetary settlement - SIMESZ method. Step-by-step guide, our recommendations and some hints on how to use the result.
Chapter 2.1 Pre-requirements
As an additional recommendation (not a requirement) in order to have more freedom on the upcoming construction stage we can advice for "the hunter" commander to obtain more than one semi-persistent SZ contact (we usually operate with 3-4 of them).
Chapter 2.2 Selection criteria for an appropriate construction site placement
Chapter 2.3 Building the city
Chapter 2.4 Known limitations and how to avoid some of them.
Chapter 2.4 Visiting the City. Helpful Hints and Tips for tourists.
Part III. The project of a proposal to ED community
o7, commanders!
Dja Co-P Mapping Service
------------------------------------------------------------------------------Encoded transmission ends.
Appendix A: VERY IMPORTANT NOTE:
I will be very pleased if anyone from the official FD team can approve/confirm that all the above mentioned in-game mechanics and announced proposals of their utilization are not in any way possible contradiction with the official policy or ToF (otherwise any further on-topic discussion will be meaningless and as so will be aborted). My personal view of the things is that even if one can - only probably - find something contradictive then the possible positive outcome overweight negative consequences if any (and all that without any additional effort from the developers team).
Appendix B: Related materials
1) this thread .
2) Most of the runtime investigation-related materials and log journal has been published in the #side-activities channel on the official FGPE Discord server
3) our final report in the FPGE thread on the official forum
Appendix C: Contact me
I'm available here and on quite a few ED-related Discord servers as "Dja"
If you are interested in SZ-related investigation, have questions on SIMESZ method or you have some fresh ideas - feel free to contact me there or send a PM
And if someone want to build its own city using the same approach I will be glad if they will share their work, screenies and observations
Dja Co-P Mapping Service here, reporting:
Encoded transmission begins:------------------------------------------------------------------------------
Intermediate report of our current research activity state and detailed analysis of the multiple "Search Zone" (SZ) instance generation mechanics (SIMESZ method), overview of its possible applications in a cooperative approach to overcome some game-imposed unwelcome scenarios (so called "grinding") and a preliminary project of a proposal to the independent pilots.
Acknowledgements: I would like to thank all participants of The First Great Planetary Expedition (FGPE) - where this project was originally started - for all the helpful hints, fruitful discussions (support) and inspirational atmosphere, in particular - commander Alec Turner as the expedition head-master and the provided possibility to use the environment of the dedicated FGPE discord server, commander Tyrope as the first who have reacted to the "call for assistance" and with whom we have observed SZ-multiplication phenomena for the very first time, commander Kiwi Rob as the co-author of the second attempt, commanders Nick Sticks, Crank Larson and AltoOrbita for all the collaborative tests performed on the 4th construction site. Without your support, commanders, this project would be never possible! o7
Cmdr Dja
Introduction
First of all we must admit that "The first ever player-built (huge) planetary settlement in ED universe" and all the screenshots presented in this thread - are not the final goal of the on-going investigation but rather a "fun" sideproduct of a more profound and long-thinked attempt to grope more effective legal way/walk-around to overcome some well known situations when the present state of the game universe imposes on the independent commanders necessity to perform personally boring repetitive ("grinding") tasks. And we hope that the method described below is one of that ways. More also this approach by its nature is usable only as strictly co-operative solution and can be beneficial only in that case, adds more playability and diversity to the existing game universe and one can say even fells good into the announced trend of "quality of life" improvements that we can all observe during recent official game updates.
Part I. Our research scope
Chapter 1.1 Object study history review
Let us note that the Search Zones phenomena and related mechanics were already at least once under the scope of our research interests few years ago - at the time they were firstly introduced in this universe. However concurrently there were other active on-going investigations and that of SZ was not of a top priority. So to mark the starting point of the present investigation here we would like to directly cite our own message text from 14/04 at the official FGPE Discord server (reposting it here for historical reason for anyone interested):
Without entering too much in detailed description of all events that followed our "call for assistance", one day later - 15/04 at 18:30 - we have met and joined our efforts together with commander Tyrope piloting Anaconda-class vessel, designation TYR-Annie, near the what has been referred later as "1st construction site" at Kumay Bermuda Triangle (area formed by three mountainous massifs at NE from O'Donnell Settlement) and after some brief on-field research we were presented with this quite unexpected - for both of us - view:
"But wait, there's... more?" - as it was very appropriately described by commander Tyrope.
Unfolded landscape with some recognizable features but in an unexpected quantities were really surprising as my original intent was just to study the possibility to transfer visible to me semi-persistent SZ:H contact from my ship navigation system appliances to any other commander in proximity. While the outcome of our original attempt "to transfer" or "share" in any way possible was negative the newly discovered phenomena was very promising.
Second attempt to reproduce this effect has been done shortly at the same location in collaboration with commander Kiwi Rob and was only partly successful when interrupted by instancing-related issues that start to interfere with our experiment when we have obtained already 6 copies of the test subject.
After that our research has been temporarily suspended due to our other responsibilities and on-going tasks, and our team have managed to return to it only after our expedition scarab has crossed the official finish line in Bridger Town. However at that moment the original contact with the 1st construction site has been already lost from my navigational system (* most probably didn't survive the April 23 update*).
Encoded transmission begins:------------------------------------------------------------------------------
Processing attached files... Decoding data...
...For all Commanders in the area, Dja Co-P Mapping Service here, we call for assistance.
I repeat, here is Dja Co-P Mapping service, we call for assistance. This is a search and reconnaissance operation. For all Commanders in the area - onboard of their ships or driving SRV's on the following sections of the route - Raccoon Ridge - Blue Powder Gap -O'Donnell Settlement - please check your navigational computers for any anomalous zones in 250 km proximity area. If nothing reported, please proceed to the following coordinates using any available transport suitable for reconnaissance tasks:
Chi Herculis, Kumay
Latitude: 63.7
Longitude: 151.2
Our intelligence reports a civilian object with elevated security level in that area, suspected being overtaken by criminal elements with unidentified goals . Due to signal jamming our agent cannot transmit exact coordinates, so perform the search in 10 km radius of the given coordinates. If successful, do not interfere and try to not advertise your presence. Object remains under formal control of Chi Herculis Creative Group and they do not want publicly disclose the situation, so defense perimeter violation and any attempt of scanning of private access points will be punished on the system level.
Dja Co-P Mapping Service here, we call for assistance, check attached files for further details
------------------------------------------------------------------------------Encoded transmission ends.I repeat, here is Dja Co-P Mapping service, we call for assistance. This is a search and reconnaissance operation. For all Commanders in the area - onboard of their ships or driving SRV's on the following sections of the route - Raccoon Ridge - Blue Powder Gap -O'Donnell Settlement - please check your navigational computers for any anomalous zones in 250 km proximity area. If nothing reported, please proceed to the following coordinates using any available transport suitable for reconnaissance tasks:
Chi Herculis, Kumay
Latitude: 63.7
Longitude: 151.2
Our intelligence reports a civilian object with elevated security level in that area, suspected being overtaken by criminal elements with unidentified goals . Due to signal jamming our agent cannot transmit exact coordinates, so perform the search in 10 km radius of the given coordinates. If successful, do not interfere and try to not advertise your presence. Object remains under formal control of Chi Herculis Creative Group and they do not want publicly disclose the situation, so defense perimeter violation and any attempt of scanning of private access points will be punished on the system level.
Dja Co-P Mapping Service here, we call for assistance, check attached files for further details
Processing attached files... Decoding data...
Decoding data...Part 1
This can be kind of a "side-quest" for anyone interested.
Ok, now the real reason for all this story. In fact I'd like to use this opportunity to check some game mechanics, in this case - level of persistency/randomness of "search zones" generation. Kind of "in-game science" - but not related to Guardians/Thargoids or any other classic ED "mysteries". The results can help to better understand the game, or bring some points, for example, to the theory of the maintained instance (mentioned by commander @Tyrope).
Here is my part of the story - nearby a week ago - don't remember exactly - a "search zone: habitation" (SZH) has appeared in my nav.point list. I have no missions in my agenda, have accepted none of that spamming my in-game mailbox. At the beginning that one was also ignored - even that was a bit tempting me being only 100 km away when I was at Raccoon Ridge - Blue Powder Gap route leg. Finally the next day after my planned stop at O'Donnel I've decided to do the trip (214 km) to this SZH that have remained in my list even after some days (and some relogging/reinstancing). Earlier, I assumed that their generation is quite random so the fact that it still persist have started to intrigue me.
Decoding data...Part 2
On my way there I accidently blown my SRV. When I regained consciousness on board of my ship SCZ entry was still present. However when I've undocked my SRV it has disappeared and I was quite disappointed (100 km for nothing). I've started to drive using my last heading - don't know why, really - and after couple of kilometers the signal reappeared once again! 120 km later I've finally arrived to my destination - yep, there was well known "search-zone" mini-game but destination "jumps" were not as large as when using ship - in fact I've corrected my course only once for about 15 degrees. Nothing fancy, standard "search zone: habitation". Couple of "Wanted" skimmers + restricted zone + private data point. Skimmers can be destroyed without problems, however trespassing or scanning can result in fines and bounties (my case).
Decoding data...Part 3
Ok, the same day I left Kumay and Chi Hercules system in order to clear bounties, returned the next day - and the earlier founded installation still persists. Relogged in Solo mode - still there. Following days I revisited that site for yet 3 or 4 times - still there, however the exact coordinates variates slightly - about half degrees (couple of times there I was involved in similar "search zone" jumping game).
During our last meetup at the NP SCZ was absent from my navigation list, but when I've returned in proximity signal has reappeared (some kind of max distance?).
And now I want to establish if it's visible/presented only for me or also for other commanders? Is it depends on my own proximity to the destination? Any help appreciated.
This can be kind of a "side-quest" for anyone interested.
Ok, now the real reason for all this story. In fact I'd like to use this opportunity to check some game mechanics, in this case - level of persistency/randomness of "search zones" generation. Kind of "in-game science" - but not related to Guardians/Thargoids or any other classic ED "mysteries". The results can help to better understand the game, or bring some points, for example, to the theory of the maintained instance (mentioned by commander @Tyrope).
Here is my part of the story - nearby a week ago - don't remember exactly - a "search zone: habitation" (SZH) has appeared in my nav.point list. I have no missions in my agenda, have accepted none of that spamming my in-game mailbox. At the beginning that one was also ignored - even that was a bit tempting me being only 100 km away when I was at Raccoon Ridge - Blue Powder Gap route leg. Finally the next day after my planned stop at O'Donnel I've decided to do the trip (214 km) to this SZH that have remained in my list even after some days (and some relogging/reinstancing). Earlier, I assumed that their generation is quite random so the fact that it still persist have started to intrigue me.
Decoding data...Part 2
On my way there I accidently blown my SRV. When I regained consciousness on board of my ship SCZ entry was still present. However when I've undocked my SRV it has disappeared and I was quite disappointed (100 km for nothing). I've started to drive using my last heading - don't know why, really - and after couple of kilometers the signal reappeared once again! 120 km later I've finally arrived to my destination - yep, there was well known "search-zone" mini-game but destination "jumps" were not as large as when using ship - in fact I've corrected my course only once for about 15 degrees. Nothing fancy, standard "search zone: habitation". Couple of "Wanted" skimmers + restricted zone + private data point. Skimmers can be destroyed without problems, however trespassing or scanning can result in fines and bounties (my case).
Decoding data...Part 3
Ok, the same day I left Kumay and Chi Hercules system in order to clear bounties, returned the next day - and the earlier founded installation still persists. Relogged in Solo mode - still there. Following days I revisited that site for yet 3 or 4 times - still there, however the exact coordinates variates slightly - about half degrees (couple of times there I was involved in similar "search zone" jumping game).
During our last meetup at the NP SCZ was absent from my navigation list, but when I've returned in proximity signal has reappeared (some kind of max distance?).
And now I want to establish if it's visible/presented only for me or also for other commanders? Is it depends on my own proximity to the destination? Any help appreciated.
Without entering too much in detailed description of all events that followed our "call for assistance", one day later - 15/04 at 18:30 - we have met and joined our efforts together with commander Tyrope piloting Anaconda-class vessel, designation TYR-Annie, near the what has been referred later as "1st construction site" at Kumay Bermuda Triangle (area formed by three mountainous massifs at NE from O'Donnell Settlement) and after some brief on-field research we were presented with this quite unexpected - for both of us - view:
(screen 04/15) Triple instance of SZH
"But wait, there's... more?" - as it was very appropriately described by commander Tyrope.
Unfolded landscape with some recognizable features but in an unexpected quantities were really surprising as my original intent was just to study the possibility to transfer visible to me semi-persistent SZ:H contact from my ship navigation system appliances to any other commander in proximity. While the outcome of our original attempt "to transfer" or "share" in any way possible was negative the newly discovered phenomena was very promising.
Second attempt to reproduce this effect has been done shortly at the same location in collaboration with commander Kiwi Rob and was only partly successful when interrupted by instancing-related issues that start to interfere with our experiment when we have obtained already 6 copies of the test subject.
Second attempt - 6 "exposures"
After that our research has been temporarily suspended due to our other responsibilities and on-going tasks, and our team have managed to return to it only after our expedition scarab has crossed the official finish line in Bridger Town. However at that moment the original contact with the 1st construction site has been already lost from my navigational system (* most probably didn't survive the April 23 update*).
Chapter 1.2. Search zone contact
So far we know that the "search zones" - as designed entities - can be differentiated by the limited amount of "naming" notations, visible in the navigation pane (i.e. "habitation", "shelter", "hidden stash", "crash site traces", etc) - and this information level is available to commander at the moment of the contact appearance. However the next level of information - "sub-variation" of a given type of the SZ - if there are any - can be so far uncovered only after the first visit to the given area (and obligatory "search" mini-game). The usage of the additional sub-classification of SZ "named" types is dictated by the necessity to distinguish between, for example, "unprotected" sub-variation of "habitation" type (with no restricted area, no skimmers, "public" DAP and 5 canisters of biowaste) and its "protected" variant which - while having the same contact "name" - "habitation" - have some only slight visual and quite important functional differences - there are 2 sentry skimmers present, restricted zone, much more valuable commodities, DAP is in private access only (and one can also suppose non-negligible differences in the distribution of the engineering material grades of "data" class as the scan results). Our investigation shows that the particular SZ contact can produce only one given sub-variation - no case of mixing different sub-variations so far were observed in the same SZ-area. Also this means in other words that a given sub-variation has the same level of persistence as its parent contact. However we must note, that in case of "protected" sub-variations their defenders, while evidently being owned by the same faction, can have either "wanted" or "clean" status and that can differ from one "exposed" SZ instance to another. Also we can mention that so far we do not see any contradictions that there can be a method - at least in theory - to predict particular sub-variation at the same time as the corresponding named contact becomes available.
So far two general methods to obtain that said SZ contact are known. The most evident one is to get - directly or by incoming request - an appropriate mission from the local factions/authorities. However up to now our research efforts were mostly concentrated on the study of the second approach - SZ contact spontaneous appearance in the nav.panel while the observer is on or in proximity of a planetary surface (on board of a ship or telepresented in an SRV). This study was aggravated by our partial incompetence as so far we are not aware of any visual or audio notifications available HUD-wise of that said appearance (beside regular check of planet-wise POI listing).
Overall we have invested quite a significant amount of research time in order to grope any factors, conditions or events that can be responsible for that said contact appearance (or leading to its obsolescence) and its persistency attribute - i.e. conditions to remain in the POI list of our observer upon its
Also on obtaining 3-5 semi-persistent contacts for a given planet a study of on-surface SZ coordinates distribution was performed (hoping to unfold any cases of potential attractors or other types of irregularities). However we must admit that we haven't achieved any breaking advances in that direction, and, while those questions reside under the scope of our research interests they are far out of the frame of the present article.
illustration will be added later
So far two general methods to obtain that said SZ contact are known. The most evident one is to get - directly or by incoming request - an appropriate mission from the local factions/authorities. However up to now our research efforts were mostly concentrated on the study of the second approach - SZ contact spontaneous appearance in the nav.panel while the observer is on or in proximity of a planetary surface (on board of a ship or telepresented in an SRV). This study was aggravated by our partial incompetence as so far we are not aware of any visual or audio notifications available HUD-wise of that said appearance (beside regular check of planet-wise POI listing).
Overall we have invested quite a significant amount of research time in order to grope any factors, conditions or events that can be responsible for that said contact appearance (or leading to its obsolescence) and its persistency attribute - i.e. conditions to remain in the POI list of our observer upon its
1)re-logging/re-instancing,
2)using surface reconnaissance vessel,
3)entering/exiting supercruise or
4)even on travel to other neighboring star systems.2)using surface reconnaissance vessel,
3)entering/exiting supercruise or
Also on obtaining 3-5 semi-persistent contacts for a given planet a study of on-surface SZ coordinates distribution was performed (hoping to unfold any cases of potential attractors or other types of irregularities). However we must admit that we haven't achieved any breaking advances in that direction, and, while those questions reside under the scope of our research interests they are far out of the frame of the present article.
Chapter 1.2. Proof of concept
At that stage we have decided to repeat the experiment with SZ multiplication, or, more correctly, on Single-Instance Multiple-Exposure (copy) of the same SZ contact (SIMESZ). However this time our goal was not only an attempt to reproduce previously obtained results but also to achieve an esthetically attractive presentation of our work. So for the third attempt a site in Kumay Lowlands has been chosen. Resulting small SIMESZ-generated settlement served us as a good "proof of concept" from the scientific point of view, however we were not completely satisfied by the esthetic part. While being made using 30 "exposures"/(blocks) in total only 9 of them were clearly distinguishable by an external observer due to the fast shortage in unoccupied "placeholders" in the chosen area (so some placeholders were shared by multiple blocks). As we have said, the latter haven't reduced the functionality of the resulting 30xSZH settlement but we have decided to proceed for the next construction site in a more deserted area.
For our fourth attempt a site was chosen in 120 km to the West from geo#6 in the Desert of mirages. Using the resources of our Service the area (instance) has been locked and the construction using SIMESZ method has been started at 21:20 ///. As the base block an "exposure" of "Search Zone: Habitation" contact - in its protected variation - has been used (while esthetically correct this contact is not the best choice regarding functionality - however we have had no other opportunities at that moment). The resulting huge player-constructed settlement at its heyday consisted of 39-40 distinguishable buildings (and more than 100 real "exposures") taking an area about 20 km wide (some of the exposed blocks outside of this area has been lost due to limitations for one keeper's control capabilities). Primitive calculations allow us to estimate that this city 1) were "populated" by ~200 sentry skimmers (without taking into account a number of errant or landed NPC ships) - clear and wanted ones; 2)have contained in its store about 500 t of valuable commodities; 3)and last, but may be of the biggest application importance, have a quite developed network of dataaccess points (private, ~100 or same as building blocks) - waiting to gratify potential hackers with some decent-grade data and informing about new bounties for their heads.
The active phase of construction (adding blocks) has been stopped when two factors have started to really interfere with the process:
Upon construction some members of FGPE have visited the site and that has allow to conduct a set of coordinated experiments and gather more evidence and data on potential applications. More than 48 hours since the start of the construction - at.... - as all tests planned for this stage has been undertaken and finished - the site has been voluntarily abandoned (instance unlocked).
For our fourth attempt a site was chosen in 120 km to the West from geo#6 in the Desert of mirages. Using the resources of our Service the area (instance) has been locked and the construction using SIMESZ method has been started at 21:20 ///. As the base block an "exposure" of "Search Zone: Habitation" contact - in its protected variation - has been used (while esthetically correct this contact is not the best choice regarding functionality - however we have had no other opportunities at that moment). The resulting huge player-constructed settlement at its heyday consisted of 39-40 distinguishable buildings (and more than 100 real "exposures") taking an area about 20 km wide (some of the exposed blocks outside of this area has been lost due to limitations for one keeper's control capabilities). Primitive calculations allow us to estimate that this city 1) were "populated" by ~200 sentry skimmers (without taking into account a number of errant or landed NPC ships) - clear and wanted ones; 2)have contained in its store about 500 t of valuable commodities; 3)and last, but may be of the biggest application importance, have a quite developed network of dataaccess points (private, ~100 or same as building blocks) - waiting to gratify potential hackers with some decent-grade data and informing about new bounties for their heads.
The active phase of construction (adding blocks) has been stopped when two factors have started to really interfere with the process:
1) a remarkable drop in FPS;
2) Rarity of an event in the row of subsequent exposures of one taking a not already occupied place bypassed optimal level limits (at that time some distinguishable buildings were already overcharged by up to 5 real exposures).
2) Rarity of an event in the row of subsequent exposures of one taking a not already occupied place bypassed optimal level limits (at that time some distinguishable buildings were already overcharged by up to 5 real exposures).
Upon construction some members of FGPE have visited the site and that has allow to conduct a set of coordinated experiments and gather more evidence and data on potential applications. More than 48 hours since the start of the construction - at.... - as all tests planned for this stage has been undertaken and finished - the site has been voluntarily abandoned (instance unlocked).
Part II. Building a planetary settlement - SIMESZ method. Step-by-step guide, our recommendations and some hints on how to use the result.
Chapter 2.1 Pre-requirements
1. Populated star system with a non-atmospheric landable planet.
2. Two independent commanders that have no known issues in instancing with each other (that's said, commanders from distant time zones IRL are not the best match for this task). The best choice is to have both commanders in the same local area.
3. "Open" play mode or "Private Group" for both (the latter has so far was not tested but supposedly will also work). "Solo" doesn't work by the very nature of the described method.
Here let us denote for future reference that one commander will play the role of the instance "keeper" and the other one will be SZ "hunter". Both of them we will refer as "The Builders".2. Two independent commanders that have no known issues in instancing with each other (that's said, commanders from distant time zones IRL are not the best match for this task). The best choice is to have both commanders in the same local area.
3. "Open" play mode or "Private Group" for both (the latter has so far was not tested but supposedly will also work). "Solo" doesn't work by the very nature of the described method.
4. There is no special restrictions on the ships those commanders use to do their respective jobs, only recommendations. For the keeper - it must be capable to stay in-game in the normal space as long as it is required by the task (no re-logging, de-instancing or any-cause disconnecting, etc). So level of the keeper's ship "autonomy" must be taken into account (or other ways to ensure the latter - refueling, modules switching off, etc). For the hunter's ship some speed/agility is also a thing to take into account. Very much advised - no "lucrative" cargo in their cargo holds and "clean" status to avoid any possible problems with pirates and/or local authorities. Also one must take into account that the keepers ship must remain in the instance for hours - if not days (depending on goals). Even in the case of the most of the unnecessary modules switched off one risks to have the keeper on the limit of running out of the fuel. Preview some fuel limpets controller on the other ship (the hunter's by default) to be able to refuel the keeper.
5. The "hunter" must obtain at least one semi-persistent "Search Zone:" type contact in its navigation panel (by any means possible) for the given system/planet. Good question - how to do it, exactly? Let us devise this particular requirement in two parts:
In reality combining 5.1 and 5.2 means that as general recommendation the hunter must have one of the contacts in a very limited set of types of the search zones - "habitation", "shelter" (some others?). Sites like "hidden stash", "crash site traces" - and others, containing only commodity-type goodies - supposedly won't work. As a general rule - there must be something that remains undone/unfinished on the site - in the hunter's perspective - to make it reappear.5. The "hunter" must obtain at least one semi-persistent "Search Zone:" type contact in its navigation panel (by any means possible) for the given system/planet. Good question - how to do it, exactly? Let us devise this particular requirement in two parts:
5.1 The "hunter" must obtain a "Search Zone:" type contact. Ok, there are at least two ways to obtain one as we have already described in part I of this article. The obvious one - just get an appropriate mission (but we haven't tried this approach so cannot ensure that this will work in all cases). The second one - just wait or do something on/around planet surface. And let the force be with you....
5.2 Contact persistency. I.e. contact must persist in a given area on a given planet even upon hunter's session re-logging (at least). Oh, and this point implies quite more limitations even on the nature on that said contact. So far, basing on our experience: 1) the target search zone contact type must contain an object to scan (a DAP in general case); 2) the "hunter" must not "complete" the given mission (do not scan anything before the role completion). The latter cannot be a rule (we have encountered quite a number of exceptions). We must admit that these recommendations based mostly on our guesses than solid knowledge
5.2 Contact persistency. I.e. contact must persist in a given area on a given planet even upon hunter's session re-logging (at least). Oh, and this point implies quite more limitations even on the nature on that said contact. So far, basing on our experience: 1) the target search zone contact type must contain an object to scan (a DAP in general case); 2) the "hunter" must not "complete" the given mission (do not scan anything before the role completion). The latter cannot be a rule (we have encountered quite a number of exceptions). We must admit that these recommendations based mostly on our guesses than solid knowledge
As an additional recommendation (not a requirement) in order to have more freedom on the upcoming construction stage we can advice for "the hunter" commander to obtain more than one semi-persistent SZ contact (we usually operate with 3-4 of them).
Chapter 2.2 Selection criteria for an appropriate construction site placement
First of all this depends on the one's final goal and... luck.
Luck. By the latter we mean that in general case the "hunter" commander has no any control on where particular SZ contact will lead him. In either case he is just obliged to follow "The White Rabbit" - SZ contact target directions. Is it completely RNGesus work? (Remark: Not really, in case of particular planet and after conducting quite a number of test runs one can find at least the most probable - or attractive - areas for "SZ contact" target destinations). At present there is no known way to make appear a "SZ contact" target area at the given coordinates. One must deal with what he have got - and here works our earlier advice to get several contacts simultaneously.
Now assume that our "hunter" has finally found "The Rabbit's Hole" - i.e. arrived at SZ destination, played the search mini-game and got visual contact with the target - the first "exposure" of a given SZ contact. Now it's time to decide how good the given "construction site" fits the goals.
While the SIMESZ construction method will work with any semi-persistent SZ contact, the surrounding landscape and terrain difficulty must be taken into serious consideration to achieve better results. The in-game engine doesn't perform any additional terrain flattening procedure before "exposure"(placing) an SZ contact target so the landscape must already have enough flat terrain area or a sufficient number of flat spots of appropriate dimensions. If this conditions met then one can obtain quite a number of visually separated "exposures" of the given SZ, if no then while even having many "exposures" they will tend to be placed on already occupied places, creating "overcharged" ones. And the latter affect not only the visual aspect of the result - for example, one can obtain as many scannable datapoints as the "exposures" performed, yes, however the access to the "overcharged" ones quite more difficult. Due to some UI issues at the present moment only maximum of two can be separately accessible from the Navigation Panel/Contacts interface, targeting all remaining is a bit more tricky (beware that in a huge construction project even in ideal conditions the case of 4-5 times "overcharged" placements is quite a usual one).
Luck. By the latter we mean that in general case the "hunter" commander has no any control on where particular SZ contact will lead him. In either case he is just obliged to follow "The White Rabbit" - SZ contact target directions. Is it completely RNGesus work? (Remark: Not really, in case of particular planet and after conducting quite a number of test runs one can find at least the most probable - or attractive - areas for "SZ contact" target destinations). At present there is no known way to make appear a "SZ contact" target area at the given coordinates. One must deal with what he have got - and here works our earlier advice to get several contacts simultaneously.
Now assume that our "hunter" has finally found "The Rabbit's Hole" - i.e. arrived at SZ destination, played the search mini-game and got visual contact with the target - the first "exposure" of a given SZ contact. Now it's time to decide how good the given "construction site" fits the goals.
While the SIMESZ construction method will work with any semi-persistent SZ contact, the surrounding landscape and terrain difficulty must be taken into serious consideration to achieve better results. The in-game engine doesn't perform any additional terrain flattening procedure before "exposure"(placing) an SZ contact target so the landscape must already have enough flat terrain area or a sufficient number of flat spots of appropriate dimensions. If this conditions met then one can obtain quite a number of visually separated "exposures" of the given SZ, if no then while even having many "exposures" they will tend to be placed on already occupied places, creating "overcharged" ones. And the latter affect not only the visual aspect of the result - for example, one can obtain as many scannable datapoints as the "exposures" performed, yes, however the access to the "overcharged" ones quite more difficult. Due to some UI issues at the present moment only maximum of two can be separately accessible from the Navigation Panel/Contacts interface, targeting all remaining is a bit more tricky (beware that in a huge construction project even in ideal conditions the case of 4-5 times "overcharged" placements is quite a usual one).
Chapter 2.3 Building the city
Assuming that all previously mentioned requirement are met, appropriate construction site selected and the first SZ-exposure is already done it's time for "The Keeper" to enter the game. His main role it to keep/"lock" given game instance with all the construction taking place. He must be placed somewhere in or above the "center" of SZ "spawning" area and remain there during whole construction process plus all the lifespan of the given city or till his duty transferred to another commander (yes, that's "risky" but possible). He can migrate if the center (~centroid - the center of the "mass" of the "exposures" if you want) of the construction shifts a bit (probably will do as the new exposures can appear at quite a distance of about dozens kilometers).
Try to avoid moving the keeper to the edges of the site - we cannot guaranty good results in this case. In our practice during construction phase our keeper remains (and migrates with if necessary) above the center of the site and uses its external camera to keep traces of the whole process (very helpful in subsequent accounting). Beware that keepers possibilities to lock the exposures in the given instance have certain limits (have not measured, however it seems they are of the same order of magnitude as the maximum distance at which the keeper can at least theoretically "see" the given SZ exposure), so certain far-off "exposures" can fell out of this space. As a possible walk-around (we have not tested this approach) one can imagine using more than one keeper for the given construction site instance.
Once again we must underline here - "keeper" must never relog, disconnect or quit the "locked" instance by any means possible. Otherwise - "Everything will go back to how it was before" - you know - "carriage - back to the pumpkin, horses - back to the mice" and your city will simply vanish.
The process itself of SZ exposure is quite straightforward. The simplest way - the "hunter" must retire to a distance of approximately 5 km or more from previous exposure (or the first one in the very beginning), perform a relog - once again into the same instance as the keeper, select the presumably persistent "same" SZ contact and repeat the search mini-game in fact making appear the next subsequent "exposure". Then - "rinse and repeat" (oh, non, exactly no rinsing! It must remain "dirty"). Sounds simple? But in fact, it is.
If there was no new mini-game then something goes wrong. Supposedly the hunter have not retired sufficiently far. The keeper itself doesn't "see" the "search min-game" process, only the result. If the new exposure was placed on the already occupied area then it can be quite difficult to distinguish it from the keeper view (but it's not important).
The trickiest part here is that hunter on each iteration must re-enter the same instance as the keeper and the city are - and get the visual contact (ideally with both - keeper and the city). Joining them in a wing each time can help but is very time consuming if done repeatedly. During our second attempt of construction the hunter has had some problems of instancing with the keeper (if joined in the wing they were capable to see each other only on the radars, but not visually). However the keeper was still capable to see at least new exposures to appear from "nowhere" in front of him. While this still worked our advice to find a more matching pair of "builders" for this task in advance.
Also to prioritize a bit "good" - in builders perspective - decisions made by matchmaking servers it is better to avoid any other non construction-related commanders in the same area.
There were proposals to use super-cruise in place of re-log. While this approach can be less immersion breaking, our limited preliminary test shows that is also much less reliable and the positive results are not guaranteed (less repetitive). Take into account that this is also more time consuming.
Beware of a side effect of the "hunter" re-entering the construction site instance AFTER the construction phase has been "officially" done. Quite reasonably this will most probably result in one more "exposition" added to the site. We are not aware of any asserted way to stop this happening - "you've created a self growing monster" as one commander quite preciously remarked - beside when the hunter loose the original SZ contact. The hunter can try to "finish the business" (scan it, for example) by interacting with the last contact instance "exposed" (but there is no warranties, we have had at least one negative on that case).
Estimated construction time. If all preparations done then depending on the final goal - city size - construction can take from few dozens of minutes to several hours. Repetitive search-fly away-re-log sequence can be boring. Positive side - all subsequent "search mini-games" - when the "hunter" is already near the spawn point - pass semi-automatically and much faster (the game engine just moves the potential exposure in erratic manner somewhere beneath the hunter ship up to its final placement).
Try to avoid moving the keeper to the edges of the site - we cannot guaranty good results in this case. In our practice during construction phase our keeper remains (and migrates with if necessary) above the center of the site and uses its external camera to keep traces of the whole process (very helpful in subsequent accounting). Beware that keepers possibilities to lock the exposures in the given instance have certain limits (have not measured, however it seems they are of the same order of magnitude as the maximum distance at which the keeper can at least theoretically "see" the given SZ exposure), so certain far-off "exposures" can fell out of this space. As a possible walk-around (we have not tested this approach) one can imagine using more than one keeper for the given construction site instance.
Once again we must underline here - "keeper" must never relog, disconnect or quit the "locked" instance by any means possible. Otherwise - "Everything will go back to how it was before" - you know - "carriage - back to the pumpkin, horses - back to the mice" and your city will simply vanish.
The process itself of SZ exposure is quite straightforward. The simplest way - the "hunter" must retire to a distance of approximately 5 km or more from previous exposure (or the first one in the very beginning), perform a relog - once again into the same instance as the keeper, select the presumably persistent "same" SZ contact and repeat the search mini-game in fact making appear the next subsequent "exposure". Then - "rinse and repeat" (oh, non, exactly no rinsing! It must remain "dirty"). Sounds simple? But in fact, it is.
If there was no new mini-game then something goes wrong. Supposedly the hunter have not retired sufficiently far. The keeper itself doesn't "see" the "search min-game" process, only the result. If the new exposure was placed on the already occupied area then it can be quite difficult to distinguish it from the keeper view (but it's not important).
The trickiest part here is that hunter on each iteration must re-enter the same instance as the keeper and the city are - and get the visual contact (ideally with both - keeper and the city). Joining them in a wing each time can help but is very time consuming if done repeatedly. During our second attempt of construction the hunter has had some problems of instancing with the keeper (if joined in the wing they were capable to see each other only on the radars, but not visually). However the keeper was still capable to see at least new exposures to appear from "nowhere" in front of him. While this still worked our advice to find a more matching pair of "builders" for this task in advance.
Also to prioritize a bit "good" - in builders perspective - decisions made by matchmaking servers it is better to avoid any other non construction-related commanders in the same area.
There were proposals to use super-cruise in place of re-log. While this approach can be less immersion breaking, our limited preliminary test shows that is also much less reliable and the positive results are not guaranteed (less repetitive). Take into account that this is also more time consuming.
Beware of a side effect of the "hunter" re-entering the construction site instance AFTER the construction phase has been "officially" done. Quite reasonably this will most probably result in one more "exposition" added to the site. We are not aware of any asserted way to stop this happening - "you've created a self growing monster" as one commander quite preciously remarked - beside when the hunter loose the original SZ contact. The hunter can try to "finish the business" (scan it, for example) by interacting with the last contact instance "exposed" (but there is no warranties, we have had at least one negative on that case).
Estimated construction time. If all preparations done then depending on the final goal - city size - construction can take from few dozens of minutes to several hours. Repetitive search-fly away-re-log sequence can be boring. Positive side - all subsequent "search mini-games" - when the "hunter" is already near the spawn point - pass semi-automatically and much faster (the game engine just moves the potential exposure in erratic manner somewhere beneath the hunter ship up to its final placement).
Chapter 2.4 Known limitations and how to avoid some of them.
The visual size of the city and/or density of visually separated "exposures" is affected by the number of available reliably flat placeholders in the given area (from game engine point of view). The most crucial here is the initial good choice of the construction site territory.
Also the maintained construction area is limited by the keeper controlling limits. More than one keeper can be a possible walk-around to this limitation.
Now when the city grows and new "exposures" are added to it the total amount of objects/props/geometry(even if not visible)/actors also grows and can result in non-negligible FPS drop. This is inevitable at certain stage however there is number of ways to delay the moment when FPS drop will became unplayable/unsupportable or just simply annoying.
Evident way is to reduce the amount of geometry each individual "exposure" introduces to the site. And the most crucial is the initial selection of SZ contact type and its variation. As a general rule "non-protected" variations are less geometry/props charged than their "protected" analogs (that have skimmers and/or other defensive appliances). So, depending on goals, stick to the unprotected ones (the unprotected "shelter" variation is so far the best from utilitarian point of view).
Also take into account that during construction quite a number of random POI can (and surely will be) be generated in proximity. Many of them can be accompanied by NPC ships - parked or flying. Some of them just fly by peacefully, others... In fact during the construction process on the 4th site there was quite a battle there. That doesn't really perturbated the process itself but resulted in a big amount of ship wreckages that was "seen" and locked in the instance by the keeper (even if they were unseen by commanders visiting the site later or by the hunter). Anyway all this additional geometry - while being picturesque - can have quite an impact on the resulting FPS.
There is a (may be a bit "risky") method not to avoid but to free the given city instance from some "unwanted" garbage. This method is based on the "keeper's role transfer procedure" and gives quite a good results if also combined with a preceding "clean up" measures. By "clean up" measures we mean - destroying all (or most of) unnecessary actors - npc's, skimmers, commodities. Once that done in our case we have tried to pass the "keeper" role to the third commander visiting the site and becoming the "temporary" keeper. The hunter was already logged off, when the new keeper has arrived and has parked in the center then our old keeper also performed a complete log-off procedure (with client full shut down). On logging back in on the second attempt our keeper succeeded in re-entering the instance with the city. Then the "temporary" keeper has also logged out while our old-new keeper has remain in the instance - and as do the city. Before those measures the FPS for the keeper has already dropped below 30 (~23 even), after - once again returned to its max 60.
City maximum lifespan - is quasi-infinite. So far the keeper (the original or anyone who have inherited this role) stays on-duty. However here we must remind that there is a weekly regular servers maintenance procedure. So "quasi-infinite" = up to next forced log-off. And then - only dust and silent stones that will persist in eternity. Even they...
Also the maintained construction area is limited by the keeper controlling limits. More than one keeper can be a possible walk-around to this limitation.
Now when the city grows and new "exposures" are added to it the total amount of objects/props/geometry(even if not visible)/actors also grows and can result in non-negligible FPS drop. This is inevitable at certain stage however there is number of ways to delay the moment when FPS drop will became unplayable/unsupportable or just simply annoying.
Evident way is to reduce the amount of geometry each individual "exposure" introduces to the site. And the most crucial is the initial selection of SZ contact type and its variation. As a general rule "non-protected" variations are less geometry/props charged than their "protected" analogs (that have skimmers and/or other defensive appliances). So, depending on goals, stick to the unprotected ones (the unprotected "shelter" variation is so far the best from utilitarian point of view).
Also take into account that during construction quite a number of random POI can (and surely will be) be generated in proximity. Many of them can be accompanied by NPC ships - parked or flying. Some of them just fly by peacefully, others... In fact during the construction process on the 4th site there was quite a battle there. That doesn't really perturbated the process itself but resulted in a big amount of ship wreckages that was "seen" and locked in the instance by the keeper (even if they were unseen by commanders visiting the site later or by the hunter). Anyway all this additional geometry - while being picturesque - can have quite an impact on the resulting FPS.
There is a (may be a bit "risky") method not to avoid but to free the given city instance from some "unwanted" garbage. This method is based on the "keeper's role transfer procedure" and gives quite a good results if also combined with a preceding "clean up" measures. By "clean up" measures we mean - destroying all (or most of) unnecessary actors - npc's, skimmers, commodities. Once that done in our case we have tried to pass the "keeper" role to the third commander visiting the site and becoming the "temporary" keeper. The hunter was already logged off, when the new keeper has arrived and has parked in the center then our old keeper also performed a complete log-off procedure (with client full shut down). On logging back in on the second attempt our keeper succeeded in re-entering the instance with the city. Then the "temporary" keeper has also logged out while our old-new keeper has remain in the instance - and as do the city. Before those measures the FPS for the keeper has already dropped below 30 (~23 even), after - once again returned to its max 60.
City maximum lifespan - is quasi-infinite. So far the keeper (the original or anyone who have inherited this role) stays on-duty. However here we must remind that there is a weekly regular servers maintenance procedure. So "quasi-infinite" = up to next forced log-off. And then - only dust and silent stones that will persist in eternity. Even they...
Chapter 2.4 Visiting the City. Helpful Hints and Tips for tourists.
Arrival. In general case a visiting commander must master the navigation using on-surface coordinates as there will not be any POI-like contact (if the keeper was not such a nice guy that allows you to join him in wing and then firing up the beacon).
Entering in the correct instance - without wing this can also be tricky (if not the trickiest part of the experience, even in wing). This depends mainly on visitors capability of matchmaking with the keeper. If the first attempt was not successful - do not despair, try again. Ask for the invitation in the keeper's wing, make friends - at least temporary. Remember that it's up to visitor to enter the keepers instance, not the contrary - the keeper will not re-log.
Also all general rules and known limitations of the instance matchmaking can be applied, take this into account when planning a visit in a big group of commanders - may be its more efficient to divide it in some number of smaller ones making a queue. Check any multi-player instancing guides available - we are not the top notch researchers in that particular domain.
Ship. For simple site-seeing and selfies fly any one of your preference. Equip it with an srv hangar and an srv itself if you'd like to do some driving around.
However, if the purpose of visiting is quite utilitarian - you'd want get some data materials as fast as possible - then small size ships or medium/large with SLF's on-board (if SLF have datalink scanner - sorry, I don't remember in fact) are the best choice. Using ship's datalink scanner going from one exposure/dataaccess point placement (don't forget that it can contain "multiple" exposures/copies) to another is much faster than using an srv for the same purpose (if the ship itself is quite small). From the side this really resembles a bee on the flowered meadow. Plan your route ahead, if possible (and the founders were nice to you to even supply with a map) - that's quite simple to lost any traces of the "flowers" that were already visited/scanned and those which are not, and besides all those "flowers" are looking exactly the same way.
Wing scanning. Here at Dja Co-P Mapping Service we were not aware of this option until recently. However performed tests show that if one of the commanders - in a wing - scans a DAP using its on-board datalink scanner compliances then all other members of its wing that are in the same instance will also receive some data - not necessary the same (but if - and only if - their ships are also "airborne"). A commander driving an srv or stayed in a landed ship will receive nothing. This lead to some interesting assumptions: one commander in a wing of four can proceed to do the scan job of the entire city, while three others - defend him. Or, other scenario - a wing of four commanders dividing the city in four areas and then scanning them as fast as possible - the most productive method so far to get the data.
As a useful reminder for the most "grind" dedicated commanders and adepts of the "relog" tactics. The instance is effectively "locked" by the keeper, so relogging doesn't work in general case. You can scan exactly as many DAPs as are available in the city. However a "usual solution" by relogging will not reset them in the default "not scanned" state. The keeper will keep the traces.... All traces...
Entering in the correct instance - without wing this can also be tricky (if not the trickiest part of the experience, even in wing). This depends mainly on visitors capability of matchmaking with the keeper. If the first attempt was not successful - do not despair, try again. Ask for the invitation in the keeper's wing, make friends - at least temporary. Remember that it's up to visitor to enter the keepers instance, not the contrary - the keeper will not re-log.
Also all general rules and known limitations of the instance matchmaking can be applied, take this into account when planning a visit in a big group of commanders - may be its more efficient to divide it in some number of smaller ones making a queue. Check any multi-player instancing guides available - we are not the top notch researchers in that particular domain.
Ship. For simple site-seeing and selfies fly any one of your preference. Equip it with an srv hangar and an srv itself if you'd like to do some driving around.
However, if the purpose of visiting is quite utilitarian - you'd want get some data materials as fast as possible - then small size ships or medium/large with SLF's on-board (if SLF have datalink scanner - sorry, I don't remember in fact) are the best choice. Using ship's datalink scanner going from one exposure/dataaccess point placement (don't forget that it can contain "multiple" exposures/copies) to another is much faster than using an srv for the same purpose (if the ship itself is quite small). From the side this really resembles a bee on the flowered meadow. Plan your route ahead, if possible (and the founders were nice to you to even supply with a map) - that's quite simple to lost any traces of the "flowers" that were already visited/scanned and those which are not, and besides all those "flowers" are looking exactly the same way.
Wing scanning. Here at Dja Co-P Mapping Service we were not aware of this option until recently. However performed tests show that if one of the commanders - in a wing - scans a DAP using its on-board datalink scanner compliances then all other members of its wing that are in the same instance will also receive some data - not necessary the same (but if - and only if - their ships are also "airborne"). A commander driving an srv or stayed in a landed ship will receive nothing. This lead to some interesting assumptions: one commander in a wing of four can proceed to do the scan job of the entire city, while three others - defend him. Or, other scenario - a wing of four commanders dividing the city in four areas and then scanning them as fast as possible - the most productive method so far to get the data.
As a useful reminder for the most "grind" dedicated commanders and adepts of the "relog" tactics. The instance is effectively "locked" by the keeper, so relogging doesn't work in general case. You can scan exactly as many DAPs as are available in the city. However a "usual solution" by relogging will not reset them in the default "not scanned" state. The keeper will keep the traces.... All traces...
Part III. The project of a proposal to ED community
... or at least for those commanders who are interested in that kind of non-official community-driven event and are capable to enter in the same instance as our Service "keeper"=)(*as a remark - PC players instance of ED Universe. *)
Currently we are at the "testing ground" stage, some more additional experiments must be conducted (and any kind of official approval for our activities from FD team will be also much appreciated, see Appendix A).
However even at that stage "Dja Co-P Mapping Service" can propose the following:
Some details:
Why we are proposing this:
- and we are eager to see what the community can do out of this opportunity.
Yes, we are quite aware that there are very different commanders blazing their own ways in the ED Universe, having different in-game roles, intentions and interests. And that is good, in fact.
We don't know what kind of a story will be started at that site upon construction - we can only assume some possible scenarios.
Will it be pure business-like - with some commanders arriving, making scans and then departing in a hurry to the nearest trader?
Or one group of the "good guys" will encounter another group of "good guys" and they will suddenly decide to find out who among them are the best guys in this universe - and all that in the sky just above the city?
Or there will be only one "bad guy" with the credo "kill'em'all" who will do the full instance clean-up procedure - our keeper inclusive? btw - we are absolutely ok with this. However if he will do the logoff just after then the fun will be over for all the rest.
Or there will be a group of volunteer "defenders"? Or other "keepers"? One must keep in mind that in case of local blackout, network/ISP problems or keeper's game client simply hanging for any reason - and the keeper at that moment will be the only commander in the instance - then yes, the instance will vanish.
Oh, if one will take the duty to judge, for example, that the city belongs to its keeper then also a "king-of-the-mountain" game play style event is also imaginable. Speaking about the "lack of the in-game content" - here we have an example of the "player-built" planetary base, that - if some player-established rules be applied - can be: "constructed", "owned by commander or group", "conquered", "looted" and finally "razed". And all this without any additional effort from the official FD team.
If some few commanders will manifest their interest in this project I'll repost it in a separate thread.
Currently we are at the "testing ground" stage, some more additional experiments must be conducted (and any kind of official approval for our activities from FD team will be also much appreciated, see Appendix A).
However even at that stage "Dja Co-P Mapping Service" can propose the following:
1) Supposedly at the second half of the upcoming month (one of the weekends +/- 1 day) our Service will build - by the above described SIMESZ method - a large settlement (so far planned base construction block is the unprotected variation of "Search Zone: Shelter" that produces up to grade 5 data materials) on the surface of a landable planet and in the proximity of station with the "data"-type material trader.
2) We will broadcast new city coordinates and then try to maintain the given instance in Open game play mode for any interested commanders to visit (and profit) using our own resources for the next 72 hours (3 days) since the construction - if no any kind of force-major circumstances will interfere with our self-imposed duty (any RL-related OR produced in-game by the other participating commanders like our keeper ship intentional or non-intentional destruction).
2) We will broadcast new city coordinates and then try to maintain the given instance in Open game play mode for any interested commanders to visit (and profit) using our own resources for the next 72 hours (3 days) since the construction - if no any kind of force-major circumstances will interfere with our self-imposed duty (any RL-related OR produced in-game by the other participating commanders like our keeper ship intentional or non-intentional destruction).
Some details:
1) Our keeper will be in a parked stock sidewinder or an srv with all unnecessary modules (including shields) switched off (this is really necessary to reduce fuel consumption).
2) We have no idea at the moment about particular system and planet for the upcoming construction - and we are open to suggestions. However the final choice and the coordinates of the site (if succeeded in our construction task) will be published at the very last moment.
2) We have no idea at the moment about particular system and planet for the upcoming construction - and we are open to suggestions. However the final choice and the coordinates of the site (if succeeded in our construction task) will be published at the very last moment.
Why we are proposing this:
1) that's another opportunity to test some interesting in-game mechanics
2) for the visiting commanders there will be quite an opportunity to max-out theirs on-board G5 data stock. This is times faster and more immersive than any relog-fests at sites like "The Bug Killer" or "Commander John Jameson crashed Cobra". In fact for those complaining on the forums that the game in some situations imposes on the player the necessity of grinding this can serve as a cooperative opportunity to say out loud "No" for at least one of such cases.
3) this can be fun!
2) for the visiting commanders there will be quite an opportunity to max-out theirs on-board G5 data stock. This is times faster and more immersive than any relog-fests at sites like "The Bug Killer" or "Commander John Jameson crashed Cobra". In fact for those complaining on the forums that the game in some situations imposes on the player the necessity of grinding this can serve as a cooperative opportunity to say out loud "No" for at least one of such cases.
3) this can be fun!
- and we are eager to see what the community can do out of this opportunity.
Yes, we are quite aware that there are very different commanders blazing their own ways in the ED Universe, having different in-game roles, intentions and interests. And that is good, in fact.
We don't know what kind of a story will be started at that site upon construction - we can only assume some possible scenarios.
Will it be pure business-like - with some commanders arriving, making scans and then departing in a hurry to the nearest trader?
Or one group of the "good guys" will encounter another group of "good guys" and they will suddenly decide to find out who among them are the best guys in this universe - and all that in the sky just above the city?
Or there will be only one "bad guy" with the credo "kill'em'all" who will do the full instance clean-up procedure - our keeper inclusive? btw - we are absolutely ok with this. However if he will do the logoff just after then the fun will be over for all the rest.
Or there will be a group of volunteer "defenders"? Or other "keepers"? One must keep in mind that in case of local blackout, network/ISP problems or keeper's game client simply hanging for any reason - and the keeper at that moment will be the only commander in the instance - then yes, the instance will vanish.
Oh, if one will take the duty to judge, for example, that the city belongs to its keeper then also a "king-of-the-mountain" game play style event is also imaginable. Speaking about the "lack of the in-game content" - here we have an example of the "player-built" planetary base, that - if some player-established rules be applied - can be: "constructed", "owned by commander or group", "conquered", "looted" and finally "razed". And all this without any additional effort from the official FD team.
If some few commanders will manifest their interest in this project I'll repost it in a separate thread.
Dja Co-P Mapping Service
------------------------------------------------------------------------------Encoded transmission ends.
Appendix A: VERY IMPORTANT NOTE:
I will be very pleased if anyone from the official FD team can approve/confirm that all the above mentioned in-game mechanics and announced proposals of their utilization are not in any way possible contradiction with the official policy or ToF (otherwise any further on-topic discussion will be meaningless and as so will be aborted). My personal view of the things is that even if one can - only probably - find something contradictive then the possible positive outcome overweight negative consequences if any (and all that without any additional effort from the developers team).
Appendix B: Related materials
1) this thread .
2) Most of the runtime investigation-related materials and log journal has been published in the #side-activities channel on the official FGPE Discord server
3) our final report in the FPGE thread on the official forum
Appendix C: Contact me
I'm available here and on quite a few ED-related Discord servers as "Dja"
If you are interested in SZ-related investigation, have questions on SIMESZ method or you have some fresh ideas - feel free to contact me there or send a PM
And if someone want to build its own city using the same approach I will be glad if they will share their work, screenies and observations