itch.io

Well, it seems to be working now... and it seems like the issue was on my side.

The addition of the pre-launch Input Selector dialog made me look into the issue in more detail and try all the keys again. And, as it turns out, i didn't try all of them before. Several of them worked, and i was even able to enter a mission by pressing Q twice. Still, the WASD input didn't work a single bit. It felt... stuck. As if some gamepad was connected and the stick on it was pulled fully to the side.

Which made me check my gamepads(or the lack thereof) again using that html5gamepad site. Turns out there were two virtual gamepads, which were VJoy's fault, and they were outputting NaN(is that even legal?!) on most of their axes. 

I went to the Device Manager and shut them down. And yep, the game is now fully playable.

Long story short, i am not smart.

Sorry for wasting your time like that. I'll go ahead and finally try the game out properly, probably tomorrow. Though i did play it for like 5 minutes today after i figured out my input issues and, unsurprisingly, it looks and feels really good.

I think you should keep the pre-launch Input Selector enabled, though. It's quite the useful thing, allowing players to tune the settings(input, graphics quality, screen resolution) through a reliable UI.

Yeah... sorry again. I should've handled this better

Not sure what you mean by "your keyboard is English", but i am writing in English right now using it, so i suppose it is.

I didn't put any energy into the components because i didn't even get the steering under control. Again, the game doesn't acknowledge the existence of my keyboard at all, and doesn't really cooperate with VJoy, either. Shooting weapons is secondary to moving and, most importantly, being able to navigate the main menu to be able to start a game.

Which, by the way, doesn't work with the keyboard, either. The only way i managed to start a game is by fiddling with the game by emulating a gamepad via VJoy. Using the keyboard directly doesn't even allow me to select things in the main menu.

Again, i think you should toggle the Input Selector™ on for this project just in case people encounter the same issues i did. There's no guarantee it would help but... it wouldn't hurt, that's for sure.

Hope you fix it soon.

Man, thing looks real damn fun, but it just doesn't wanna cooperate. I do not currently have a gamepad available, and, contrary to what your description says, the game seems to be completely unaware of my keyboard's existence.

I downloaded VJoy and even x360ce, but to no avail. The closest i got to a playable state was being able to steer my ship... although the directions were inverted. Couldn't fire my weapons, couldn't do the (oh-so-awesome) inertial flight, couldn't even navigate the menu properly.

Judging by the trailer, this game is amazing. But it's ridiculously unusable as of now, at least for those who don't own a gamepad.

And yeah, yeah, i know, not owning a gamepad in 2019 is somewhat ridiculous. But IMO, this doesn't seem like the kind of game that would benefit from gamepad input. In fact, it might just be a bit too complex for gamepad input, i reckon, and would be more playable with a keyboard.

Whatever the case, please fix your input system and make sure it handles the keyboard properly. And/or maybe tell Unity to show the prelaunch input manager.

Hope you handle this issue soon. Can't wait to blast these alien bugs to bits.

My OS is Windows 10, if that's of any help. Not sure what other kind of system info would be useful. If you need any more details, please reply.

It's me again. Working on some autonomous multi-binary and managed to break the game. The main base somehow built the turret even though there was not enough data to build it.

http://imgur.com/a/dxQB0 

The code that probably caused this weird bug(pretty messy but i'm currently working in "as long as it works" mode):

enum{
TARGET_BUILT_BY,
TARGET_RIGHT,
TARGET_BACK,
TARGET_LEFT,
TARGET_FWD,
TARGET_BUILDER,
TARGET_SCOUT,
TARGET_COMM,
TARGET_SCAN1,
TARGET_SCAN2,
TARGET_SCAN3,
TARGET_SCAN4,
TARGET_SCAN5,
TARGET_SCAN6,
TARGET_DEFENCES,
TARGET_ENEMIES_SEEN = 32
};
enum{
TURRET_DEFENCE_RATING = 15,
INTERIOR_DEFENCE_RATING = 5,
WALL_DEFENCE_RATING = 20
};
enum{
TEMP_BUILDER,
TEMP_MINER,
TEMP_BASE,
TEMP_SHIP1,
TEMP_SHIP2,
TEMP_SCOUT,
TEMP_TURRET,
TEMP_INNER,
TEMP_WALL
};
int empty_defence_slot;
int buffer;
int buffer2;
int defences_rating;
int largest_enemy_attack_size;
int perform_defence_scan;
//...
perform_defence_scan--;
//...
if(scan_for_threat(...))
//...
}else{
if(perform_defence_scan<0){
perform_defence_scan = 40;
defences_rating = 20;
//Base counts for 20 defence
for(buffer = TARGET_DEFENCES; buffer<TARGET_ENEMIES_SEEN; buffer++){
if(process[buffer].visible()){
switch(process[buffer].get_template()){
case TEMP_TURRET: defences_rating += TURRET_DEFENCE_RATING; break;
case TEMP_INNER: defences_rating += INTERIOR_DEFENCE_RATING; break;
case TEMP_WALL: defences_rating += WALL_DEFENCE_RATING; break;
}
}
}
}
auto_stability.set_stability(0);
auto_harvest.gather_data();
auto_allocate.allocate_data(2);
if(empty_defence_slot != -1)
if(defences_rating<largest_enemy_attack_size&&random(3)==2){
buffer = random(3) + TEMP_TURRET;
buffer2 = random(8000);
switch(buffer){
//The next line is, i bet, what caused the bug:
case TEMP_TURRET: build_process(buffer, cos(buffer2, 400), sin(buffer2, 400), buffer2, empty_defence_slot);
//as we can see on the screenshot, the process that was just built is TEMP_TURRET
case TEMP_INNER: build_process(buffer, cos(buffer2, 200), sin(buffer2, 200), buffer2, empty_defence_slot);
case TEMP_WALL: build_process(buffer, cos(buffer2, 600), sin(buffer2, 600), buffer2, empty_defence_slot);
}
}
//Deploys a builder if none present, otherwise deploys a scout if none present
if(get_available_data()>1000){
//Deploys a random unit
}
}
//Other code, including the code that keeps targeting memory consistent by collapsing all the gaps between TARGET_DEFENCES
and TARGET_ENEMIES_SEEN, and also between TARGET_ENEMIES_SEEN and 64

This code is only partial, if you need the whole process, or even the whole pack of processes, tell me and i'll send you a .zip of all .c files + the seed & settings for this battle.

Although it doesn't seem like that outcome can be replicated, not sure how that is possible. Just tried to re-do that battle, no bug this time.

Well... it mostly works. switch() throws an error if the difference between cases is higher than 32, which isn't deadly, but surely can be improved.

But yeah, sorry for my stupidity, enum constants value assignment sure works.

lel nevermind me then

I think i didn't even try that stuff out, which is a gg for me, i just kinda assumed that since you cannot assign values to variables on declaration, you cannot assign them to enums. Plus i don't think any designs in campaign use that feature, maybe i just didn't notice that tho.

Thanks for the response. Now i shall go continue working on my processes.

I've been playing this game occasionally for like two months by now, recently beat the normal difficulty and am working on a decent multi-binary to go into the normal(autonomous) difficulty.

I do love the game, but the code editor/compiler has several albeit small issues. Probably the most annoying one is that you cannot assign values to enum entries, which means that if you want to keep your message protocols consistent, you gotta have the same message type enum in every process, even if this process only uses one type of message. So it ends up as a waste of space(2048? lines max), + a waste of time since you gotta go into every process and update the enum.

enum{
//500-599 REQUEST
MSG_REQUEST_ESCORT = 500,
MSG_REQUEST_BUILDER = 501,
//600-699 FOUND
MSG_WELL_FOUND = 600,
MSG_ENEMY_FOUND = 601
};

Something like that would be awesome.

Now that i think about it, you could use variables to hold stuff like that, yes, but that's a waste of memory and a waste of instructions, since assigning a variable does use up several instructions.

Also i was thinking, maybe create lookup tables for math operations like sin/cos and possibly even atan2? There are only ~8k possible angles in-game, so a lookup table for a sin operation would be around 32 kilobytes(float(4 bytes)*8k angles) which isn't that bad, but with such a lookup table loaded sin and cos operations are just wrapping the angle + looking up the result + some multiplication. Not sure if this applies to atan2 though - the amount of possible inputs is infinite, and even for the visible area(900 pixels*900 pixels) is quite big(~1.6 megabytes for a lookup table). But in the end it ends up as a single operation against 16 that atan2 currently uses.

If you somehow manage to set up the atan2 lookup table to take arguments and convert it into an index in the lookup table we do end up with 32 kilobytes yet again, not sure if that's possible in less than 16 operations tho.

Not sure if that's worth the trouble though, because you'd rarely use more than one atan2 call in a process. 

(edit)Another thing i forgot to suggest, while not really related to the compiler, it would be great to have more options in the Custom Game screen. Ideally a map editor, of course, but adding some simple settings is enough. Like, Spawn Distance From Wells. At the start of a custom game, green and purple bases fail to spawn their defense processes because they're too close to a well, which prevents them from participating in the battle properly. Also please add fields like Well Replenish, Well Reserve 1 and Well Reserve 2 for better control over custom game wells, with an option for endless wells.