0.6 plans

Development directions, tasks, and features being actively implemented or pursued by the development team.
Post Reply
Deus Siddis
Elite
Elite
Posts: 1363
Joined: Sat Aug 04, 2007 3:42 pm

Re: 0.6 plans

Post by Deus Siddis »

safemode wrote: we need to stop kidding ourselves that what vs brings are these huge do what you want universes (systems).
We're not talking about what is there now, we're talking about potential. VS as a game is heavily broken but it has done some things well otherwise no one would be here right now trying to fix it. All I'm saying is don't slam the door shut on this, leave it cracked open. Allow late game players who have acquired large advanced ships or fleets of them to head into the wilderness seeking a different game experience and higher risks and rewards. If they choose. Or they can choose to continue to stay in the civilized jump network trade routes.

Right now there is no campaign and the dynamic universe is too nebulous, random and static. Both things can be fixed, but not if we force ourselves arbitrarily to just make another scripted campaign game.
safemode wrote: games that are fun == players == development interest == artists == better game. which is what our goal should be.
Yes but look around you, how many open source scripted campaign games do you see that are successful? Such games require a huge amount of content and can only really be played once. So you need a lot of contributions to make them happen but they don't attract the long term interest necessary to produce so much content from volunteers. I'm not saying scripting should be avoided completely, but you shouldn't look to it for salvation for it has not at all proven itself.
Primordial wrote:From a player standpoint, the problem with the sandbox as it stands is that nothing you do seems to affect anything.
And that's a major balance and feature oversight that needs to be fixed. Factions should produce fewer ships and store them up to attack in waves against specific infrastructural targets. Infrastructure like space stations and control of planets should take considerable time and resources to build or rebuild and be the sole source of all resources, both those used by factions to build ships and infrastructure and those available for trade. Planets and stations should not be spawned at random but placed based on a number criteria, randomness being only one of them. And in addition to wars and spawning, the player should see everything that is happening reflected in a more aggressive and insightful news service and the price changes of a simple dynamic economy.

Let's say the cephid 17 system produces deuterium fuel and titanium ore for the andolian faction. The aera come in and wipe the place out. Then an andolian shipyard a jump away will be operating at 50% production if there isn't a surplus of these resources from other neighboring systems. So the local andolian fleet has fewer replacements and they either come in from other parts of the empire, thinning the lines there and making them more vulnerable, or they let the aera dig in to hold on to and rebuild cephid 17 for themselves and/or potentially launch an offensive on the shipyard system sooner or later. Bounty missions and system wide open bounties for all area ships in the cephid 17 system are posted like crazy in all the neighboring andolian controlled systems, the news service should provide semi-predictive reports on what the waring faction AIs might do next in the contest for cephid 17. The price of weapons, medicals and essentials should skyrocket in and around the system and the price of luxuries should plummet as panicked masses try to sell everything they own in exchange for the basics of survival.

And what the player does in these hotspots can decide the victor. By supplying resources to one side in trade or by attacking the other for bounty or just the hell of it, the balance can be tipped in favor of a faction that might have been losing this battle.

Next to this a scripted campaign is nothing. This is dynamic, encompasses every aspect of game play VS already has and it plays out differently every time.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: 0.6 plans

Post by safemode »

scripted campaigns don't need to be linear or tell a story. they do however, need to continually engage the player. we could have it engage the player in response to whatever is unbalancing the game at that time. etc. the point is, the game while not needing a single story does need to direct the player. if you think otherwise then I don't know how you can explain the last decade of vs not leading to its becoming the most popular game. it has operated under the no direction method for it's life and it obviously doesn't work.

with the new setup of more compact and denser interaction in systems we can have many independent and dynamic missions and fixers hitting the player at all times. the player will be pulled not only by their own random choices but by factions individual campaigns... which should be tailored to their back story. it is not fully scripted so much as giving factions functionally dynamic but identifiable personalities and a set of actions they can use to act on them.

that would not require much content, just some decent Python scripting skills.

as for the big ship comment, the player shouldn't be controlling any ships large enough to require a crew to actually control realistically. it simply wouldn't make sense. it is outside the scope of the game since we can't simulate a bridge.... at all

edit: I'll try and clean up my cephid17 and push it today. I just want to cut back on the number of units launched into the system and tweak spec a bit more. should give everyone a general idea of the direction I think we should push the game. so much becomes simpler and falls into place doing it this way.
Ed Sweetman endorses this message.
Deus Siddis
Elite
Elite
Posts: 1363
Joined: Sat Aug 04, 2007 3:42 pm

Re: 0.6 plans

Post by Deus Siddis »

safemode wrote: we could have it engage the player in response to whatever is unbalancing the game at that time. etc. the point is, the game while not needing a single story does need to direct the player.
And I'm not against this. There should be a beaten path or several for players to follow (expecially new ones). You just shouldn't force players and development to stay only on that path. Completely eliminating any option to travel into system interiors under your own power would do that and it is unnecessarily extreme. All you need to keep the game focused is to limit SPEC from being an option on most ships, starting with the smaller and cheaper ones.
as for the big ship comment, the player shouldn't be controlling any ships large enough to require a crew to actually control realistically. it simply wouldn't make sense. it is outside the scope of the game since we can't simulate a bridge.... at all
That's completely arbitrary. Obviously any space craft is far too advanced a machine for one man to maintain. So the reasonable explanation is computer control, automation and dock side repair crews handle this stuff for you whether your ship is big or small.

What matters is the actual game play. Is this big ship slow enough to be believable and balanced but responsive enough for the player to fly it with the current control scheme? And my experience with the physics rebalance is that for ships in the range of 50-200 meters the answer is yes. I want these bigger and expensive but still flyable ships like the goddard, vigilance and mule to be fast-SPEC capable. They don't need to come equipped with SPEC standard but they are big, powerful and expensive enough that they should be able to have it.
Last edited by Deus Siddis on Wed Mar 20, 2013 6:13 pm, edited 1 time in total.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: 0.6 plans

Post by klauss »

safemode wrote:I would think that the lack of activity in vs, both in users and development would be indicative of how the way vs has been has failed to work. people don't enjoy wandering around and doing nothing. we need to stop kidding ourselves that what vs brings are these huge do what you want universes (systems). it isn't a feature in itself if nobody apparently enjoys it.
I happen to agree about the first part. But don't on the second. People enjoy seeing their actions spread ripples across the dynamic universe. If anything, VS fails at making it have a bigger impact. Economy for instance, people all over the place has asked a "dynamic" economy, where "dynamic" means probably in their minds, if I blow up station X, I can see the effect on the economy.

But I also do strongly believe that a game needs a story, the kind you're implying in the first part.

Lets not add features that add to the story but detract from the dynamism of the universe. Base-mode travel would be one such feature, if it was the only way to travel big distances.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: 0.6 plans

Post by safemode »

I'm not suggesting adding features. Im not taking away dynamic universe features. I'm fixing it so that it makes sense in game, makes sense developing it, and is fun for people to actually play.

first is to get rid of the player and NPCs needing to travel long distances. that is a necessary step.

second is refactoring the air scripts to play nice in new systems.

third is then to add more NPC interaction with the player and have each faction follow particular goals.

finally we can then balance things like economy and possibly make a new full campaign mode
Ed Sweetman endorses this message.
Primordial
Merchant
Merchant
Posts: 62
Joined: Tue Jun 21, 2011 10:33 pm

Re: 0.6 plans

Post by Primordial »

klauss wrote: Economy for instance, people all over the place has asked a "dynamic" economy, where "dynamic" means probably in their minds, if I blow up station X, I can see the effect on the economy.
Partially.

I guess ideally, for an example, Asteroid bases would produce X amount of Ore over time. Some of that ore would sold to a merchant, however much they could afford/store on their ship. They would take that ore to a refinery or something, who buy it, and turn into metal. The metal is sold to a shipyard who produce ships that take X amount of metal to make. The ships are sold based on number available/AI respawn. Replace ships with any other metal based commodity/etc.

The player can see an effect of this when, say, pirates fly into a system and start attacking merchants or industrial haulers, blowing them up. The metal cargo, left in space gets picked up by some of the pirates, or any other opportunistic salvagers in system, who then haul that cargo either to a commerce center, or to a base where they sell whatever they gain - in this case metal - which a base might then use to create ships/other things for the appropriate faction.

Pirates also might gain new ships attempting to blow up large haulers that carry ships to ship dealers, thus depriving the ship dealers of ships to sell, and the factions connected, of ships.

Naturally the player can act on any of this and affect what happens - potentially turning a profit at the same time.

If the ore mine is destroyed, ore must be found somewhere else.
If the refinery is destroyed, you have to find a new refinery to refine ore at.
If the commerce center is destroyed, all associated trading has to find a new place to trade at.
If the ship yard is destroyed, the ships have to be built at a new shipyard.
All buildings cost a certain amount of money and resources to produce and build.

This naturally could have all kinds of effects, depending on what's happening to the system and surrounding systems at the time. Planets cannot be destroyed and so I guess systems with the right types of planet would form natural hubs if the AI could figure out that this is a good place to build/trade/etc. Which could, again, lead to interesting siege/war situations. Suddenly those blockades in the news become a much more prevalent/involved thing.

And yes, this is very pipe-dreamy.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: 0.6 plans

Post by safemode »

here is a rough rough draft of the new setup. I need to really fine tune a lot here, but you can kinda get an idea of the direction with this patch applied to your py3 data dir. I just haven't had the time in the last couple days due to some home issues
You do not have the required permissions to view the files attached to this post.
Ed Sweetman endorses this message.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: 0.6 plans

Post by klauss »

safemode wrote:here is a rough rough draft of the new setup. I need to really fine tune a lot here, but you can kinda get an idea of the direction with this patch applied to your py3 data dir. I just haven't had the time in the last couple days due to some home issues
I've been profiling. And although the profiles don't seem to indicate it clearly, I believe the main bottleneck, at least in my system, is the radar, which shows easily a thousand dots or more. Sized. With antialias. I think that's not a very optimized path on most hardware.

I should try to limit the number of dots...

EDIT: Ok... not that. Still something's hinky, oprofile says the bottleneck is Unit::Draw. I don't think it's the GPU itself, because at 0 detail and with an empty screen (just background) it stays at 15fps... so it must be all the time it takes Draw to realize a unit is on-screen or not.

EDIT2: Woot... I found the problem. r13565 disabled -O3 !! I changed it so that Release and RelWithDebInfo have -O3 before CPU_OPTS, that should avoid the problem mentioned in the commit log.

EDIT3: Finally confirmed. Profile with -O3

Code: Select all

CPU: P4 / Xeon with 2 hyper-threads, speed 3059.02 MHz (estimated)
Counted GLOBAL_POWER_EVENTS events (time during which processor is not stopped) with a unit mask of 0x01 (mandatory) count 100000
samples  cum. samples  %        cum. %     symbol name
10       10            15.8730  15.8730    UnitUtil::getECM(Unit const*)
9        19            14.2857  30.1587    Unit::InRange(Unit const*, double&, bool, bool, bool) const
4        23             6.3492  36.5079    Radar::SphereDisplay::DrawTrack(Radar::Sensor const&, Radar::ViewArea const&, Radar::Track const&, bool)
4        27             6.3492  42.8571    Radar::Track::IdentifyType() const
4        31             6.3492  49.2063    TextPlane::Draw(std::string const&, int, bool, bool, bool)
4        35             6.3492  55.5556    UnitUtil::isCapitalShip(Unit const*)
2        37             3.1746  58.7302    Radar::SphereDisplay::Draw(Radar::Sensor const&, VSSprite*, VSSprite*)
2        39             3.1746  61.9048    Radar::Track::Track(Unit*, Unit const*)
2        41             3.1746  65.0794    Unit::GetComputerData()
2        43             3.1746  68.2540    VDU::DrawTarget(GameCockpit*, Unit*, Unit*)
2        45             3.1746  71.4286    void findObjectsFromPosition<UnitWithinRangeLocator<Radar::CollectRadarTracks> >(CollideMap*, Collidable*, UnitWithinRangeLocator<Radar::CollectRadarTracks>*, QVector, float, bool)
1        46             1.5873  73.0159    GFXCallList(int)
1        47             1.5873  74.6032    GFXDraw(POLYTYPE, float const*, int, int, int, int, int)
1        48             1.5873  76.1905    GameUnit<Unit>::getHudImage() const
1        49             1.5873  77.7778    MessageCenter::last(unsigned int, gameMessage&, std::vector<std::string, std::allocator<std::string> > const&, std::vector<std::string, std::allocator<std::string> > const&)
1        50             1.5873  79.3651    MountColor(Mount*)
1        51             1.5873  80.9524    Radar::CollectRadarTracks::acquire(Unit const*, float)
1        52             1.5873  82.5397    Radar::Sensor::FindTracksInRange() const
1        53             1.5873  84.1270    Radar::Sensor::GetColor(Radar::Track const&) const
1        54             1.5873  85.7143    Radar::Track::IsExploding() const
1        55             1.5873  87.3016    Radar::ViewArea::Scale(Vector const&) const
1        56             1.5873  88.8889    Unit::Computer::RADARLIM::UseFriendFoe() const
1        57             1.5873  90.4762    UnitUtil::getDistance(Unit const*, Unit const*)
1        58             1.5873  92.0635    VDU::Draw(GameCockpit*, Unit*, GFXColor const&)
1        59             1.5873  93.6508    VDU::DrawWeapon(Unit*)
1        60             1.5873  95.2381    VDU::staticable() const
1        61             1.5873  96.8254    charWidth(char, float)
1        62             1.5873  98.4127    getFont(bool, bool)
1        63             1.5873  100.000    std::vector<Radar::Track, std::allocator<Radar::Track> >::_M_insert_aux(__gnu_cxx::__normal_iterator<Radar::Track*, std::vector<Radar::Track, std::allocator<Radar::Track> > >, Radar::Track const
This is not counting what the nVidia driver is using up, which is like 80% of the CPU. But I suspect it's because of the radar. Should I disable it... m... I've got my work cut out for tomorrow.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: 0.6 plans

Post by safemode »

those flags shouldn't include -O options because they dont come before CPU_OPTS they actually come after and override the CPU_OPTS. I removed them because -O2 was the old option used there and it was making my -Ofast or -O3 options in my cpu_opts variable not work. build with the verbose make option turned on and verify your -O3 is coming before cpu_opts. I forget if it was both of those or one of those that i disabled because they were coming after cpu_opts on the build line, but if you reverted the commit, then you re-broke it. They _NEED_ to come before cpu_opts. I found it simpler to just add the -O option to the cpu_opts line. Though i probably only did that to vishera.

I would be very careful deciding if build flags are helping via profile. -O3 could simply be more aggressive at inlining functions, making the calling functions eat the time instead of the ones that are now inlined... but if your cpu_opt line wasn't setting -O options then you were probably running with no general optimizations before.

On my system with software rendering. If i am in the cockpit my game is running at half the framerate easily as when i'm in a view that is outside of the ship. The fastest views are the side views when nothing is on screen. The second slowest view is any view of the planet. the cockpit is the slowest i believe because of radar and text.
Ed Sweetman endorses this message.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: 0.6 plans

Post by klauss »

safemode wrote:those flags shouldn't include -O options because they dont come before CPU_OPTS they actually come after and override the CPU_OPTS. I removed them because -O2 was the old option used there and it was making my -Ofast or -O3 options in my cpu_opts variable not work. build with the verbose make option turned on and verify your -O3 is coming before cpu_opts. I forget if it was both of those or one of those that i disabled because they were coming after cpu_opts on the build line, but if you reverted the commit, then you re-broke it. They _NEED_ to come before cpu_opts. I found it simpler to just add the -O option to the cpu_opts line. Though i probably only did that to vishera.
No, I didn't revert the commit, I just added the -O3 where it was missing, before CPU_OPTS, so CPU_OPTS has a chance of overriding it, and nothing has a chance to override CPU_OPTS.

I noticed because I did try the verbose make, to try and generate assembly listings, and checking the listing I noticed there was no inlining, and checking the command line indeed there was no -O option.
safemode wrote:I would be very careful deciding if build flags are helping via profile. -O3 could simply be more aggressive at inlining functions, making the calling functions eat the time instead of the ones that are now inlined... but if your cpu_opt line wasn't setting -O options then you were probably running with no general optimizations before.

On my system with software rendering. If i am in the cockpit my game is running at half the framerate easily as when i'm in a view that is outside of the ship. The fastest views are the side views when nothing is on screen. The second slowest view is any view of the planet. the cockpit is the slowest i believe because of radar and text.
Are you using the profile build type? Because that one worked well. It was the Release ones that didn't. Anyway, I'll try -O2 and -Ofast and some other -O variantes to see if they make more sense.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: 0.6 plans

Post by safemode »

I would keep O options in all the CPU opts rather than base flags. O has different behaviors in newer gccs. and OFast is only 4.7

the reason for keeping it in CPU opts is that in newer gccs O3 turns on auto vectorization. and editing cpuopts is cleaner than playing with a variable shared by all
Ed Sweetman endorses this message.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: 0.6 plans

Post by klauss »

safemode wrote:I would keep O options in all the CPU opts rather than base flags. O has different behaviors in newer gccs. and OFast is only 4.7

the reason for keeping it in CPU opts is that in newer gccs O3 turns on auto vectorization. and editing cpuopts is cleaner than playing with a variable shared by all
Yes, but no. Because CPU_OPTS does not respond to debug mode, and debugging with -O3 is really painful.

I think it's fine where it is, maybe if you want it editable, add another variable RELEASE_OPTS that gets attached to release opts?
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: 0.6 plans

Post by safemode »

possibly a whole other flag that just sets that option. then debug can simply disable using that variable when building the GCC command. that way we don't have to care about the order of everything. the main reason this particular option is a special issue is because it is dependent on not just GCC version but CPU opts too. I should be able to say, build without debug, with CPU opts but with O2 or O3 or OFast etc and not worry about some other option overriding it

Since, -O3 on gcc 4.7 activates auto-vectorization but -O3 on earlier versions dont, thus the behavior of -O3 is vastly different cpu_opts to cpu_opts and computer to computer, it shouldn't be a standard and thus no -O option should be some standard option.

These need to be at the end of the CFLAGS variable since we dont want any packed optimizations to enable any of these options we are disabling.
Release should simply be the lack of debugging flags.
Profile should add debugging flags + profiling flags + disable inlining
debug should add debugging flags and disable inlining

The next to end CFLAGS would then be CPU_OPTS. Obviously these should be cpu specific optimizations and we will probably want some variations depending on gcc version down the road.

The front of the CFLAGS would be the packed Optimization variable. This is the -O# flags ...or -Ofast. or -Os. This has to come first so that disabled optimizations remain disabled. It also needs some gcc version detection.

I think that is the cleanest way to do it.
Ed Sweetman endorses this message.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: 0.6 plans

Post by safemode »

holy hell. i find it amazing that anyone has ever been able to use vegastrike as an engine for mods ....trying to follow the python modules is enough to make you want to delete it all and start over. So much dead code mixed with unorganized functions .... I almost want to cry thinking about what it would take to clean up /data to make it easy to follow.

It doesn't make sense to me why the python is written the way it is.
static functions rather than objective methods, module names that dont follow the intended purposes (cuz there is usually more than one) of the functions inside. Function calls that return values that dont make any sense for the function call... Lots of recursion and and local function names that match VS. function names but do way more than just wrap calls.

meh. data land has gone far too long without as much eyes on the code as the engine has had.
Ed Sweetman endorses this message.
Deus Siddis
Elite
Elite
Posts: 1363
Joined: Sat Aug 04, 2007 3:42 pm

Re: 0.6 plans

Post by Deus Siddis »

safemode wrote: holy hell. i find it amazing that anyone has ever been able to use vegastrike as an engine for mods ....trying to follow the python modules is enough to make you want to delete it all and start over. So much dead code mixed with unorganized functions ....
Someone finally knows my pain. :cry:
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: 0.6 plans

Post by klauss »

You know, back to the consolidated system, I think everything's too close now. I'd space things a part twice or perhaps even more. Things should be in view, but far.

Right now, it's really difficult to navigate around the hub, because everything interferes with SPEC. If you'd space things twice as much, it wouldn't be a problem I think, and traffic density would decrease as well, making it overall better.

So, even though it's important to make VS performant enough to handle this configuration, I think it has to be spaced a bit more. If you want, you can speed up SPEC, but I think it's not necessary for a 2x or 3x spacing increase.

What I do like is the distance to Atlantis. It's really beautiful having it on sight like that. I haven't seen the dark side yet, though. I wonder if orbits are working on cephid... (some of my launches should have been on night side due to orbits shifting, but weren't)
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
Deus Siddis
Elite
Elite
Posts: 1363
Joined: Sat Aug 04, 2007 3:42 pm

Re: 0.6 plans

Post by Deus Siddis »

klauss wrote:I wonder if orbits are working on cephid... (some of my launches should have been on night side due to orbits shifting, but weren't)
Was time compression completely removed from the engine? Because it could certainly help answer your question.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: 0.6 plans

Post by klauss »

Deus Siddis wrote:
klauss wrote:I wonder if orbits are working on cephid... (some of my launches should have been on night side due to orbits shifting, but weren't)
Was time compression completely removed from the engine? Because it could certainly help answer your question.
No, I think I could bind a key to it and use it. But I wonder how long I'll have to wait even with time acceleration...
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: 0.6 plans

Post by safemode »

klauss wrote:You know, back to the consolidated system, I think everything's too close now. I'd space things a part twice or perhaps even more. Things should be in view, but far.

Right now, it's really difficult to navigate around the hub, because everything interferes with SPEC. If you'd space things twice as much, it wouldn't be a problem I think, and traffic density would decrease as well, making it overall better.
I need to remove interdiction. There is no need for all the large radiuses for gravity interference with spec maxed at around 2000kps. As is, it's not very functional, but without all those workarounds that were put in place for SPEC being > c, it'll be fine.

We dont want things far ...we want them very close. We dont want to simulate reality when that reality is going to be pointless and boring.

We can move things further away when we implement things to do or happen along the way. We need to stop this designing of the game with hopes and dreams of features to be implemented in the future but never do. If we dont have anything worthwhile for the player to do while going from A to B and the player likely needs or will have to go from A to B then you have to reduce the distance from A to B because the old method of just letting the player go faster or dilating time is stupid STUPID STUPID. It's a crutch that solves nothing and introduces more problems.
So, even though it's important to make VS performant enough to handle this configuration, I think it has to be spaced a bit more. If you want, you can speed up SPEC, but I think it's not necessary for a 2x or 3x spacing increase.
What ought to be done is reducing the size of wormhole meshes ...They're gigantic. ..way too big. It wouldn't look so crowded if they were handled differently. I dont like the idea of the mesh anyway. If it's a virtual rendering in-cockpit, then make it look like one from the targetting computer ... ie.. just a special square when targetted ... Lets get rid of these ugly green things that dont make any sense.
What I do like is the distance to Atlantis. It's really beautiful having it on sight like that. I haven't seen the dark side yet, though. I wonder if orbits are working on cephid... (some of my launches should have been on night side due to orbits shifting, but weren't)
Orbits should work. everything just moves _VERY_ slow ... Basically the idea here guys is to design the game to play as best as it can now, and as features and such are added, we modify the game to handle them, rather than setting it up as if all these yet-to-be-implemented features exist and work like they're meant to. So with the features VS has now, tight systems where ship to ship dogfighting is quite likely and base to base travel is minimal is best. That's pretty much all there is to do in the game right now. And by making them tight vs making travel faster we solve so many issues and simplify so many processes. What is seen in the patch above is severely incomplete because SPEC still has it's claws all over the place and those claws assume > c movement. They need to be modified. Gravity interdiction can easily be toned back to unit radius's * 1.5 and the player should be able to stop and react with more than enough time until collision (and the game will not miss units either)...
Ed Sweetman endorses this message.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: 0.6 plans

Post by klauss »

I'm not talking about realism or anything like that, I mean, it looks crowded, and it's not just the jump meshes. Try increasing distances, I've noticed replacing 10071 -> 10101 and 10040 -> 10020, 566 -> 588 and a few similar mods like those, result in a much better layout.

Try it out.

Also, to make it work with regular orbits, I think the hierarchy should be changed a bit. You should pick a wormhole as the "center", and make all other units gravitate around the wormhole. That way, the parent wormhole can orbit around, and the layout won't get destroyed. Currently, if orbits were working as intended, the hub would be un-done by rotational differences.

I'll try to get you a patch with those changes.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: 0.6 plans

Post by klauss »

I'll be starting the upgrade in 1h or so...
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: 0.6 plans

Post by safemode »

hope the web interface is usable. current one is so bad it might as well not exist. was so close to bitbucketting and just moving to git .
Ed Sweetman endorses this message.
log0

Re: 0.6 plans

Post by log0 »

To be able to compile py3 branch with MSVC one will have to add __restrict__=__restrict to preprocessor definitions and disable warning 4227(to avoid a shitstorm of warnings). I am not against optimizations, but has anyone profiled this change(just curious)?
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: 0.6 plans

Post by safemode »

you can see pages about GCC 4.7 and the differences in assembly output. adding the define to config.h should be all you need to do to make both keywords work.
Ed Sweetman endorses this message.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: 0.6 plans

Post by safemode »

well, I finally got my broke self a new graphics card. radeon 7770. Klaus and I are addressing some performance issues before moving forward with system consolidation. basically I've noticed the game not making full use of the CPU despite having plenty to do that isn't being held up in gl. the point being that I'm seriously thinking of making ogre an immediate priority of mine... the specifics likely meaning we would maintain our own copy of ogre and modify it to handle the extra precision we need. I haven't got into it yet but it looks like that would be the smartest direction to take


also, I'm looking into the latest bullet physics library. it supports open cl colliding. as well as soft body colliding among other things.
Ed Sweetman endorses this message.
Post Reply