Sandworm

It would be really nice to get a few options in regards to the debug console: 1) Option to set number of lines shown / use more than half the screen 2) Scrolling up - some mistakes output more then you can fit on a screen 3) Fontsize would be nice - the eyestrain can get pretty bad

'background' as in alt-tabbed out to my browser - mute the game if it's not the 'front' application.

Title

Method to get the users current UI color scheme (Settings->Graphics->UI Color)

I don't think it needs to be either/or. I like the idea of turret factories, I think the idea of making copies is reasonable, I definitely think goods should be used as well as resources. As for your last option; I think turret factories could play a much bigger role in item progression. My 'idea' (and I'll be the first to admit a not terribly well thought out idea) would be to make all weapons not made at a turret factory, standard in every way. A Tech 6 Iron Triple Chaingun drop would always have the same stats as any another Tech 6 Iron Triple Chaingun - a turret factory where the player makes a Tech 6 Iron Triple Chaingun will always have better stats then its ~Costco~ equivalent. Drops from enemy ships then could have a *small* chance of dropping these better weapons, but for the most part it will be up to the player to find and use a turret factory if they want better weapons. Research stations would be a bit more interesting - (5)Tech 6 Iron Triple Chainguns would get you (1)Tech 7/8/9 Iron Triple Chaingun, again with standard stats, but with the possibility to return an "enhanced" (as if made at a turret factory) version. I know there are a dozen little details I'm not thinking about, but I hope you get the gist of my 'idea' ;D

Hi Qui_Sum, Before I start, I want to make sure we're on the same page. In my message I refer to 'front-facing' turrets, this is different from 'turrets on the front-face'. Mine would be sitting on the top/bottom/'left/right'side of a block that's towards the front of the ship, not ON the front 'face' of a block. I also want to emphasize that I'm talking about starter ships with 2-3 mining lasers not a ship with 20 mining lasers facing every direction/top and bottom where I imagine even the dumbest ai could randomly accidentally point the ship in a suitable direction. While I appreciate that 'players love to design their own ships', a quick look at the workshop shows that 99.9% of all ships have a 'front' direction. Watch any video of players mining, and you will see them point straight at an asteroid, boost into range, stop and then start mining - only moving a little bit to get in range of the back side of the asteroid. I ask only that the AI use the same common sense. I don't think I'm being unreasonable here when I say people expect a ship to mine when they tell it to, not dance all around the asteroid occasionally firing mining lasers into empty space for an hour. I think anyone who has actually played this game can attest to the fact that *where ever* you place your turrets, your captain will find a way to point the ship in the exact opposite direction needed and sit there dumbfounded rotating on the wrong axis while you debate alt-f4'ing. Again, I'd like to stress the 'I' in AI. Would it not be 'intelligent' for the AI to consider that the front 'area' of the ship has turrets facing 'forward' and at least try to mine from a head on position and then try doing it's weird little dance around the object if that didn't work? I've got nothing against figuring out what works, but that would require a state where it actually does work, and I've yet to see anything from the AI to suggest that there is an optimal way to place turrets. Or should I say, I've yet to see the AI behave in a reasonable human like manner. Maybe I can put it another way: when I ask a ship to mine and it behaves so erratically trying to accomplish that task, I don't think to myself 'hey maybe the developers want me to design my ship differently' - no, I think to myself the design is perfectly rational/normal and yet for some reason it can't accomplish this basic task, something must be broken. Anyways, thanks for reading - I hope there is a compromise to be had somewhere.

One of the first things a player is likely to do is build a small mining ship and hand it over to a captain. The amount of time the player spends designing this ship will be directly proportional to the amount of disappointment they feel watching their ship flounder around trying to accomplish what they believe to be a simple task. To solve 90% of likely ship layouts: Point the front of the ship at the center of the asteroid, move into range, fire lasers. The concept is simple, the math is simple, yet we still have ships that look like they're piloted by drunks, and at this point I'm pretty sure alcohol is a contributing factor. What about the other 10% of layouts: Orientation Blocks. Blocks that can 'point' in one of six cardinal directions. Turrets on these blocks can be assumed to fire in the relative direction of said block and the 'AI' can go about aligning the ship so that those blocks are 'pointing' at the target. If the target is an asteroid, the code can search for orientation blocks with mining lasers on them, salvage can search for orientation blocks with salvaging lasers, absent any blocks for the love of god use the 'front' of the ship for alignment to point at target.

... window UI elements to be displayed without losing keyboard and mouse focus to said window? So one day we might have something like attached image?

callback onShotFired(entityId) Executed whenever a shot is fired in the sector Parameters entityId The index of the firing entity After at least an hour of quit/edit/load/quit/edit/load/quit/edit/load/quit/edit/load/quit/edit/load/ quit/edit/load/quit/edit/load/quit/edit/load/quit/edit/load/quit/edit/load/ quit/edit/load/quit/edit/load/quit/edit/load/quit/edit/load/quit/edit/load/... I finally figured out that the entityId returned to the callback is the turret id ***NOT THE CRAFT ID*** Don't get me wrong, I understand *now* that turret id is returned - I just don't understand why you couldn't specify that it was the turret id returned - not the ship id. Ship is an Entity --True Turret is an Entity --True Callback returns 'index of the firing entity' Did the ship fire a shot --Yes Did the turret fire a shot --Yes To make my point clear - you simply cannot label everything in the documentation an 'Entity' without clarifying what 'Entity' refers to. I'd be really interested in knowing the developers position on modding - is it something they're adding as a 'little extra' - or do they realize that a heavily modifiable game makes for a dedicated modding community which makes for a quantifiably bigger reason to by the game.

Which browser/version are you using out of curiosity? Edit: I see now that there could be a few layout issues. Most of the header elements are lacking specific sizing, font sizes are left up to the browser etc. so placement of 'fixed' elements is probably a bad idea. I'll go through it again and see if I can lock everything down to specific sizes *or* make sure everything is relative.

All API documentation in a single html file. Has a filter script that filters on function names and properties only. Dark theme with emphasis on important areas like function name and property name. Quick navigation to each section under Goto menu. This was originally a personal project, tailored to how I use the documentation, and as it stands is incomplete in functionality. I plan to add better descriptions and examples as I learn/mod more. In a document that started with over 60k lines and is now just over 40k lines there's bound to be a few mistakes, if you find one, let me know. If you have any suggestions, I'd be happy to accommodate if I can. ***May take a bit of CSS fiddling to get it to look right - working on fix (9/1/18) SingleFileDocs.zip

Sometime I just have to laugh at myself. For me, this is a single player game. When I made my original comment I never even considered having to synchronize clients over the internet. And now that you brought it up, I *do* remember seeing this post on Stack Overflow but didn't actually scroll all the way down to read some other answers. Live and learn. As far as implementing QueryPerformanceCounter - I don't see myself using it, nothing I plan on modding needs that kind of precision. However, with hopes that you (the developer) may read this - could you please keep this project in the back of your minds, or others like it - I know it's a long shot, but my brain tingles with the possibilities.

The main problem is in the script for salvaging, small pieces of wreck with no material value are complete 'invisible' to salvagers. This can be changed easily, but doesn't outright solve the problem. To completely solve the problem we need to 'cheat' just a little and delete small objects around the salvager when it gets stuck. I'm doing some work on the salvage script to fix that and travel speed and a few other things that bug me. Will post when done.

Depending on how GalaxyMap():setSelectedCoordinates(x,y) works (if it allows setting multiple selections without clearing previous ones) #1 may be possible. Since the search function in the Galaxy Map allows for multiple sectors to be selected at the same time this *should* be possible. #2 is almost certainly possible with the above function. If setSelectedCoordinates means set *jump* coordinates - then ya, neither #1 or #2 is possible with scripting. I would have tested this out myself, but I'm still at the stage of trying everything out using the console '/run' command, and it appears that any command entered that way is run in the 'Server Context' and GalaxyMap() is client side only.

Using code similar to: weaponsCheckBox = window:createCheckBox(Rect(vec2(150, 30)), "Weapons"%_t, "onWeaponsChecked") weaponsCheckBox.tooltip = "Researches weapons ONLY"%_t Produces a combobox, but not the associated tooltip on mouse hover.