Author Topic: Star Citizen Dev Progress Watch  (Read 99452 times)

dsmart

  • Supreme Cmdr
  • Administrator
  • Hero Member
  • *****
  • Posts: 4790
    • Smart Speak Blog
Re: Star Citizen Dev Progress Watch
« Reply #105 on: July 28, 2018, 07:51:52 AM »
So the latest schedule is out. 3.3. is looking good and should be complete in time for an end of Sept release :emot-lol:

https://robertsspaceindustries.com/roadmap/board/1-Star-Citizen

https://www.reddit.com/r/starcitizen/comments/92l30i/330_to_360_progress_watch_update_20180727/

« Last Edit: July 29, 2018, 07:06:25 AM by dsmart »
Star Citizen isn't a game. It's a TV show about a bunch of characters making a game. It's basically "This is Spinal Tap" - except people think the band is real.

jwh1701

  • Hero Member
  • *****
  • Posts: 865
Re: Star Citizen Dev Progress Watch
« Reply #106 on: July 28, 2018, 11:43:22 AM »
So the latest schedule is out. 3.3. is looking good and should be complete in time for an end of Sept release :emot-lol:

https://robertsspaceindustries.com/roadmap/board/1-Star-Citizen

https://www.reddit.com/r/starcitizen/comments/92l30i/330_to_360_progress_watch_update_20180727/


No surprise this thread has you don't understand game development in it.



N0mad

  • Hero Member
  • *****
  • Posts: 579
Re: Star Citizen Dev Progress Watch
« Reply #107 on: July 28, 2018, 01:30:02 PM »
LOL So we've gone from 3.3 Gameplay:
  • Mission modularity and racing
  • Service Beacon Improvements
  • Repair Bot
  • Repair Ships
  • [Refuel] Collection
  • [Service Beacon] Escort
  • [Service Beacon] Refuel
  • [Service Beacon] Repair
  • [Salvage] Scanning
  • [Salvage]Extraction
  • [Salvage]Processing
  • [Salvage]Selling
  • Manual repair
  • Buy/Sell Fuel
  • Fuel Transfer

To:

  • Ship system degradation
  • Scramble Race Missions
  • Improvements to Retrieval and Delivery Missions
  • FPS Combat Missions
  • Asteroid Mining
  • Improvements to Mining on Planetary Bodies
  • Ping and Scanning
  • Transit system
  • Arena Commander and Star Marine REC rentals
  • Groups System Improvements
  • Improvements to Manned and Remote Turrets on Vehicles
  • No Fly Zones
  • Item Kiosk Shopping improvements


So the only actual new gameplay we can expect from 3.3 will be some asteroid mining and FPS combat missions.

So once again CIG has moved the goal posts and kicked the promised gameplay features into 2019.

Even the zealots are noticing.


dsmart

  • Supreme Cmdr
  • Administrator
  • Hero Member
  • *****
  • Posts: 4790
    • Smart Speak Blog
Star Citizen isn't a game. It's a TV show about a bunch of characters making a game. It's basically "This is Spinal Tap" - except people think the band is real.

N0mad

  • Hero Member
  • *****
  • Posts: 579
Re: Star Citizen Dev Progress Watch
« Reply #109 on: July 29, 2018, 02:57:10 AM »
I'm now waiting for them to realise that they can't add Hurston and kick that into next year aswell.

I suspect the zealots won't be happy about that.

dsmart

  • Supreme Cmdr
  • Administrator
  • Hero Member
  • *****
  • Posts: 4790
    • Smart Speak Blog
Re: Star Citizen Dev Progress Watch
« Reply #110 on: July 29, 2018, 04:36:14 AM »
I'm now waiting for them to realise that they can't add Hurston and kick that into next year aswell.

I suspect the zealots won't be happy about that.

It depends on how far they put it from everything else. Remember, these are just levels which they stream in on-demand with trigger points (beacons).

What's going to be really interesting is if it's ANYTHING like the procedural city from CitizenCon 2017

« Last Edit: July 29, 2018, 04:45:35 AM by dsmart »
Star Citizen isn't a game. It's a TV show about a bunch of characters making a game. It's basically "This is Spinal Tap" - except people think the band is real.

Penny579

  • Jr. Member
  • **
  • Posts: 57
Re: Star Citizen Dev Progress Watch
« Reply #111 on: July 29, 2018, 07:01:28 PM »
LOL So we've gone from 3.3 Gameplay:
  • Mission modularity and racing
  • Service Beacon Improvements
  • Repair Bot
  • Repair Ships
  • [Refuel] Collection
  • [Service Beacon] Escort
  • [Service Beacon] Refuel
  • [Service Beacon] Repair
  • [Salvage] Scanning
  • [Salvage]Extraction
  • [Salvage]Processing
  • [Salvage]Selling
  • Manual repair
  • Buy/Sell Fuel
  • Fuel Transfer

To:

  • Ship system degradation
  • Scramble Race Missions
  • Improvements to Retrieval and Delivery Missions
  • FPS Combat Missions
  • Asteroid Mining
  • Improvements to Mining on Planetary Bodies
  • Ping and Scanning
  • Transit system
  • Arena Commander and Star Marine REC rentals
  • Groups System Improvements
  • Improvements to Manned and Remote Turrets on Vehicles
  • No Fly Zones
  • Item Kiosk Shopping improvements


So the only actual new gameplay we can expect from 3.3 will be some asteroid mining and FPS combat missions.

So once again CIG has moved the goal posts and kicked the promised gameplay features into 2019.

Even the zealots are noticing.

You're too kind

Complete Features already claimed to be implemented

  • Asteroid Mining
  • Ping and Scanning

Fix currently broken features

  • Improvements to Mining on Planetary Bodies
  • Item Kiosk Shopping improvements
  • Groups System Improvements
  • Improvements to Manned and Remote Turrets on Vehicles
  • Improvements to Retrieval and Delivery Missions
  • Arena Commander and Star Marine REC rentals
  • No Fly Zones

Add New features

  • Ship system degradation
  • Scramble Race Missions
  • Transit system
  • FPS Combat Missions

Becuase a game where you can't go more than 40 mins without crashing, part degradation is a priority.
Transit system? where we travelling too with 1 system.
FPS Combat, good luck with 15fps shooter
Racing missions in the PU - this is better than existing racing module how?

Penny579

  • Jr. Member
  • **
  • Posts: 57
Re: Star Citizen Dev Progress Watch
« Reply #112 on: July 29, 2018, 07:05:00 PM »
This is part of the plan.

All the 'cool' features will be saved so they can be touted in the last quarter and be shown off in the Con man festival and help to maximise the speed of the hype train for the end of year ship sale where they make like 80% of there income.





dsmart

  • Supreme Cmdr
  • Administrator
  • Hero Member
  • *****
  • Posts: 4790
    • Smart Speak Blog
Re: Star Citizen Dev Progress Watch
« Reply #113 on: July 30, 2018, 04:45:16 AM »
This is part of the plan.

All the 'cool' features will be saved so they can be touted in the last quarter and be shown off in the Con man festival and help to maximise the speed of the hype train for the end of year ship sale where they make like 80% of there income.

I believe it's a combination of that, and the fact that they can't complete everything promised in any schedule. I personally can't wait to fly through a procedural city @ 5 fps
Star Citizen isn't a game. It's a TV show about a bunch of characters making a game. It's basically "This is Spinal Tap" - except people think the band is real.

dsmart

  • Supreme Cmdr
  • Administrator
  • Hero Member
  • *****
  • Posts: 4790
    • Smart Speak Blog
Re: Star Citizen Dev Progress Watch
« Reply #114 on: July 30, 2018, 01:08:13 PM »
Gorf brought this to my attention. It's regarding the problem with missiles @ 5:19


I just don't understand this nonsense. He is describing a number of bugs and/or tech issues - right there. Let me explain.

1) Collision Detect

If a missile doesn't "reach" it's target or the collision isn't triggered, detonation will fail, as will #3

2) Prediction

If a missile travel path goes out of sync due to network problems (e.g. packets dropped), it will fly blindly, never reach or hit its target etc

3) Energy Transfer

If a missile does reach it's target, but collision fails, even if it explodes, there won't be any energy (damage) transfer; thus no damage taken by the target

4) Flight Dynamics

See #2



Here is how I do it in Battlecruiser/Universal Combat, based on an engine that's decades old now. Truly, this isn't rocket science if you know what you're doing.

If you have the GBS for UCCE 3.0 via the Steam forum, then you already know these stats.

MISSILE DEFINITION

Vagrant (Space-To-Space)

Code: [Select]
{
STS_VAGRANT.3D,STS VAGRANT,STR,~60000,A0.1526,L100,C1000,H5000,P105,R120,Y45,g3,(MTPRYAVE),E200,{1000,}15000,Q3500,[0,]5000
}

Cluster (Air-To-Air)

Code: [Select]
{
ATA_CLUSTER.3D,ATA CLUSTER,AT,~30000,A0.2289,L100,C1000,H5000,P100,R180,Y45,g2,(MTPRYAVE),E100,<100,>25000,{1000,}35000,Q2500,[0,]5000
}

SHIP DEFINITION

Super Carrier:

Code: [Select]
{
STORMCARRIER.3D,STORMCARRIER,SARc,
 ?24,*1000,!28500,%250,A0.1100,L125,C250,H300,&1800000,j90000,J120000,P9,R8,Y10,[2500,]5000,^60000,<100,>25000,{1000,}250000,(_PRYATVNEW)
}

Fighter:

Code: [Select]
{
STARDRONE.3D,STARDRONE,SARc,
 ?22,*1000,!10000,%100,A0.1068,L125,C300,H650,&600000,j20000,J15000,P20,R25,Y22,[250,]200,^35000,<100,>15000,{50000,}75000,(PRYATVNEW)
}

In my games, AIR/LAND/SEA/SPACE entities all have unique baseline dynamics and physics. Then each item has it's own unique (which augment and/or overload the baseline values) properties which determine how they perform.

Here is what each parameter means:

Code: [Select]
# [RADAR FLAGS]
#
# S  appears only in TASCAN space radar / missile can lock in SPC mode
# A  appears only in TASCAN air radar / missile can lock in AIR mode
# G  appears only in TASCAN ground radar / missile can lock in GND mode
# R  is a radar source or is missile with video feed capability
# T  threat (missile, mine etc)
# N  appears only in NID radar
# c  craft object type
# p  personnel object type
# r  strategic object type
# t  tactical object type
# i  interstellar object type
# m  misc object type
# L  cannot be destroyed by laser fire
# l  cannot be destroyed in multiplayer game
# I  cannot be destroyed at all
# F  cannot be destroyed by first person weapons
#
# [DYNAMIC FLAGS]
#
# P  can pitch                 
# R  can roll                   
# Y  can yaw                   
# A  can fly                   
# T  can translate in XYZ       // disabling this prevents object from moving
# E  has propulsion system     
# G  affected by gravity       
# U  can maneuver while on seabed (otherwise will not be able to move)
# F  can float at water level without sinking
# V  velocity diffs from orientation
# O  orientation independent of velocity
# M  missile               
# N  radar source
# X  explosion effect           
# B  laser blast               
# Q  uses quick render laser shot because model has no geometry
# L  uses elongated type laser shot
# Z  uses beam type laser shot
# _  support structure (another object can land on it)
# I  object is invisible while being rebuilt (must also have 'T' AI flag)
# H  object does NOT generate a shield animation when it collides with another object
# W  object can be towed
#
# [AI FLAGS]
#
# m = meter, ms = milisecond, min = minute, ft = feet, d/s = degrees per sec, m/s = meters per sec
#
# $  resource points              // resource points (NYI)
# @  defense points               // defense points (NYI)
# s  kill point                   // EPs awarded for destroying this target
# &  ship turnaround time   (ms)  // time for unit to re-launch after docking
# !  gun range              (m)   // range before unit fires the gun / range of projectile (fp weapons only)
# %  gun recharge time      (ms)  // gun recharge time
# ~  lifetime               (ms)  // missile self destruct time / laser shot (gun range/laser Hspeed) expiration time
# {  min acquisition range  (m)   // min missile lock range / min radar range for unit / max radar range for ground unit
# }  max acquisition range  (m)   // max missile lock range / max radar range for unit
# <  min altitude           (ft)  // min craft operational altitude / min missile launch altitude / min visibility altitude for ground unit
# >  max altitude           (ft)  // max craft operational altitude / max missile launch altitude / max visibility altitude for ground unit
# ^  missile reload time    (ms)  // time before unit reloads it's missile tubes
# Q  missile lock time      (ms)  // time before missile acquires a valid lock
# *  waypoint range         (m)   // range from waypoint before unit determines it has reached it
# ]  armor                        // unit's armor protection value
# [  shield                       // unit's shield protection value
# E  blast energy                 // missile/laser damage value
# P  pitch rate             (d/s) // rate of pitch
# R  roll rate              (d/s) // rate of roll
# Y  yaw rate               (d/s) // rate of yaw
# p  pitch spin rate        (d/s) // rate of spin along pitch axis
# r  roll spin rate         (d/s) // rate of spin along roll axis
# y  yaw spin rate          (d/s) // rate of spin along yaw axis
# L  low speed limit        (m/s) // low speed threshold
# C  cruise speed           (m/s) // cruise speed threshold
# H  high speed limit       (m/s) // high speed threshold
# A  best acceleration            // best acceleration
# D  best deceleration            // best deceleration. Presently == acceleration
# T  rebuild time           (min) // unit rebuild time
# J  jump transit time      (ms)  // hyperjump transit duration
# j  jump recharge time     (ms)  // hyperjump engine recharge time
# B  bounce elasticity            // 0 (no bounce, default) - 1.0 (rubber ball) 
# g  guidance type :              // type of guidance system for fire control systems
#
#       0 = none (default)                         
#       1 = CTL                         
#       2 = ATL                         
#       3 = ATL/V                         
#       4 = RITL/V                         
#       5 = VITL                         
#       6 = ASL                         
#       7 = VSL                         
#       8 = LTA (lasers only)                         
#       9 = ODSM                         
#      10 = RANDOM                         
#      11 = RKT (rockets)
#
# ?  object class                // object class/spec type
#
# [CLASS TYPES]
#
#       0  None 
#       1  Turret
#       2  Civilian structure       
#       3  Military structure   
#       4  Cargo pod
#       5  Personnel           
#       6  Asteroid
#       7  Space Force marine
#       8  Mobile Infantry marine
#       9  Elite Force marine
#      10  Mine               
#      11  Launch pad           
#      12  Probe           
#      13  Radar site
#      14  Enemy Air Defense           
#      15  Orbital Defense System
#      16  Supply Platform     
#      17  Naval craft           
#      18  Ground vehicle       
#      19  Close air support craft 
#      20  Shuttle
#      21  Transport
#      22  Fighter
#      23  Cruiser
#      24  Carrier             
#      25  Starbase             
#      26  Starstation
#      27  Surface To Orbit unit
#      28  Mobile Forward Base
#      29  Smoke grenade
#      30  Frag grenade
#      31  First person item
#      32  Naval sub
#      33  Naval LCAC
#      34  Assault Force marine
#      35  Recon Force marine
#      36  Engineering Corps marine
#      37  Medical Corps marine
#      38  Proximity grenade
#      39  Flash bang grenade
#      40  Anti-personnel mine
#      41  Wildlife1 (animals, reptiles)
#      42  Wildlife2 (birds, fish, insects)

Using the examples above, the Vagrant's fastest speed (amount = 5000 m/s) missile is much higher than the Stormcarrier speed (amount = 300 m/s), so once it's launched and locked, that ship has zero chance of escape. It can only jam, or if that fails, hope that the shield and armor withstand the impact. Also, the ship stands zero chance of out-maneuvering the missile because the latter has a faster PRY rate.

If a missile is fired in "dumb" mode without a lock, it just flies ahead until it either hits (see below) a target or it runs out of fuel and self-destructs.

If a missile is fired with target "lock", it will follow the target until it either hits (see below) a target or it runs out of fuel and self-destructs.

If the missile hits (energy transfer = E200) the ship, if the shield (amount = 2500) is down or less than 200 units, the energy transfer will breach the shield, thus transferring damage to the armor (amount = 5000). If no shield, then the armor takes damage directly. So it will take several missiles to breach the shields (which recharge over time), then the armor (no recharge, only repair), then the ship's hull. And even so, even with a shield-->armor-->hull breach, unless the damage to the hull hits the reactor core, the ship won't explode right away; it will just be disabled.

If the missile gets near the target, it doesn't actually have to touch it. There is a built-in proximity (base on size of target) fuse which immediately detonates the missile when it's close enough. The damage shockwave from the proximity blast (spherical), as well as missile shrapnel (individual bits with own energy/damage transfer), are what cause the actual damage to the target.

If somehow a ship manages to evade a missile until it's timer runs out, the missile will self-destruct (causing damage to anything within range).

As you can see, there are lot of other parameters which take other factors into account. It's why missiles in my games tend not to spell immediate doom when one (with or without lock) is fired at you.

Here watch this epic space combat battle in one of my games which shares that same engine with BC/UC




I have no idea why, after over 6 years they are still having problems like this, and which they should have solved since year one when they put in flight dynamics and missiles. It makes NO sense to me. And he says they don't have "time" for when it will be fixed. Wow.

I mean, look at this:

« Last Edit: July 31, 2018, 05:25:04 AM by dsmart »
Star Citizen isn't a game. It's a TV show about a bunch of characters making a game. It's basically "This is Spinal Tap" - except people think the band is real.

jwh1701

  • Hero Member
  • *****
  • Posts: 865
Re: Star Citizen Dev Progress Watch
« Reply #115 on: July 30, 2018, 07:08:45 PM »
That is a lot of interesting information on how you implemented missiles. I really wonder at times the real total of programmers working on SC. They claim they are at 500 employees and I just counted they have 96 job openings waiting to be filled if that is also true. To see the calling all devs and videos of semi believable people discussing the work it boggles the mind looking at the current state after 7 years. I wonder the missile issue stems from most likely ongoing issues of poorly implementing significant changes to the engine. Could the engine changes become one big tangled mess that has become to unwieldy? Years ago company I worked for ran into limitations on winpe and had to start over completely. 

N0mad

  • Hero Member
  • *****
  • Posts: 579
Re: Star Citizen Dev Progress Watch
« Reply #116 on: July 30, 2018, 07:11:12 PM »
I'd suggest that the problem might be to do with the silly numbers they're trying to throw at their physics engine. In a normal game you'd be in a ship moving relatively slowly relative to the grid origin, thus a missile tracking you would only be moving slightly faster ie. hundreds of m/s, therefore tends  of meters with each physics update - all easily handled.

In Star Citizen firstly they're all in orbit, thus already moving at thousands of m/s, then they probably also have an added velocity of thousands of m/s. Then throw in network issues and the physics engine just can't do accurate hit detection for either the missile strike or explosion.

That doesn't explain how missiles are just bouncing off things, unless the missile, having clipped through the hull thinks it's entered the the local physics grid of the given ship?

At least that's my guess.
« Last Edit: July 30, 2018, 07:12:49 PM by N0mad »

dsmart

  • Supreme Cmdr
  • Administrator
  • Hero Member
  • *****
  • Posts: 4790
    • Smart Speak Blog
Re: Star Citizen Dev Progress Watch
« Reply #117 on: July 31, 2018, 05:30:44 AM »
That is a lot of interesting information on how you implemented missiles. I really wonder at times the real total of programmers working on SC. They claim they are at 500 employees and I just counted they have 96 job openings waiting to be filled if that is also true. To see the calling all devs and videos of semi believable people discussing the work it boggles the mind looking at the current state after 7 years. I wonder the missile issue stems from most likely ongoing issues of poorly implementing significant changes to the engine. Could the engine changes become one big tangled mess that has become to unwieldy? Years ago company I worked for ran into limitations on winpe and had to start over completely.

Seeing as this missile issue is one of the more prevalent bugs, I don't think it has anything to do with engine changes. Physics and flight dynamics aside, their 64-Bit kludge is the main cause of issues like this. I wrote about it back in 2015 and again (watch that video) last month in a Twitter thread.
Star Citizen isn't a game. It's a TV show about a bunch of characters making a game. It's basically "This is Spinal Tap" - except people think the band is real.

satoru

  • Newbie
  • *
  • Posts: 6
Re: Star Citizen Dev Progress Watch
« Reply #118 on: July 31, 2018, 09:03:44 AM »
I'd suggest that the problem might be to do with the silly numbers they're trying to throw at their physics engine. In a normal game you'd be in a ship moving relatively slowly relative to the grid origin, thus a missile tracking you would only be moving slightly faster ie. hundreds of m/s, therefore tends  of meters with each physics update - all easily handled.

In Star Citizen firstly they're all in orbit, thus already moving at thousands of m/s, then they probably also have an added velocity of thousands of m/s. Then throw in network issues and the physics engine just can't do accurate hit detection for either the missile strike or explosion.

That doesn't explain how missiles are just bouncing off things, unless the missile, having clipped through the hull thinks it's entered the the local physics grid of the given ship?

At least that's my guess.

Its not that there arent people working on it

The problem is that the work they do is often thrown out, rendered redundant, etc

Imagine you are told "we're making a bike" so you design a bunch of things

then you hear " well now its gonna be an electric bike". Ok well don't have to throw out everything we can retrofit a few things maybe a few off the shelf components

then you hear "I want a foldable electric bike". Ok well the frame has to redesigned, where are we gonna put the battery now?

then you hear "I want a foldable hybrid gas electric bike for range". Really? ok ok our gear system isn't designed for gas motors plus we'd have to redesign the chain system

Then you hear "acutally we should just design a hybrid moped". what in the actual ... like now we gotta redo everything. we'll need revamp our manufacturing to handle larger pressed metal. maybe we can get a 50cc engine from...

Then you hear "well actually we need an all electric RV".......... what................

Their issue isnt people. its that they keep having to reinvent the entire architecture, structure, etc every year because Chris wants 'something'. Its 7 years now but 6 of it was thrown away because they don't have a project manager that says "STOP"

jwh1701

  • Hero Member
  • *****
  • Posts: 865
Re: Star Citizen Dev Progress Watch
« Reply #119 on: July 31, 2018, 12:40:30 PM »
Seeing as this missile issue is one of the more prevalent bugs, I don't think it has anything to do with engine changes. Physics and flight dynamics aside, their 64-Bit kludge is the main cause of issues like this. I wrote about it back in 2015 and again (watch that video) last month in a Twitter thread.

I remember reading that along time ago, great write up concerning what they say vs reality. I also remember them not knowing the ships were not underwater depending on location from an early SC video. From hindsight I wonder how they did not know if they poached engineers from crytek?
« Last Edit: July 31, 2018, 01:01:30 PM by jwh1701 »

 

SMF spam blocked by CleanTalk