Recent Posts

Pages: [1] 2 3 ... 10
Thanks to the help of Wilford Vanterpool with filtering white noise and setting up a priority algorithm for shaping raw data into a readable output, Paul Urrea covered Freezing Point I within the frequently scanned zone. Icebreakers Prime would have a bit of trouble jumping there in case of an emergency quickly enough, but with instant problem detection reaching even beyond this node it's been estimated Icebreakers would launch themselves as node's instances soon enough to prevent any serious damage, meanwhile it was the best database in the whole area. A small datamining program has been written - a self-containing, floating nano database wrapped in portable installation script, allowing for quick deploy or uninstall coupled with compressing stored data into one nice plug and play package. These procedures took their ticks to complete, but on the upside the process was fully automated, requiring netrunner (or AI assistant) to only specify the amount and type of data to download, upload or transfer and a specific order of these operations to occur. The program was supposed to just unpack with a bunch of data filtering executables in the depths of Freezing Point I and start sending the output back to Node Prime.

Cyber Highway class Floating Database      100 000 MB       280 Threads       1 343,4 BP       TCS 2 000    TH 2 000    EM 0
1000 GB/s      ICE res 1-191       ICE Shields 0-0       HTK 82      Sensors 0/0/0/0      DCR 1      PPV 0
MSP 8    Max Reconfig 100 MSP
DB storage 75 000 TB    I/O Buffer 26 GB   
Netrunner    Control Rating 1   BRG   
Intended Deployment Time: 12 ticks   

Cyberspace Gliding Protocol  EP400,0 (5)    Power 2000    CPU Use 4,74%    Cybernetic Signature 400    Critical Fault 5%
Cache Capacity 4 055 000 MB   Range 153,9 billion micronodes (1780 microticks at full power)

This design is classed as a Non-offensive Program for integrity maintenance purposes
This design is classed as a Portable Database for autonomous running purposes

For safety reasons, due to the worm buried within Node Prime, initially all gathered and processed data was to be held at Freezing Point I and to prevent cybersignature of datamining reaching the worm's sensors netrunners set up their own quarantine just so the data would appear as untouched to any observer outside the mined node. However, as soon as first qbits have been extracted roughly at he center of mass of the authorization cluster, a lone Quarantine ICE popped out, soon to be followed by more as Icebreakers started dissolving first instances:

Already proven as not that dangerous, the Icebreakers kept dealing with them, however Isidor Martinex commited one fatal flaw - he assumed this piece of software had already been defeated by simply having it classified and even decompiled to some extent. But it took only a few ticks for the combined group of Quarantine instances to strip one of the Icebreakers completely from its obfuscation and started injecting its sripts for isolating, shutting down and consuming program's modules. Shortly afterwards they alll dissolved in cyberspace's void, but it's been a valuable lesson - with ratio of instances being roughly 1:1, the Quarantine ICE was still a dangerous and potent countermeasure and while slightly weaker, nowhere near weak and potentially devastating. Should more of them arrive, the situation could go south in a matter of microticks.

Besides Freezing Point I, early scans had also identified Freezing Point V as a good datamining spot. At first more instances of Cyber Highway were supposed to reach this node and start extracting and preparing information for transfer in a similar fashion to Freezing Point I operation, but upon closer inspection the node turned out to be some type of exotic database itself, rendering Cyber Highway incompatible with it. In some way this node type could be interpreted as a more sophisticated, properly designed Cyber Highway - a mature, fleshed out software and not cheap module assembled under pressure of infiltrating alien cyberspace. Extracting any info from it was no easy job, because the whole database schema had been imprinted onto a complex quantum matrix, with the data collapsing upon observation into either the correct data or random nonsense depending on the angle from which it was viewed, with the proper sequence of observations fulfilling the role of an authentication process. While cracking this code could take a few ticks and then a few more, comparing the signature of pre-collapse data with first batches of extracted Freezing Point I packets revealed that these quantum matrix-based storage systems were responsible for keeping metadata of the cyberspace. Gaining insight into their content could provide description of the purpose, maintenance, architecture, transfer protocols, security, ICE, installed software, configuration, hardware specifics and all insights into this virtual reality that could ever be useful during the run.

To solve the access problem, PURGE operatives deployed their own simple quantum matrix, carefully tuned to be able to interact with Freezing Point V. The advantage of using own quantum matrix was that it allowed to extract the data bypassing the authentication, the downside that albleit extracted, it'd still exist in unintelligible format, preventing netrunners from reading it, making working with obtained metadata a nightmare. But the "nightmare" part applied only to humans. It was expected that the programs could still benefit from having the metadata injected into their configurations, provided they'd have at least some basic rulesets for dynamic cyberspace navigation programmed, making them better at navigating cyber void. Not the most powerful application of the contained knowledge, but it had to do for the time being. Better something than nothing.

Quantum Monitor class Data Harvester Station      150 000 MB       160 Threads       3 197,8 BP       TCS 3 000    TH 0    EM 0
1 GB/s      No ICE res       ICE Shields 0-0     HTK 137      Sensors 0/0/0/0      DCR 1      PPV 0
MSP 13    Max Reconfig 2400 MSP
Netrunner    Control Rating 1   BRG   
Intended Deployment Time: 12 ticks   
Quantum Harvester: 15 modules downloading 1 200 000 Megaqbits per tick
Quantum Matrix - Capable of storing and processing multiple configurations simultaneously

Cache Capacity 11 401 000 MB    Range N/A

This design is classed as a Non-offensive Program for integrity maintenance purposes
This design is classed as a Static Database for deployment purposes
This design is classed as a Quantum Harvester for autonomous running purposes

In addition to the main program, a small helper had been prepared, intended to work as an installer for the data harvester, but in addition also outfitted with the feature of transferring data in quantum state for all kinds of purposes.

Proxy class Installer      50 000 MB       290 Threads       1 860,5 BP       TCS 1 000    TH 4 000    EM 0
4000 GB/s      ICE res 1-120       ICE Shields 0-0       HTK 165      Sensors 0/0/0/0      DCR 1      PPV 0
MSP 23    Max Reconfig 200 MSP
Installing script     
Netrunner    Control Rating 1   BRG   
Intended Deployment Time: 12 ticks   

Cyberspace Gliding Protocol  EP800,0 (5)    Power 4000    CPU Use 2,24%    Cybernetic Signature 800    Critical Fault 5%
Cache Capacity 22 731 000 MB    Range 3 659,6 billion micronodes (10589 microticks at full power)
Metadata Injecting Capability: 80 000 MB per microtick     Complete Injection 284 microticks

This design is classed as a Non-offensive Program for integrity maintenance purposes
This design is classed as an Installer for autonomous running purposes

Soon the Database Prime operation was up and running on Freezing Point V, extracting metadata to fuel gliding of netrunners and their programs alike. In the future it was hoped authentication code would get cracked and the metadata would be studied to full extent, revealing all the aces Trappist-1 cyberspace kept hidden in its virtual sleeves. Proxy was automated to keep running all the time, strenghtening the whole operation tick after tick. In the meantime more Quarantine instances appeared, but Icebreakers, this time more carefully guided, handled them without any significant trouble.

As ticks passed by, Freezing Point slowly started to become too narrow. With the current understanding of this particular network, netrunners couldn't think about any additional ways of extracting more out of their sandbox node cluster. It'd still serve as a testing ground for new designs and proofs of concept, but there was hardly any point in limiting themselves to this one region anymore. And Quarantine attacks slowly grew in scale, but to mount better counter-counterintrusion measures more processing power was needed, as well as more data. And more space to control was always nice. And the whole point of the run was to simply extract as much data as possible.

Each cluster of nodes should be connected to its neighbours by hyperglide lanes. According to basic netrunning knowledge, they could either require authentication or be free to pass through, stable for any entity to traverse them or require a running transfer shield to prevent entity's data from being fragmented and dissipated, irreversibly terminating its existence. In each cluster there should be a set of jump points for accessing each lane, problem was they remained hidden from the unauthorized intruders. Waypoints from which Quarantine ICE kept spewing its intsnaces, but chances were these were just integrated ICE storage units containing them, not lanes for general-purpose travel. With enough persistence PURGE team could crack the passwords to turn off the alarm and reveal all the jump points, but the tense situation has been dragged off for too long and at this point they must've already burned all cyberbridges and the mechanisms for entering these passwords were most likely to be permanently locked for them in some other clusters, clusters they could not travel to without knowing the location of jump points. The only alternative would be to use quantum metadata. This gave limited insight into the search and exploration processes because each obsevration would screw up quantum state and thus validity of used metadata, but at least the results of this search aka jump point coordinates should be accessible after their reveal just fine.

In addition the program used for mapping the local architecture should be capable of traversing hyperglide lanes as to not limit its usefulness just to Freezing Point. That itself was easy enough to do, because while the exact technology for long-distance travel inside this particular network might remain a mystery, the consequences of unprepared jump point entry were not and a couple of standard shielding algorithms were more than enough to prepare the program for most likely failure scenarios in case of data fragmentation. A little skill on the netrunner's side would suffice for adjusting the jump procedure as needed upon encountering uncovered and odd cases, creating some sort of symbiosis: the program instance had a chance to fail each transit without supervision, but netrunners would just fry their brains attempting to cross unstable lanes without support of proper software.

But preparing the lane-detection module to also serve as intercluster exploration vessel posed a new set of problems, all boiling down to one: the unknown of cyberspace beyond Freezing Point. There were only two possibilities: corrupt, useless regions (and too much whacky bits interfering with a netrunner's brain was dangerous in itself) or meaner ICE. The explorer should be able to defend itself (and definitely its user) from basic attacks, but then going in blind meant not much could be prepared in terms of this. The only reliable option was to attempt to hide the software from detection via seamlessly syncing explorer's structure with the static of cyberspace, since that approach could be properly tested within Freezing Point. The approach agreed upon, the one simple enough to pull off without wasting too much time, was to simply bloat the code with scripts for simulating white noise synced with Trappist-1 cyberspace and make them run alongside valid command. This of course had negative impact on performance, since the exploration suite was now heavier and for each valid command had to run dozens of, from the perspective of its pure functionality and purpose, useless commands imitating juts a dead static at coords it would happen to touch.

Neo Glider class Architecture Mapper      30 000 MB       794 Threads       8 366,6 BP       TCS 600    TH 480    EM 13 740
5000 GB/s    JR 3-500      ICE res 5-86       ICE Shields 458-536       HTK 195      Sensors 140/180/6/6      DCR 45      PPV 0
Maint Life 5,29 macroticks     MSP 7 843    AFR 160%    IFR 2,2%    1YR 468    5YR 7 017    Max Reconfig 720 MSP
Netrunner    Control Rating 2   BRG   SCI   
Intended Deployment Time: 60 ticks    Integrity Check Required   

J30000,0(3-500) Hyperglide Jump Drive     Max Program Size 30000 MB    Distance 500k nodes     Instance Size 3

Cyberspace Gliding Protocol  EP600,00 (5)    Power 3000    CPU Use 69,71%    Signature 96,00    Critical Fault 15%
Cache Capacity 5 573 000 MB    Range 48 billion micronodes (111 microticks at full power)
Theta S229 / R536 ICE Shields (2)     Recharge Time 536 nanoticks (0,9 per nanotick)

CIWS-200 (2x10)    Range 1000 micronodes     TS: 20 000 GB/s     ROF 5       
Hostile Construct Identification Sensor AS158-R15 (1)     GPS 10800     Range 158,4m micronodes    Resolution 15
ICE Signature Sensor EM10-180 (1)     Sensitivity 180     Detect Sig Strength 1000:  106,1m micronodes
Cyberspace Disturbance Sensor TH10-140 (1)     Sensitivity 140     Detect Sig Strength 1000:  93,5m micronodes
Improved Jump Point Detection Sensors (3)   6 Survey Points Per Tick
Improved Cyberspace Sensors ( 3 )   6 Survey Points Per Tick

This design is classed as an Offensive Program for integrity maintenance purposes
This design is classed as an Architecture Mapper for autonomous running purposes

Some parts of its design, namely the cloaking protocols, appeared crude, but they should be good enough to get the job done. Design philosophy was to make it an exploration program mapping network from a safe distance, blending with the fabric of cyberspace and hopefully gliding fast enough to escape detection range should some ICE sniff it out. It even had some primitive counter-counterintrusion disintegrators should some encountered ICE be capable of triggering attacks that skip distance without launching program having to glide closer. They were likely to be overwhelmed in any serious combat, but hopefully they would stop at least some instances of these long-range attacks from leaking through. In addition its ICE resistance got sacrificed in favour of ICE shields, a weaker but regenerative defence layer, in addition isolating the program's core from impacts which could give additional benefits in specific scenarios. That way even if it got hit multiple times it should be able to recover quickly after escaping imminent danger and continue mission without the need for reconfig.

When everything was finally ready, first instance of Neo Glider was loaded into a cyberdeck, booted up and sent into the unknown, set up for identifiying hyperglide lanes and exploring the network at large so that PURGE team might at last start unearthing its ancient secrets.
General Discussion / Re: What's Going On In Your Empire: C# Edition
« Last post by gamemonger56 on Today at 07:03:55 AM »

finally found the [SOL] homeworld....chased the rats back to their hole.  very nice planet, lots of minerals,etc. Not gonna glass it.

Took out the PDCs; had to build a bigger ship with bigger missiles and beams. took out the army on the planet, some 300K tons.

Now i have terraformers over the planet and turning it into something my peoples can use....

C# Suggestions / Re: Suggestions Thread for v2.0
« Last post by gamemonger56 on Yesterday at 08:42:24 PM »

I would like to see autofactories, maintenance and fuel. drop them on a planet with auto miners, tell the factories what to build and come back in a couple of years.

I would make them to be medium to high tech. starting imperium wouldve have access to to them.
C# Tutorials / Re: Maintenance modules
« Last post by Kiero on Yesterday at 05:24:00 AM »
C# Tutorials / Re: Maintenance modules
« Last post by gamemonger56 on January 27, 2023, 04:59:59 PM »

thanks for that ill try that. also, screen below did not appear :)
General Discussion / Re: Questions Not Worth Their Own Thread: C# Edition
« Last post by db48x on January 27, 2023, 04:25:29 PM »
EDIT nm I figured it out, forgot to set 2nd stage separation range to zero!

This is a very common problem; I would say that one in five of my own such designs have had the same flaw.
The Academy / Re: Very slow game turns
« Last post by Garfunkel on January 27, 2023, 08:49:24 AM »
Please register your account so that you can post normally. Currently, we have to approve your posts manually which creates a delay.

As to your question, that does sound little long for what you describe. However, Steve has put out version 2.1 already so I would recommend to switching to that unless you're really attached to your current game. If you are, then deal with the NPRs as soon as possible since they are the likely culprits of major slowdowns if you've already purged civilian shipping lines. Also, if you have the "NPRs activate spoilers" option toggled on, then your game might be screwed in the sense that the 2 or 3 NPRs could have generated multiple spoilers that are now busy grinding your game down to a crawl.
C# Suggestions / Re: Suggestions Thread for v2.0
« Last post by boolybooly on January 27, 2023, 04:38:27 AM »
If you look at the two screenshots, these are successive in the process of adding water vapour to Proxima Centauri II. You can see the Hydrographic Extent increases from 5.51 to 6.56.

Min Max thermal range changes from (-11.136 <> 54.498, which is a range of 65.634) to (-9.256 <> 56.849 range 66.105). So the range has increased not decreased and the temperature factor has gone from zero to 0.123 though it fluctuates quite a bit.

You need to let all that water vapor condense down to equilibrium, which will take ages from 0.5 atm. The increased range you're seeing is simply because you increased atmospheric pressure with water vapor which increased the body's greenhouse effect.

At the same time Hydrographic extent increased by 20% 5 to 6 ish but didnt seem to help and to the best of my knowledge does not have an effect, which is why I am suggesting liquid water could have an effect too.

I completely understand temperature increasing temporarily due to water vapour makes sense and the range of extremes increasing due to global warming also make sense as it is current meteorological science dogma and is considered to be due to the increased level of the energy equilibrium in the atmosphere causing higher wind speeds and thereby increased mixing of equatorial and polar weather systems in the atmosphere causing particular locations on the surface to experience a greater range of extremes.

But the global warming model does not include adding water to the system which would buffer the whole system as well as cause sea levels to rise of course.

In the example you could add Frigusium to counter the water vapour warming but that would only lower temperatures and shrink the range a little as a result, there is no way to change range independently of temperature so you are stuck with a fixed scale of range per temperature per body, as I understand it. On Proxima there is no way to bring the range inside tolerable though you might get away with straddling it.

If you are adding liquid water to a body then in theory the temperature range should decrease due to the buffering effect of liquid water's high SHC and bring about a reduction in temp range, which does not seem possible by any means in Aurora C# as things stand but might be worth having as you could use the hydrographic extent >20 to buffer the temperature range and reduce fluctuation due to eccentric orbit, at the cost of max population supportable. Alternatively you could invent a TN Reductium gas to do the same but since the hydrographic model already exists I just thought it would be a more interesting suggestion to make the most of it.
C# Tutorials / Re: Maintenance modules
« Last post by Kiero on January 27, 2023, 03:55:09 AM »
Code: [Select]
MB-30 "Lee Il-Seok" class Maintenance Base      158 031 tons       1 580 Crew       3 799 BP       TCS 3 161    TH 0    EM 0
1 km/s      No Armour       Shields 0-0     HTK 212      Sensors 0/0/0/0      DCR 1      PPV 0
MSP 25 015    Max Repair 100 MSP
Cargo Shuttle Multiplier 10   
Lieutenant Commander    Control Rating 1   BRG   
Intended Deployment Time: 3 months   
Maintenance Modules: 30 module(s) capable of supporting ships of 75 000 tons

This design is classed as a Commercial Vessel for maintenance purposes
This design is classed as a Space Station for construction purposes
This design is classed as a Maintenance Ship for auto-assignment purposes

That is my Maintenance Base.
To use it as an overhaul location you have to put it in a fleet and drag it into position by a Tug.
Then take a ship that you would like to overhaul and direct it to that maintenance Fleet (screen below):
C# Bug Reports / Re: Why is this showing up?
« Last post by gamemonger56 on January 26, 2023, 07:23:23 PM »

New one showing up:

2.1.1 Function  #2929: Object reference not set to an instance of an object.

Shows up very randomly.
Pages: [1] 2 3 ... 10
SMF spam blocked by CleanTalk