Page 4 of 20 FirstFirst ... 234569 ... LastLast
Results 46 to 60 of 291

Thread: GUIDE: Planet sounds and how to know everything from System Map.

  1. #46
    I doubt it is saved, because next cmdr can also generate it on the fly as his/her game will also follow the same procedural generation rules

  2. #47
    Originally Posted by dognosh View Post (Source)
    I doubt it is saved, because next cmdr can also generate it on the fly as his/her game will also follow the same procedural generation rules
    Im pretty sure the system IS saved once it's visited, because if it weren't we would expect to see variations in the procedural generation between two commanders, but we dont. You can tell a commander what is at system Z and if they go there, they will see the same thing. Also, there would be no way of storing "first discovered" tags if its not saved.

    lets say someone is traveling to system -PDQ 1. An undiscovered M class red dwarf planet somewhere coreward of Sol.
    The CMDR hits the jump button and the system goes to work:
    "is it a known system? no, ok generate it"
    "its an M class red dwarf that means it has this much gravity, this is whats around it, its coreward so it will be X Y and Z, that allows for planet types A B and C, throw in some random generation, we get an M class red dwarf with two planet A's three planet B's and one C at the outside, lets roll some procedural textures based on atmosphere, ok done." It then saves this generated system to a database.
    It does all this during witchspace, you drop in to the sector, honk, and see stuff.

    You scan stuff and then go back home.If it didnt save the system when you visited it CERTAINLY does at this poin that you sell the data. This may be one reason selling data takes so long, its updating the database. So two CMDRS may be running around with entirely different data for the same system, and whoever lands and sells it first is the final form for the system in the database.

    Might be worth testing.

  3. #48

  4. #49
    Thinking about it you are probably right. 400bn systems would actually create a very large database (several GB in size). My whole install is only 5.5Gb, so I doubt its there.

    Having systems only being generated the first time they are entered, and then any subsequent visitor just downloads the data, would be an effective solution.

    - - - Updated - - -

    Originally Posted by Murishani View Post (Source)
    two CMDRS may be running around with entirely different data for the same system, and whoever lands and sells it first is the final form for the system in the database.

    Might be worth testing.
    That would be a poor design as basically you've built an unnecessary race condition that could be managed in witchspace. All you actually need to store/share is the seed for the procedure used to generate the system. However it does explain why selling takes so long and is sequential.

  5. #50
    Originally Posted by Murishani View Post (Source)
    Im pretty sure the system IS saved once it's visited, because if it weren't we would expect to see variations in the procedural generation between two commanders, but we dont. You can tell a commander what is at system Z and if they go there, they will see the same thing. Also, there would be no way of storing "first discovered" tags if its not saved.
    Not necessarily. The procedural generation will be based on an RNG, all that needs to be shared globally is the RNG and the seed for each system, same RNG and same seed you get the same results every time (because RNGs aren't really all that random, that's why the big on-line poker rooms go to lengths like having radioactive sources and geiger counters attached to their servers to provide the seed and achieve actual randomness).

  6. #51
    Originally Posted by CMDR DoubleSkulls View Post (Source)
    Thinking about it you are probably right. 400bn systems would actually create a very large database (several GB in size). My whole install is only 5.5Gb, so I doubt its there.
    not even close, 400,000,000,000 is a VERY large number, even if every system was only 1kb (they're not) 400 billion systems would be 400 TERABYTES of information.

    Originally Posted by CMDR DoubleSkulls View Post (Source)
    That would be a poor design as basically you've built an unnecessary race condition that could be managed in witchspace. All you actually need to store/share is the seed for the procedure used to generate the system. However it does explain why selling takes so long and is sequential.
    A race condition? Im not sure I follow. Player 1 visits system PDQ-1 and gets 2A's 2B's and 1C around an M class, player 2 visits the same system only this time he gets 1A 3B's and 2C's (due to some randomization in the procedural generation) if player 1 gets back before player 2, that system saves that way, player 1 gets the credit for discovery, and player 2 still gets the credits for his finds, but conveniently, since someone else turned the data in first, the credits on the scans are all they get and whatever system they saw, is no longer there. Like I said this would require specific testing to determine if its accurate or not.

  7. #52
    Originally Posted by iain666 View Post (Source)
    Not necessarily. The procedural generation will be based on an RNG, all that needs to be shared globally is the RNG and the seed for each system, same RNG and same seed you get the same results every time (because RNGs aren't really all that random, that's why the big on-line poker rooms go to lengths like having radioactive sources and geiger counters attached to their servers to provide the seed and achieve actual randomness).
    good RNG's are random, seeds control the level of randomness so that you can have predictable results according to complex rulesets i.e. procedural generation, but there will often be some variance between two procedurally generated models even from the same seed. The results may be nearly identical if youre not looking for the differences but they will usually be there. But really that wasnt my point, I dont KNOW that two CMDRS have different data sets, the seed may be accurate enough that their data will be similar enough as to not matter and be the same data.

    I think we may be begining to prod at the guts of a system that frontier would rather we not be prying into for security purposes so I think Im going to stop talking about it at this point.

  8. #53
    Originally Posted by Murishani View Post (Source)
    A race condition? Im not sure I follow. Player 1 visits system PDQ-1 and gets 2A's 2B's and 1C around an M class, player 2 visits the same system only this time he gets 1A 3B's and 2C's (due to some randomization in the procedural generation) if player 1 gets back before player 2, that system saves that way, player 1 gets the credit for discovery, and player 2 still gets the credits for his finds, but conveniently, since someone else turned the data in first, the credits on the scans are all they get and whatever system they saw, is no longer there. Like I said this would require specific testing to determine if its accurate or not.
    A race condition is a common problem in (sloppy) multi-threaded coding where you are updating the same variable in two different threads so when each thread accesses the variable the value it has will depend on which thread updated it last - the threads are in a 'race' to determine the value and bugs can appear which aren't easy to reproduce and can be a right pain to track down. If two different explorers had two different versions of the same system then that would create a similar problem.

    The systems are procedurally generated - so it's random but it's random in a way that while FD can't know in advance what you'll find everyone will find the same thing.

    If you note down the details of every undiscovered system you find on your next trip and when you get home recheck the system map of every system that you don't end up tagging you will find that the system details are exactly as you found them. Guaranteed.

  9. #54
    I think there are variables in to generation process that are already written and atatched to every star, depending on type. Nevertheless i cannot listen to any difference in star sound from GALACTIC MAP, so, anyway they are generated, i think we are allowed to know what's inside a system only after we enter it (if it's unexplored of course). And i think it's good like this.

    Now back on topic, look at those two ammonia and tell me if visuals are helpfull...
    I'll update OP too.

    Name:  Strange Ammonia 1.jpg
Views: 111
Size:  972.1 KBName:  strange ammonia 2.jpg
Views: 110
Size:  685.5 KB

  10. #55
    Originally Posted by iain666 View Post (Source)
    A race condition is a common problem in (sloppy) multi-threaded coding where you are updating the same variable in two different threads so when each thread accesses the variable the value it has will depend on which thread updated it last
    ok I follow, I'm not entirely sure that the condition applies due to how the system data (may) be being stored before being turned in. This is actually why I said we might want to stop discussing the guts of the system. And were off thread topic anyway.

  11. #56

  12. #57

  13. #58
    With PG there is no need to ever save the system even after it has been generated once. You will always get the same result because its not using true random numbers. Its using psedo random.

    If you can follow the text, this is a facinating read about how it was done in Frontier: http://www.jongware.com/galaxy1.html

    The only thing that needs saving in ED is the first discovery tags (and temporarily the data on your discovery scanner so it knows what you have to sell when you get back).

    However, FD might save the system once it has been entered so first discovery tags are easier to associate. Its probably a lot tricker to keep track of those discovery tags without a reference. However, it could be done something like this:

    System xyz: Object 3: <commander name>. Object 6: <commander name>

    As each system would always generate the same objects in the same order (unless someone starts messing around with the system generation code) then each object just has a sequential number that it uses the stored data to link with.

    If i were FD I would have been doing everything possible to minimize storage requirements considering the potential size of the data set.

  14. #59
    Not sure if Akira is still updating this but thought Id update with findings on Helium-rich gas giants.

    They are completely silent, just like ammonia life worlds.

  15. #60
    Originally Posted by Murishani View Post (Source)
    Not sure if Akira is still updating this but thought Id update with findings on Helium-rich gas giants.

    They are completely silent, just like ammonia life worlds.
    Yes, i'm still updating and i thank you very much since i didn't find any helium rich yet. I always scan silent gas giants, so i guess i had back luck.
    Will update and quote. Unfortunatly i had internet connection problems for 2 weeks, and i am about to leave for another couple of weeks, but the plan is to keep this guide updated.

    I didn't play since 1.3, so i don't know if they changed something about planet sounds, any feedback is welcome.

    And +1 to murishani

Page 4 of 20 FirstFirst ... 234569 ... LastLast