frame

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Sign In Register

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Categories

Hi Everyone

I think most of the major changes are done, I think. Now I will be just doing small stuff to improve security and hopefully make everything look better. :)

For help for existing users prior to website update read these posts:

Activating account:
http://spacesimcentral.com/forum/discussion/7019/troubleshooting-my-account-from-the-switch-over

Download Area Info
http://spacesimcentral.com/forum/discussion/7020/download-area-info


Please post to the administration area if you have any problems:
http://spacesimcentral.com/forum/categories/ssc-administration


-D1-

Classic Systems full of Tumbleweeds

edited 2:53PM in Pioneer
Van Mannens Star

Ross 248

Tau Ceti



they're empty?????? Is that to avoid copyright issues with Dave?



3D starmap is super confusing btw, anyone got any tips? I keep getting lost very easily
«1

Comments

  • robnrobn Pioneer Developer
    edited 2:53PM
    trumpet wrote:
    Van Mannens Star

    Ross 248

    Tau Ceti



    they're empty?????? Is that to avoid copyright issues with Dave?


    They're autogenerated, which tends more to the unpopulated side. It will improve as time goes on, both via adjustments to the system generator and inclusion of custom systems to support scenarios or storyline we want.


    3D starmap is super confusing btw, anyone got any tips? I keep getting lost very easily


    I made this video just after the 3d galaxy hit the repository. Its had a couple of very minor tweaks since then but the fundamentals remain the same.



  • edited 2:53PM
    thanks Robn! That vid is a massive help



    is there a discussion thread regarding populating the galaxy?
  • edited 2:53PM
    thanks Robn! That vid is a massive help



    is there a discussion thread regarding populating the galaxy?
  • edited 2:53PM
    trumpet wrote:
    is there a discussion thread regarding populating the galaxy?




    There is now! :D



    I personally think that this should tie into the factions ideas, since we might want the populated volumes to match the factions.



    However, there's probably no good reason to stop us/you from manually populating a few of the real star systems with reasonable sounding populations, space stations and ports. The worst that will happen is that we'll have to give some feedback that might alter them. Definitely avoiding anything that was expressly in Frontier/FFE for example. That doesn't mean that Tau Ceti can't be a inhabited with interesting planets, just that they shouldn't be copied from those games!



    Longer term one way of affecting system population might be to define volumes which belong to a faction, perhaps with a drop-off rate.

    EDIT: (worth nothing that I don't mean you'd _see_ these ingame, just that they'd be there in the data controlling population/faction distributions)

    Then when it's generating the system populations it would evaluate the contribution of these volumes and assign a mixture of the factions where they overlap.



    Hmm, start of an idea in there I think :idea:
  • edited 2:53PM
    Longer term one way of affecting system population might be to define volumes which belong to a faction, perhaps with a drop-off rate.


    I'm thinking that would be good for building sets too. If, for example, we have Federation, Empire and Alliance building styles, cities near the center of the volume would be exclusively of that faction's style, but as one moves near the periphery of the volume the styles of the buildings would become increasingly mixed.
  • edited 2:53PM
    Yeah the factions sounds good. I always used to start out in Lave and save up $$$ till I could afford to get into the Imperial systems.. then save up even more to make it all the way into Sol.



    Was satisfying feeling when you finally got to make that jump and see Sol pop up...



    The suggestion I have would be to spawn pockets of civilisation... ie if a Star System spawns/generates/itereates as a high population centre - (multiple cities on a planet, more than just one space station - you know something like Phekda or Alioth in that there's a bit going on that you can fly around) then x number of systems around this major population centre would also be populated thinning from the high population centre



    this would in turn create the Alioths and Phekdas of this galaxy perhaps??
  • edited 2:53PM
    The suggestion I have would be to spawn pockets of civilisation...


    Yes! High population civilized areas thinning out to lawless no man's lands in between them. That's what I'm hoping for.
  • edited 2:53PM
    I quite like this idea, not sure entirely how to define these volumes yet. It might be possible to add a feature to the galaxy viewer itself so that interested people can go in and edit within the game engine. Possibly only do this using a command line flag for "developer mode" ... anyway that's an aside.



    What do other dev's think about defining simple volumes to control the population and development, and later factional alignment, of a system?

    Is there some kind of faction document/page with actual implementation discussion around?



    Are there any objections to this approach?



    Andy
  • edited 2:53PM
    Another option is to keep it completely procedural.

    Although how to define this so that it allows for factional centres of power etc does seem a bit trickier.
  • edited 2:53PM
    I quite like this idea, not sure entirely how to define these volumes yet.




    a) use your 3d engine to do the work for you. Define volumes as a mesh.

    advantages: -You should already have most of the code for it.

    - even complex, irregular volumes can be easily defned by creating a mesh in a 3d-programm

    disadvantages: -very static



    b) Go procedural. Write a course algorithm that takes a starting point and expands from there, using a (very simplified) model of resource allocation, a short tech tree and a bit of politics to determine expansion speed. Where volumes start to overlap you get a much slower expansion rate, an occasional war and smuggling galore.



    advantages: -provides you with a course, but consistant history you can build on.

    -completely dynamic: History could even continue while you play, you could play in different time periods, and if things get boring you can change the history seed and get slightly alternative histories.



    disadvantages: -Unpredictable, especially when modding. When someone adds a new major faction via a mod, it will change the whole course of history

    -a pretty piece of work

    -longer loading time at game start (depending on how course the algorithm is. I think it should be possible to make something that can run through a thousand years of history in under 5 seconds, but that would be very course. The more detail you want out of it, the longer the algorithm has to run).



    C) A combination of the above, combining some of the advantages and disadvantages: Make a procedural algorithm that generates you the volume and the history, and then freeze it and load it at startup instead of generating the whole thing. Has shorter loading times, is more easily modable and offers you full control over the result, but it is again absolutely static, and it's a lot of work.
  • edited 2:53PM
    Well I started to look around the source code last night to figure out how it determines the current star system data.



    It looks like it just takes the distance from 0,0,0 :- i.e. Earth/Sol. As it's main determinant for a planets population.

    That would be the obvious place for me to hook in assessing the local volumes etc.



    @UncleBob

    My current plan is just to do some hacking on my own PC/branch to work out how I'd do manual volumes and then work from the understanding I develop doing that to create a procedural algorithm that is time based. I _really_ like the idea of places changing over time :D populations, number of stations (it would be insanely awesome I you could see them being built... but no), goods on offer, everything really.



    Good suggestions!
  • edited 2:53PM
    Oh and I just remembered, whilst doing this investigating I stuck breakpoints in the various parts of system population.

    During the creation of a new game the star system generation gets called a HUGE amount. I haven't looked into why but it all seemed to be from Lua.



    I'm wondering if there might be something in a script that could be partly responsible for the very long new game start times.

    I'll try to take a look at this...





    I think I really need a to do list! :D
  • edited 2:53PM
    Oh and last night I profiled our Simplex noise implementation against a SIMD port of a glsl version using the GL Mathematics library and another open source library.



    By iterating over the noise function itself 10,000,000 times for each function, and even by forward generating the parameters for them to eliminate that as a potential overhead, I've found that our current noise function is at least 2 times faster than the one I found via this thread http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Number=293473 (http://webstaff.itn.liu.se/~stegu/aqsis/DSOs/DSOnoises.html) or https://github.com/ashima/webgl-noise/wiki which I used GLM to test using C++.



    I.e: it's pretty quick already, there might be specific ways we're using it for Pioneer which we can optimise it for but otherwise it's not going to get that much faster without some really careful understanding.
  • edited 2:53PM
    During the creation of a new game the star system generation gets called a HUGE amount. I haven't looked into why but it all seemed to be from Lua.




    First for generating the visible systems, second for generating all the systems for missions, I would guess.
  • robnrobn Pioneer Developer
    edited 2:53PM
    Oh and I just remembered, whilst doing this investigating I stuck breakpoints in the various parts of system population.

    During the creation of a new game the star system generation gets called a HUGE amount. I haven't looked into why but it all seemed to be from Lua.




    StarSystem.GetNearbySystems. We know a better mechanism is required, and we know the system cache behaviour is suboptimal. Just needs someone to get in there and think about it.
  • edited 2:53PM
    Ugh yes I see what you mean.

    Ah well. Another one for the issues list :)
  • edited 2:53PM
    The discovery of the ToDouble() method on fixed datatypes is speeding up development :D



    The biggest problem right now appears to be the paucity of potentially habitable stars. I can setup, well hack in this case, a list of points in the sector view that function as the centres of population exodus. Just like Sol does.



    However most of the worlds generated are frigid, gas giants, or otherwise unsuitable for the habitation algorithm to put life on them. I think it needs to be a bit more flexible as we'd surely terraform a lot of the worlds, build space stations and star ports of dead worlds etc.



    Still I think the idea is coming along. Not a clue how to turn it into an algorithm yet, but a manual system using Lua scripts seems plausible right now :)



    Andy
  • edited 2:53PM
    Oooh actually I just had an idea.



    Back at Uni' I wrote a system for generating dirt textures using a process I can almost remember the name of... it'll be on my HDD somewhere. Anyway it's slow and a bit oddball. Ah ha! Diffusion limited aggregation that was it. I could probably also implement something using a simple directed tree I suppose. Then branches could "grow" over time too(?) meaning the number of inhabitants etc.



    Not sure but there could be something good in either of these approaches.
  • edited 2:53PM
    I might have gone mad with the power of Lua! :lol:



    Just scripted up some system generation to populate a vast swathe of space, centred roughly on the coordinates of Achenar from Frontier for obvious reasons, with hundreds and hundreds of stars so that I could test the rough population heuristic I've got.



    Ah damn that's awesome :mrgreen:
  • edited 2:53PM
    Just scripted up some system generation to populate a vast swathe of space, centred roughly on the coordinates of Achenar from Frontier for obvious reasons




    Damn imperials! :P


    but a manual system using Lua scripts seems plausible right now




    We'll still need multiple factions and factional reputation that gets displayed somewhere in the character screen, so something will probably have to be hard coded. Still, if the system is open enough to add custom faction by LUA, all the better. I bet Pioneer will get used for gazillions of total conversions if it is easily modable (hmmm... Perry Rhodan Mod, anyone? :P Way too early to think about stuff like that. Bad Bob!)
  • s2odans2odan Pioneer Developer & Moderator
    edited 2:53PM
    However most of the worlds generated are frigid, gas giants, or otherwise unsuitable for the habitation algorithm to put life on them. I think it needs to be a bit more flexible as we'd surely terraform a lot of the worlds, build space stations and star ports of dead worlds etc.


    Hey, the answer I believe is in Starsystem.cpp around line 1450 where there is a large list of ifs and if/else statements where colonisation is abandoned due to certain condistions. You'll just need a check above all of those for: (psuedo code)

    if (human_proximity > 0.25) {

    do life stuff...;

    }

    I think thats the bit anyway that deals with colonisation.



    This is one section from that part, where colonisation is abandoned if the resources of a planet are crappy:
    else {<br />
    <br />
         // don't bother populating crap planets<br />
    <br />
         if (m_metallicity < fixed(5,10)) return;<br />
    <br />
    +    if (m_oreAbundance < fixed(2,10)) return;<br />
    <br />
       }
    
  • robnrobn Pioneer Developer
    edited 2:53PM
    While you're in StarSystem.cpp, would you mind checking/fixing all the math and cleaning up the code? Its one of the giant things to do and nobody wants to touch it :)
  • edited 2:53PM
    robn wrote:
    While you're in StarSystem.cpp, would you mind checking/fixing all the math and cleaning up the code? Its one of the giant things to do and nobody wants to touch it :)




    That's because there's so much math! :lol:

    Is there a list of specific issues for StarSystem or does everyone just look at it and run away?
  • robnrobn Pioneer Developer
    edited 2:53PM
    Is there a list of specific issues for StarSystem or does everyone just look at it and run away?


    Not sure if this is specific or general. It is just off the top of my head though :)




      [*:so5yao2w]The math needs checking to make sure it actually implements the correct algorithms/theory of system generation

      [*:so5yao2w]The fixed-point stuff needs checking for overflows, underflows, precision problems, etc. There are many, and some have just been fudged around. I know there are edge cases where zero-mass bodies can be generated, bodies generated inside other bodies, impossible orbits, etc.

      [*:so5yao2w]It needs a decent class structure.
    #699, terrain refactor is an example of some code of similar complexity being broken out into a managable structure. I'm not suggesting it be copied, but it might be useful.

    [*:so5yao2w]Stricter checks on data access required (eg hide member variables etc)

    [*:so5yao2w]Looser coupling between StarSystem and SBody

    [*:so5yao2w]Looser coupling with CustomSystem/CustomSBody (overlaps with some other work/thinking that's going on around custom systems)



    That's just a start :)
  • BrianettaBrianetta Pioneer Developer
    edited 2:53PM
    Just scripted up some system generation to populate a vast swathe of space, centred roughly on the coordinates of Achenar from Frontier for obvious reasons...


    Achenar is the real and notable star Alpha Eridani, in case you want to put it in its actual, correct place! It's the bulgiest star known.
  • edited 2:53PM
    The name is actually AcheRnar, and is among the brightest stars as seen from earth, but certainly not the Bulgiest. It's a B3V, so it's actually main-sequence and cannot even compete with type III stars, left alone type I like Antares or Betelgeuse (Unless by bulgy you mean massive. Archernar certainly got a lot of that...)



    B-stars are pretty hot, not that much chance of finding a habitable planet according to current models, but then again, current models are undergoing severe criticism by real-life Exo-planets...



    A BV would be a nice place for a Sudarski II giant though, that might sport a habitable moon... The Goldylocks zone would probably be somewhere between 30 and 40 AU. Big system, might take a while to fly around in... :D
  • BrianettaBrianetta Pioneer Developer
    edited 2:53PM
    UncleBob wrote:
    The name is actually AcheRnar, and is among the brightest stars as seen from earth, but certainly not the Bulgiest. It's a B3V, so it's actually main-sequence and cannot even compete with type III stars, left alone type I like Antares or Betelgeuse (Unless by bulgy you mean massive. Archernar certainly got a lot of that...)


    Achenar is an alternative spelling, not an incorrect one (and that's mentioned on pretty much every source).



    By bulgiest, I do not mean massive, and I do not mean bright. I mean bulgy. It bulges at the equator, because it spins extremely quickly. No bulgier star is known. I'm actually kind of surprised that my spell checker knows the words bulgy, bulgier and bulgiest. (-:
  • edited 2:53PM
    It bulges at the equator, because it spins extremely quickly. No bulgier star is known. I'm actually kind of surprised that my spell checker knows the words bulgy, bulgier and bulgiest. (-:




    Your spellchecker's definitaley better than me! :lol: So yeah, you're right. My first association when hearing "bulgy" mislead me.


    Achenar is an alternative spelling, not an incorrect one (and that's mentioned on pretty much every source).




    Looks like I learn something new every day... two things today, actually, considering "bulgy".
  • s2odans2odan Pioneer Developer &amp; Moderator
    edited 2:53PM
    Achenar is an alternative spelling, not an incorrect one (and that's mentioned on pretty much every source).


    Except for the one you linked to hehe.


    centred roughly on the coordinates of Achenar from Frontier for obvious reasons,

    in case you want to put it in its actual, correct place!


    We already have this star:


    CustomSystem:new('Achernar',{'STAR_B'}):add_to_sector(4,8,-16,v(0.023,0.857,0.883))
    


    Hard to find since we use the *correct* location, not some made up crap like frontier/FFE ;)



    @Fluffy :
    The fixed-point stuff needs checking for overflows, underflows, precision problems, etc. There are many, and some have just been fudged around. I know there are edge cases where zero-mass bodies can be generated, bodies generated inside other bodies, impossible orbits, etc.


    Specifically with overflows, I know the albedo values and greenhouse gass values tend to overflow for strange results...cold planets next to a sun ect.

    Quite a few cases of impossible orbits, things rotating too fast, that sort of thing... Although I personally aint too bothered about them as they are very interesting planets when you find one :) Like the planet we found with such a high rotation that you couldnt stay still without set-speed, it would fling you out of its atmosphere :)
  • edited 2:53PM
    I know the albedo values and greenhouse gass values tend to overflow for strange results...




    Overflowing greenhouse effects? Tell me about it... Seems to be a trouble with near any system generator, including my modified StarGen code.
Sign In or Register to comment.

SpaceSimCentral

| The largest Space and Scf-Fi Gaming Community
@ 2008-2016 SpaceSimCentral.com, All rights reserved.
Powered by VanillaForums, Designed by ThemeSteam

Contact us

Like I am going to give you my phone # :)

Get In Touch