Author Topic: Change Log for v7.2 Discussion  (Read 135699 times)

0 Members and 3 Guests are viewing this topic.

Offline Erik L (OP)

  • Administrator
  • Admiral of the Fleet
  • *****
  • Posts: 5654
  • Thanked: 366 times
  • Forum Admin
  • Discord Username: icehawke
  • 2020 Supporter 2020 Supporter : Donate for 2020
    2022 Supporter 2022 Supporter : Donate for 2022
    Gold Supporter Gold Supporter : Support the forums with a Gold subscription
    2021 Supporter 2021 Supporter : Donate for 2021
Re: Change Log for v7.2 Discussion
« Reply #300 on: July 07, 2016, 09:03:18 AM »
I'm not sure most mobile devices would handle even C# aurora too well, but I imagine it should be possible to have a host server running Aurora with automatic turn processing while players using a browser or mobile could access the database and control individual empires.   
That would be great :D .
I doubt Visual Basic is flexible enough to do it.

VB6 No. But VB.NET most certainly could. You'd probably be limited to Windows devices though.
 
The following users thanked this post: icecoldblood

Offline viperfan7

  • Warrant Officer, Class 2
  • ****
  • v
  • Posts: 61
  • Thanked: 6 times
Re: Change Log for v7.2 Discussion
« Reply #301 on: July 07, 2016, 11:23:10 PM »
I don't think windows mobile can even run VB.NET.

I just think it could be a nifty side project to have aurora mobile with the C# aurora as well, along with support for remotely stored DBs.

Hell my phone has almost as much RAM as my PC. Yes, aurora is processor intensive but since its turn based (Or whatever you want to call auroras turn system, there's nothing quite like it anywhere) its not a big deal, just means you'll wait longer to process things.

Hell, I'd be more then happy to buy a mobile version of it, if it ever happens
 

Offline MarcAFK

  • Vice Admiral
  • **********
  • Posts: 2005
  • Thanked: 134 times
  • ...it's so simple an idiot could have devised it..
Re: Change Log for v7.2 Discussion
« Reply #302 on: July 08, 2016, 12:40:48 AM »
I was actually considering the possibility of multiplayer, a server runs the game while letting you use a client version to queue up commands for your empire. I'm sure someone could do a terribly buggy version of this using memory and database hacking when C# drops. Didn't someone make a utility that allowed a spreadsheet to access database information for sorting or organising I other ways? Could even have been possible to do something like that with VB aurora, hell people have made multi client dwarf fortress or KSP somewhat workable, old aurora should work pretty well as everything's in the database as long as you only have a single turn process thread running and come up with a good method of resolving commands coming in from multiple sources.
" Why is this godforsaken hellhole worth dying for? "
". . .  We know nothing about them, their language, their history or what they look like.  But we can assume this.  They stand for everything we don't stand for.  Also they told me you guys look like dorks. "
"Stop exploding, you cowards.  "
 

Offline Rewstyr

  • Gold Supporter
  • Leading Rate
  • *****
  • Posts: 8
  • Thanked: 1 times
  • Discord Username: Rewstyr#8870
  • Gold Supporter Gold Supporter : Support the forums with a Gold subscription
    2021 Supporter 2021 Supporter : Donate for 2021
    2023 Supporter 2023 Supporter : Donate for 2023
Re: Change Log for v7.2 Discussion
« Reply #303 on: July 08, 2016, 03:37:25 AM »
Although I think I know the answer I want to ask just in case.   Is there any possible way to get the source code for a port to Android/iOS?  I am a developer and would love to play this game on mobile.  Not sure how it would work out on smaller screen space but would be something interesting to look into.

Steve
 

Offline linkxsc

  • Commander
  • *********
  • Posts: 304
  • Thanked: 16 times
Re: Change Log for v7.2 Discussion
« Reply #304 on: July 08, 2016, 07:03:56 AM »
I was actually considering the possibility of multiplayer, a server runs the game while letting you use a client version to queue up commands for your empire. I'm sure someone could do a terribly buggy version of this using memory and database hacking when C# drops. Didn't someone make a utility that allowed a spreadsheet to access database information for sorting or organising I other ways? Could even have been possible to do something like that with VB aurora, hell people have made multi client dwarf fortress or KSP somewhat workable, old aurora should work pretty well as everything's in the database as long as you only have a single turn process thread running and come up with a good method of resolving commands coming in from multiple sources.

I had been actually thinking of something along those lines too. Basically, each player would be a "task group" with all task group commands available. They'd make their commands, and the server would update at a set interval executing the commands of each player and their TG.
Things like player personal funds could be tracked externally to aurora.
But it would be terribly inefficient.

Also for travel, I totally forgot about ye olde hyperdrives. TBH I don't even know how they worked, and i can't get old versions of aurora to run properly to mess with them.
 

Offline Kytuzian

  • Sub-Lieutenant
  • ******
  • K
  • Posts: 132
  • Thanked: 9 times
Re: Change Log for v7.2 Discussion
« Reply #305 on: July 08, 2016, 08:25:45 AM »
You could build a super-crappy multiplayer right now if you make a program that takes screenshots of the various reports in-game and accepts commands command-line style like "build earth infrastructure 100 100", then manipulates the game through mouse clicking emulation and such. I've done not-dissimilar things in the past.
 

Offline linkxsc

  • Commander
  • *********
  • Posts: 304
  • Thanked: 16 times
Re: Change Log for v7.2 Discussion
« Reply #306 on: July 08, 2016, 09:27:30 AM »
Tbh the biggest bottleneck is the server. Which would be playing the game in sm mode at intervals... and with a lot of stuff going on, a 5 sec incriment can often take more than 5s
 

Offline QuakeIV

  • Registered
  • Commodore
  • **********
  • Posts: 759
  • Thanked: 168 times
Re: Change Log for v7.2 Discussion
« Reply #307 on: July 08, 2016, 12:49:11 PM »
This game is in general not remotely suited to multiplayer right now.
 

Offline ndkid

  • Warrant Officer, Class 1
  • *****
  • n
  • Posts: 86
  • Thanked: 4 times
Re: Change Log for v7.2 Discussion
« Reply #308 on: July 14, 2016, 10:35:22 AM »
I was trying to avoid the current exploit where you can repair a large amount of damage by undergoing a small refit. However, you have a good point about not repairing something you plan to replace anyway. Perhaps it might be better to allow the refit but not repair any damage to components that remain in the new ship. Alternatively I could have a Refit & Repair task which combines the two.

I would be tempted to go with the refit not repairing any damage to components that remain in the new ship. In the case of changing the amount of armor as part of the refit, go ahead and do the repair, because I don't think an elegant alternative. Not repairing leaves the option for someone to take a wounded vessel right back out if the situation is critical enough, just with the latest weapon systems, which seems... dramatically interesting. :-)
 

Offline 83athom

  • Big Ship Commander
  • Vice Admiral
  • **********
  • Posts: 1261
  • Thanked: 86 times
Re: Change Log for v7.2 Discussion
« Reply #309 on: July 14, 2016, 04:19:26 PM »
How about Refitting + adding repair costs to components that you do repair and not replace?
Give a man a fire and he's warm for a day, but set fire to him and he's warm for the rest of his life.
 

Offline JOKER

  • Chief Petty Officer
  • ***
  • J
  • Posts: 49
  • Thanked: 3 times
Re: Change Log for v7.2 Discussion
« Reply #310 on: July 27, 2016, 10:08:05 PM »
Though Steve is working on Aurora C# now, I still wondering about some min-maxing in game mechanic.

Currently my design become beehive-like missile launcher in space, solely focusing on missile alpha strike and rely on AMM as their only defence. This design works extremely well in battle, but become less and less interesting, as I can easily lock on NPR AMM ship and got them in first wave, then got others in the second.

Beam weapon is little more than crap. Steve once said he don't want some ship sail through AMM spam with impunity, but Beam ship have to, or several enemy beam ship could beat crap out of what's left of them. It's like bring a knife into gunfight.
« Last Edit: July 27, 2016, 10:18:40 PM by JOKER »
 

Offline DaMachinator

  • Sub-Lieutenant
  • ******
  • Posts: 108
  • Thanked: 5 times
Re: Change Log for v7.2 Discussion
« Reply #311 on: July 28, 2016, 07:45:15 AM »
Though Steve is working on Aurora C# now, I still wondering about some min-maxing in game mechanic.

Currently my design become beehive-like missile launcher in space, solely focusing on missile alpha strike and rely on AMM as their only defence. This design works extremely well in battle, but become less and less interesting, as I can easily lock on NPR AMM ship and got them in first wave, then got others in the second.

Beam weapon is little more than crap. Steve once said he don't want some ship sail through AMM spam with impunity, but Beam ship have to, or several enemy beam ship could beat crap out of what's left of them. It's like bring a knife into gunfight.


Which is why the proper use for beams is on fighter swarms too small to be picked up by enemy active search sensors. With ridiculous amounts of thermal reduction for added stealth.
The maximum speed of any ship or missile with a given engine technology is the speed of a ship composed only of one engine of that technology with the highest power to weight ratio possible with current technology, and nothing else.
 

Offline JOKER

  • Chief Petty Officer
  • ***
  • J
  • Posts: 49
  • Thanked: 3 times
Re: Change Log for v7.2 Discussion
« Reply #312 on: July 28, 2016, 01:33:59 PM »

Which is why the proper use for beams is on fighter swarms too small to be picked up by enemy active search sensors. With ridiculous amounts of thermal reduction for added stealth.

It's impossible. NPR AMM sensor will pick up them on ~80m range. Then you can see the great old AMM spam.

If there would be any remake on beam weapon, I want to see some old-style battleship duel at ~100m or 200m range. But it will require remake on lock-on and hitting mechanic, and avoid focusing all firepower on one target. Some player put most sensors on one ship, it will be very bad to got it toasted in one salvo.

Maybe Steve could introduce random distribution on beam weapon hit. Beam weapon could lock on and fire at a battlegroup rather than a single ship , like what happens when you shoot bird flock with shotgun. And shield will be very valuable in this scenario, as we can't simply focusing all firepower on one ship to overcome it. But to avoid impenetratable shield, it may not recharge in battle, or only recharge when turned off.

I also want another two feature. It's annoying to assign hundreds of missile launcher on my ship, so I want "missile turret" to pack these launchers up. Build ship components with factory is a well-known trick to speed up ship building, I even use excel to optimize it, but I still hope we can simply build a "pack" including all components needed.

« Last Edit: July 28, 2016, 02:49:01 PM by JOKER »
 

Offline misora

  • Warrant Officer, Class 1
  • *****
  • m
  • Posts: 94
  • Thanked: 5 times
Re: Change Log for v7.2 Discussion
« Reply #313 on: July 28, 2016, 08:50:25 PM »

I also want another two feature. It's annoying to assign hundreds of missile launcher on my ship, so I want "missile turret" to pack these launchers up. Build ship components with factory is a well-known trick to speed up ship building, I even use excel to optimize it, but I still hope we can simply build a "pack" including all components needed.
That would be a good idea. I find that very annoying as well and a detriment to large fleet engagements as time goes on.

Would you mind sharing that excel sheet with us, I'm sure plenty of people would use it.
 

Offline JOKER

  • Chief Petty Officer
  • ***
  • J
  • Posts: 49
  • Thanked: 3 times
Re: Change Log for v7.2 Discussion
« Reply #314 on: July 28, 2016, 11:45:15 PM »
That would be a good idea. I find that very annoying as well and a detriment to large fleet engagements as time goes on.

Would you mind sharing that excel sheet with us, I'm sure plenty of people would use it.

Just use cost percent of each component to calculate how many factories should you assign for them, so that they will finish on the same day.

For example, your ship have 30% engine, 20% weapon, 10% sensor, other 40% are small components and armor that can't or not worth to build in factory. So I use 0.3/(0.3+0.2+0.1)=50% factory to build engine, 0.2/(0.3+0.2+0.1)=33% factory for weapon, 17% for sensor. If you simply assign all factory to engine than turn to other components, when they finish producting one kind of component, they stopped working until next time increment. It could save about 20 days for every batch.

But I'm not sure this 20 days worth it or not.