The Ur-Quan Masters Home Page Welcome, Guest. Please login or register.
Did you miss your activation email?
December 02, 2022, 12:09:22 am
Home Help Search Login Register
News: Celebrating 30 years of Star Control 2 - The Ur-Quan Masters

  Show Posts
Pages: [1] 2 3
1  The Ur-Quan Masters Re-Release / General UQM Discussion / Re: UQM stars/races relocation mod? on: January 08, 2016, 08:35:23 am
Well, all stars having importance index will remain having original content. Including Rainbow-containing and Melnorme-containing stars. Do you want to keep the "Groombridge" name for that Rainbow-containing star? What's so special about this name?  Smiley
Oh, btw, I've decided to make Sirius always be near Sol. I guess everybody knows, that Sirius is the closest neighbour star.

Thanks for supporting words and those contributions. Sometimes it's really important to see, that I'm not alone in my endeavour.

I was hoping to do the final sprint this week, but failed bumping (like silly) on the underestimated complexity of gluing stars with constellations, while avoiding collisions, and making all this random and look nicely. I'll have to backup to the slow pace, where I have much more time to think things over-and-over again, before implementing them at weekends.
Besides I spent vacation for rest, and hanged on the new UnderRail game, which is quite nice.

I'm currently thinking about 2 alternative paths of doing things.



Maybe there is an easier way to make things look nice?, but I can't see it.
2  The Ur-Quan Masters Re-Release / General UQM Discussion / Re: UQM stars/races relocation mod? on: January 03, 2016, 09:32:05 pm
Solved non-important constellations placement. Made an XY-overlapping-windowing indexer, which solves tasks of empty spaces detection and even distribution of constellations. Also applied collision resolver (which is also used near graph-springs-layouter) to make sure constellations don't get too close to each other.

Non-important solo stars will most probably be treated like single-star-constellations, which means that placement of non-important solo stars is 95% done.

Also completed naming for constellations. And for solo-stars will use same solution, which makes it ~80% done.

Overall progress:
V (1) Initialization of initial fleets
V (2) Initialization of important stars
V (3) Initialization of important constellations
V (4) Initialization of semi-important stars
V (5) Initialization of non-important constellations
TODO (6) Initialization of non-important constellation-stars
90% (7) Initialization of non-important solo-stars
TODO (8 ) Initialization of quasi-space locations
90% (9) Initialization of important coordinates
V (10) Compilation of all previous steps results into a starmap

Resolved 1 memory leak, but it's still not healthy. Benchmark still dies on 300th-400th iteration.
Quasi space locations placement will be solved using logics similar to constellations placement - using combination of XY-overlapping-windowing indexer and collisions solver.
All hardest tasks are solved, and now just need to apply the tools made, and integrate this whole stuff into game initialization logics. As for the latter, I was also thinking about making a sub-menu for "New Game" -> "Start with original locations" or "Start with randomized locations".

Quite tired by now, as I spent sick leave (from work) and holidays to implement hardest stuff. I have 1 week of vacation left now, and hope to release first good version by end of it - starting from next week things will go very slow again.
3  The Ur-Quan Masters Re-Release / General UQM Discussion / Re: UQM stars/races relocation mod? on: December 31, 2015, 01:46:37 am
CelticMinstrel

Actually, making fun names from at least 5-10 of solo stars might be enough. All solo stars are below. If anyone wishes to contribute - welcome - think of 5-10 funny star-names.))
And if I ever get to constellation templates, we can similarly think of 5-10 constellation hints.
4  The Ur-Quan Masters Re-Release / General UQM Discussion / Re: UQM stars/races relocation mod? on: December 29, 2015, 10:54:10 pm
One put the Syreen homeworld on top of the Burvix, which seems a little odd. I guess that's just a matter of adding a new but very loose constraint.
Chronology:
(1) Burvix lives in Arcturus, communicates with Druuge and Utwig.
(2) Syreen lives in Beta Copernicus I.
(3) Syreen homeworld got destroyed by Mycon.
(4) Burvix got destroyed by Kohrah.
(5) Syreen submits to Ur-Quan, in exchange they find a world where Syreen can live - Betelgeuse.

Thus there's almost no assumptions about where Syreens should be, and who they should neighbour (except, that they should neighbou Ur-Quans), - because they got new home just very recently. Spathi may know about it from insider info channels, because they became part of hierarchy. And this home don't even need to be near human space (according to dialogues)... Although, I don't think Syreen's battle/intelligence value is high for player. Thus placing them too far from Sol might make them just worthless - so probably need the Sol <-> Syreen assumption anyway... Not sure.
And please, correct me if I'm wrong.
For #9, just force the Syreen location to be named Betelgeuse regardless of where it ends up being placed.

For #10, in theory you can probably just force the constellation containing the beast to have the same name as in the original game. I don't recall if the constellation actually formed a snake-beast-like shape though.
For #9 - I could do either that, or just remove Bugsquirt stuff and let Spathies name real location. Another solution (really funny) would be to give a funny second name to every star/constellation, and depending what new name for Syreen home is randomly chosen - put fun into Spathi mouth. If I was a school teacher, it would be quite easy - I would give a task to each student to invent funny names for 2-3 stars...  Grin

For #10 - not sure I remember correctly, - it wasn't anything about name. The Lyncis constellation actually looks like a snake which ate something big. One way to solve this would be changing dialogue (excluding hint about snake and elephant).

If I keep Syreen in Betelgeuse and Vux Beast in snake-like constell - it just would kill the idea of relocation and randomization.
5  The Ur-Quan Masters Re-Release / General UQM Discussion / Re: UQM stars/races relocation mod? on: December 27, 2015, 10:31:45 pm
Integrated tools for solving collisions of stars/constellations (while making layout). Finished layouting for 4 steps: fleets, important stars, important constellations, semi-important stars. As layouting may fail in some very rare random cases, introduced fail-tolerance and reset-retry logics. Added some more benchmarking tools.
Although I tried to be careful with memory allocation (malloc/free), benchmark showed a memory leak, and on Windows I can't localize it. The tools below conflicts with src/libs/compiler.h and other libs.
Code:
#include <windows.h>
#include <psapi.h>

size_t getPeakRSS() {
    PROCESS_MEMORY_COUNTERS info;
GetProcessMemoryInfo( GetCurrentProcess( ), &info, sizeof(info) );
size_t peak = (size_t)info.PeakWorkingSetSize;
}
size_t getCurrentRSS(){
    PROCESS_MEMORY_COUNTERS info;
GetProcessMemoryInfo( GetCurrentProcess( ), &info, sizeof(info) );
return (size_t)info.WorkingSetSize;
}
The failed benchmark consists of 1000 attempts to layout 4 steps: fleets, important stars, important constellations, semi-important stars. It fails on 350th-400th step with out-of-memory.
Otherwise works pretty fine - reset-retry frequency is near 0.1%, average generation time is below 1 second. I'll leave it like that for now, as I don't think it will ever cause any problem to gamer - the starmap generation is a very rare thing gamer will do.

Next tasks are
(A) generation of non-important constellations
(B) generation of non-important solo-stars and constellation-stars
(C) random distribution of names to constellations/stars

For (A) and (B) the main challenge will be to make distribution even. Probably gonna reuse layouting-via-springs, but under different sauce now. Another idea was to separate starmap into big amount of overlapping windows, and to solve distribution-evenness problem in scope of each window. It's like an indexing strategy (one of), used in some DBs.
As for pretty constellation patterns... well, I would do that if someone cooperated, and made a simple txt file containing all constellations profiles. Each profile should contain a bunch of coordinates for each star in it, centered on constellation centre as (0,0). Quite easy to do programmatically btw, - even Excel would be enough to do it... Otherwise, I don't think I'll bother with that, until first complete version of fully working relocation mod is released.
6  The Ur-Quan Masters Re-Release / General UQM Discussion / Re: UQM stars/races relocation mod? on: December 25, 2015, 07:26:58 pm
Somehow, solving the font problem (I was trying to draw text without font being initialized) made layouter work much faster. I also moved forward reusing layouter for placement of other objects (not only fleets). Naturally refining it's algorithm. Now result is pretty cool - it averagely completes in <1 second, rarely giving maximum 4 seconds.
Code:
Last generation completed in  377 iterations,  0 seconds. Current average (for  100 generations): i  939, t  0. Overall max: i 5076, t  3

I also keep track of some issues, which were mentioned here, and which I noticed myself:
Code:
Issues in assumptions:
    #001 Shofixty epic return (from mission to Mycon -> back home through Vux and Yehat spaces): path may be non-straight line
    #002 Chenjesu expedition through Spathi to discover ZFP: path may be non-straight line.
    #003 Rainbow worlds will not form arrow
    #004 Supox   may be among other fleets, but noone talks about them
            Solved by #005.
    #005 Utwigs  may be among other fleets, but noone talks about them
            Solved by UTWIG_FAR_FROM_SOCIAL_RACES macro. Solves also #004.
    #006 Druuge  may be among other fleets, but noone talks about them
            Solved by DRUUGE_FAR_FROM_SOCIAL_RACES macro. Solves also #004.
    #007 Any race may neighbour other race, but pretend not knowing each other
            Solved by #004. Solved by #005. Solved by #006.
    #008 UrQuan not in center reduces need to encounter them (MUST BE SOLVED)
            Solved by URQUAN_SOICENTER_DISTANCE_FROM_EDGE = 4000 macro.
    #009 If "BugSquirt" sounds a bit like "Betelgeuse" (Deutch), then new Syreen location name will not sound like that anymore.
    #010 Beast hunted by Zex - it will not reside in constellation, which is like "snake ate elephant"
    #011 Constellation-stars should form pretty geometric forms.
    #012 Solving #007 and #008 makes generated galaxy quite deterministic.
 
7  The Ur-Quan Masters Re-Release / General UQM Discussion / Re: UQM stars/races relocation mod? on: December 24, 2015, 06:10:07 am
After fixing few bugs in the layouting algorithm it started working quite nicely, resolving alpha config (132 assumptions) very fast.
I was quite afraid to get drown in endless-fruitless trying to refine algorithm, failing in the end after 1 month, and surrendering whole endeavour. So afraid, that when it finally started working fine (after few fixes), I was like

I thoroughly analysed all relations between all fleets and important locations and made a matrix of assumptions with full specification here. I bet it's at least 95% complete, and of course it's content is subject of discussions.
This complete-assumptions-config contains 25 participants and 250 assumptions between them, which is quite heavy. On my 3Ghz CPU layouter consumes only 1 core, and solves it in 10-100 seconds, and it won't be easy to refine it further.
Btw, I tried to use graphical library to output some texts (like layouting iterations counter), and failed
Code:
void DrawTextInCorn(char* txt, Color c) {
    TEXT t;
        
    BatchGraphics();

    SetContextFont (TinyFont);

    t.baseline.x = 100;
    t.baseline.y = 100;
    t.align = ALIGN_CENTER;
    t.CharCount = strlen(txt);
    t.pStr = txt;
        
    SetContextForeGroundColor (c);
    font_DrawText (&t);  

    printf("Phase drawn %s\n", txt);

    UnbatchGraphics();
}
...
DrawTextInCorn("Text", PCMENU_SELECTION_TEXT_COLOR);
If anyone knows proper magics to make it work, please teach me. It would be good to show user some progress info, while layouter works...

I also decided to reuse the layouter in later steps to place on starmap important stars, some semi-important stars and some important constellations. And that's the plan.

-----------------------------
[Upd:]
Solved the text-drawing problem. Problem was in font, which was not loaded. In the not-yet-hacked initialization fleets get initialized before SC2 kernel (and fonts) is loaded.
8  The Ur-Quan Masters Re-Release / General UQM Discussion / Re: UQM stars/races relocation mod? on: December 23, 2015, 03:13:56 pm
I've decided to postpone dealing with the initialization hacking, until I have some real relocation algorithms working.
---------------------------------------
I integrated my graph layouting prototype for placing fleets and enforcing distance assumptions between them.
As expected, first prototype fails to solve the layouting.
For 24 participants and 132 assumptions I get 2-5 assumptions failing to resolve,
The failure is not too bad, and algorithm has a lot of potential for refinement. And that's the plan. I also made a simple starmap drawer, to see how layouter behaves...

This layouter algorithm is the hardest task in the whole endeavour, I should arm myself with patience...
9  The Ur-Quan Masters Re-Release / General UQM Discussion / Re: UQM stars/races relocation mod? on: December 20, 2015, 01:09:49 am
Alright. The communication-templating stuff is done.
--------------------
The initialization nightmare looks like this:
Code:
       [USER: run game]
        Starcon2Main
            BackgroundInitKernel
                getInitialFleetsDict
                LoadMasterShipList
                    x*load_ship - initialize all INITIAL states of fleets, loads some heavy resources
        
            cycle {
                StartGame
                    TryStartGame
                        RestartMenu
                            DoInput(DoRestart) -> loop main-menu, until "Start" or "Load" is chosen
                            [USER: enter "Load"]
            }
            
            InitGameStructures
                // init Fleets some more in their INITIAL states
                // set starting loc of Player Flagship
            
            ExploreSolarSys
                DoInput(InputFunc = DoIpFlight)
                    DoIpFlight(LastActivity == CHECK_LOAD)
                        SolarSysMenu(LastActivity == CHECK_LOAD --> MenuState.CurState = GAME_MENU)
                            DoInput(InputFunc = DoSolarSysMenu)
                                DoSolarSysMenu(MenuState.CurState = GAME_MENU, Save|Load = Load)
                                    GameOptions (LastActivity == CHECK_LOAD)
                                        PickGame
                                            DoInput(DoPickGame) -> loop in load-menu until save-entry is chosen
                                            [USER: choose save-entry to load]
                                            SaveLoadGame
                                                ConfirmSaveLoad
                                                    LoadGame
                                                        // update state of fleets
                                                        // set loc of Player Flagship
The structure is really bad, but no blaming devs - I can easily imagine how it emerged. That's what I call "Live Workaround Tree" (LWT). Almost all big-enough projects has similar degrading effect, when refactoring is considered to be too late and expensive... And I will not even try to fix the mess - it's just too complex. Thus workaround is the only possible choice - the only way to grow something on the LWT is to grow another workaround on it.

So, about the solution.
I'm aiming 2 modes for game start:
(A) init original starmap & fleets - considered to be fast
(B) init randomly relocated starmap & fleets - considered to be slow (especially due to fleets graph-layouting via springs)
These modes are already done.
Now to integrate them into LWT mess I need to introduce 2 more modes for game init, which will be orthogonal to (A)/(B):
(1) fake initialization - done before game is actually started or loaded (near BackgroundInitKernel and InitGameStructures)
(2) true initialization
The (1) should always be called in ORIGINAL MODE (A) before game is started/loaded. It will be used to load permanent resources into game. Later in procedure it is overwritten by (2).
The (2) may be in both ORIGINAL(A) and RELOCATIONAL(B) modes. It should be called only after player pressed "Start New Game". Game loading will need to be dealt additionally.

Cases:




10  The Ur-Quan Masters Re-Release / General UQM Discussion / Re: UQM stars/races relocation mod? on: December 18, 2015, 11:37:23 pm
Quote
I wasn't aware about the Algol thing though; I'm quite surprised to hear that the Spathi ventured that far from their sphere of influence.
Probably that's mistake by original devs. Or diplomatic trick(lie) by Melnormes - they mentioned this story about Spathies...
--------------
I've done quite some work for reorganizing code of galaxy initialization into 10-steps chain:
(1) Initialization of initial fleets
(2) Initialization of important stars
(3) Initialization of important constellations
(4) Initialization of semi-important stars
(5) Initialization of non-important constellations
(6) Initialization of non-important constellation-stars
(7) Initialization of non-important solo-stars
(8 ) Initialization of quasi-space locations
(9) Initialization of important coordinates
(10) Compilation of all previous steps results into a starmap

Most steps also produces dictionaries, which are required for templating dialogue files and for future relocation algorithms.
All this kitchen also requires to be saved/loaded with game saving/loading.
Also did alot of defensive programming, since my testing power is quite low.

Current structure works for original map, and contains placeholders for relocation algorithms, which should fit in easily.

I also made a prototype of graph-layouting algorithm based on springs. Works for simple cases, but fails to draw a house (medium-complexity case). I think it should suffice, if not, I'll refine it when introduce/test it in game.
---------------------------------------
Current plan:
(1) Finish templating of mentions in dialogue files of important constellations, semi-important stars. 90% done.
(2) Extract misplaced starmap initialization logics from game main-menu.

The latter one is an unpleasant surprise.
globdata.c has a InitGameStructures function, which initializes fleets and also turns on the START_INTERPLANETARY activity -
Code:
GLOBAL (CurrentActivity) = IN_INTERPLANETARY | START_INTERPLANETARY;
- which leads to call of ExploreSolarSys() in Starcon2Main(...).
ExploreSolarSys wants starmap and Sol to be already defined.
And all this is happening BEFORE game is actually started or loaded from main-menu.
I'll either have to introduce an ugly workaround for this, or redesign game initialization procedure, which is really-really complex. Both paths are painful. Undecided Most probably I'll just workaround this mess...

Only after those things are done, I can finally start filling in relocation algorithms (some of which are already successfully prototyped).
11  The Ur-Quan Masters Re-Release / General UQM Discussion / Re: UQM stars/races relocation mod? on: December 11, 2015, 09:29:34 pm
Death 999
Sorry, didn't understand you.
Currently I separate 3 categories of stars:
** important ones - homeworlds and artefacts
** semi-important stars/constellations - mentioned in dialogues
** non-important ones - can be freely randomized

If you meant semi-important stuff - it will get templated in dialogue files, get randomized names, will respect names and locations of important stars and fleets...

-----------------------------------
If anyone wishes to help - I would really benefit from having a single C-file program, compilable with gcc, runnable from Cygwin shell, and which would
** draw a graphical square map for hyperspace with a grid (galaxy size is 10000x10000; no need to zoom - just simplest top-down view)
** have a function to draw array of POINTs
** have a function to erase array of POINTs
Need it to test dozens of upcoming stars positioning algorithms.
12  The Ur-Quan Masters Re-Release / General UQM Discussion / Re: UQM stars/races relocation mod? on: December 06, 2015, 08:45:43 pm
CelticMinstrel
Yeah, I've dealt with those things. Everything mentioned here is dealt with.

As for distance assumptions in general (which are specified here). I will fill it more later. If you have anything to add there right now, I would be very grateful, if you do it in format used in the spec file.

The assumptions regarding Spathies are tricky. Melnormes mention, that they practiced colonization in Algol system (which is in Druuge SoI) and they are also aware of the Vux-related megabeast (which is by the north edge of galaxy). So the distance for them is not so much of a barrier. On other side, they didn't know about ZFP, until Mmrnmhrm (or Chenjesu (don't remember)) made an expedition to the centre of galaxy. Thus, I think these distance assumptions are not always to be dealt so strictly. But I've added the distance assumption between Spathi and Arilou (not yet committed).

-----------------
I had some unsuccessful trials with my code. Introduced some serious changes and hoped to debug/compile this in one blow. Well, that approach works with most of languages/projects, but not here. I got 10k or cyclicly reoccurring compile-time bugs with absolutely nonsensical descriptions... So I've lost few days on step-by-step reintegration of my solution into the project, and still have to spend 1-2 more days on that... An unpleasant part of work.

Actually, it's so damn cool, when you don't have the deadlines, like ones in industry.
13  The Ur-Quan Masters Re-Release / General UQM Discussion / Re: UQM stars/races relocation mod? on: December 01, 2015, 05:24:26 am
Yeah, it was easy one.

I'm currently in the middle of changing industrial project. Had to work overtime for whole weekend. Not much progress with the mod, thus.

In the mod currently finishing structuring 9-steps galaxy formation procedure, which involves steps like fleets placement, important stars placement, etc. Procedure will have two modes: step-by-step form original galaxy, and step-by-step form random one. It's filled with defensive structures, with intension to detect errors early. Once this procedure works fine for original map, I'll go on with making galaxy randomizer...
14  The Ur-Quan Masters Re-Release / General UQM Discussion / Re: UQM stars/races relocation mod? on: November 22, 2015, 01:45:36 pm
Finished and tested simple mentions (of important stars) with both communication files and lander messages. Dealing with Strings in C is really tricky and not easy at all - negative side of low level languages.
Finished analyzing mentioned constellations and semi-important stars. Also extracted some more assumptions about fleets and homeworlds.
Actually felt like a historican/archivist while reading through all that info. Cool Pleasant romantic work.

Hardest cases for positionining will be
>> 3 constellations in Arilou SoI (originally Chandrasekhar, Circini, Columbae). Will have to apply some simple maths here.
>> Horologii and Antares are already dealt with.
>> Lacaille and Krueger are to be placed in intersection of Pkunk and Ilwrath.
>> "the snake-like creature who has swallowed the elephantine beast"
>> Mira and Indi - inside Vux fleet, closer to Sol
Aldready have good math functions for most cases. The others mentions will be really easy to resolve.

I'll solve the hard-mentions extraction in the following manner:
** Will create 2 enumerations for them, similarly as important stars are enumerated (in gendef.h): important constellations and semi-important stars.
** There will be 2 dictionaries: [important constellation idx -> general constellation idx] and [semi-important star idx -> ptrStar], which will be filled as a result of relocation in a dedicated procedure solving assumptions.
** For non-relocational mode I'll fill those maps with semi-hardcoded stuff.
** The communication files will get inlined with variables (similarly like I dealt with important stars)
Code:
   
$${StarName:ImortantStarIdx=%d}
$${StarNameUC:ImortantStarIdx=%d}
$${StarName:SemiImortantStarIdx=%d}
$${StarNameUC:SemiImortantStarIdx=%d}
$${ConstelName:ImortantConstelIdx=%d}
$${ConstelNameUC:ImortantConstelIdx=%d}
15  The Ur-Quan Masters Re-Release / General UQM Discussion / Re: UQM stars/races relocation mod? on: November 21, 2015, 02:53:17 pm
From these 242 mentions there are 2 kinds of cases:
** Simple - will be able to deal with them atomatically.
** Hard ones - will need to handle them manually. Mentions of constellations (22) and non-important stars (8 ).

I'll deal with simple cases first. After that will need to describe assumptions for the hard ones. If anyone wishes to participate - fill in the table here:
https://sourceforge.net/u/uqm-logarithm/sc2/ci/master/tree/tools/for-relocation/data/mentioned-assumptions.xls
The context game-texts are in same XLS (on first sheet).
Pages: [1] 2 3


Login with username, password and session length

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Valid XHTML 1.0! Valid CSS!