Tasklist?

charlieg · Post by **charlieg** » Sat Jul 16, 2005 7:48 am

Is there a task list anywhere for WCU?

Personally I wouldn't mind doing a few 'janitor' tasks [i.e. finicky little things others never get around to do like e.g. putting specific info in the Wiki] if there's anything going.

Perhaps maintaining an official task list would help organise development?

spiritplumber · Post by **spiritplumber** » Sat Jul 16, 2005 11:58 am

Indeed it would!!!

Right now since I'm done with the ships and am learning the VS code so I can do some tweaks (you might like the new tractor beam

) the main "boring" task that is required is to go through units.csv and see if I missed anything in there -- mostly the bases could use a look, how their satellites and turrets are placed etc.

I will upload as soon as I get my damn server to figure out that i'm NOT over quota.

crouton · Post by **crouton** » Sat Jul 16, 2005 1:14 pm

A master tasklist would be great. So far (I'm gathering from different sources) this is what's on the table:

* Units.csv (as spirit mentioned)

* Existing system files (making sure the existing ones have correct jumpnodes and are populated correctly) as well as creating new system files (thehawk has done a great job with this so far.)

* Determining which ships are in the game and are acting/looking correct versus ships not in the game or are incorrect (textured, etc). The new shippack-4.0 is on SourceForge, but I'm not 100% certain that WCU contains everything in that pack.

* Moving ships to the OBJ format (mkruer states this is the preferred format for the next shippack release)

done by spirit in last release* Commerce modeling (1st page of the TODO thingum thread)

* Updating the existing base backgrounds. They are pretty low res and could use a refresh.

* Kilrathi bases. If we are going to land on Kilrathi bases (is it possible for the player to be a Kilrathi to begin with?) backgrounds and such would be useful.

* Update the FAQs. This might take some consensus, but since we're ignoring Priv2 altogether (hard to integrate) and are looking hard at keeping WCP ships/capships as rare as possible, we should update the website to reflect that. Rather than being a playground for every known Wing Commander ship, we're creating a game in the Wing Commander universe with a defined timeframe.

crouton* Redo the manual. Right now it's still Privateer Remake, right? Maybe make it HTML rather than PDF, so it can be viewed in-game?

* Splash screen and intro. Both are tied to PR, and should be cut or replaced.

* Update the website. Now that work on WCU seems to be gaining speed, we can split the website into PR and WCU sections.

Done! * Finish the sound editing. This has been chuck and klauss' gig, not sure if they need help or more hours in the day.

* Get the DB up and running (sort of). Moving away from XML is a longterm project, though.

* Get the CVS on Sourceforge fully up to date. We'll need to clean up some directories, merge Priv1.1 back in and use spirit's WCU update to make it play nice, etc. This is pretty important to keep up-to-date and correct.

[edit] More things to do!

chuck_starchaster* Background screens for trading and such.

* Update cargo items?

* Flesh out faction-oriented 'things' (just in a general sense, we'll need to work up a consensus on specifics)

[edit2]

mostly done for Priv bases in last release, needs doing for new base types* Tweak 'export model' - what is produced by each base should be reasonable (no ore from pleasure bases, etc)

[edit3]

* Support for pixel assignments of images

* Support for nonstandard-size images

* Compact and unify Python scripts (e.g. cockpits)

That's about all I can come up with at 8am, but I'm sure there's more. Plotlines are a big one but they can be sidelined for now.

Post by **chuck_starchaser** » Sat Jul 16, 2005 7:38 pm

Sounds are done, for now.

Add to that, upgrading backgrounds for the trading and ship upgrade screens. I'll try to tackle it.

So, the problems with jumps around Sol and some other systems down and to the right are fixed now?

What about space stations? Do we have distinquishing space-stations for the various factions? Are the various faction-dominated areas of space going to feel different? That is, if you go to the border worlds, is one going to "feel" one is like in a different country, with different ships, different stations and different dialogs, news items, and mission types?

crouton · Post by **crouton** » Sun Jul 17, 2005 11:25 pm

I've put names in front of tasks. chuck_starchaser has taken the trading/upgrade backgrounds, and I've grabbed the manaul update.

If you would like to work on something, reply here and I'll update the list. if you have another task to add to the list, post it here and I'll update the list.

spiritplumber · Post by **spiritplumber** » Mon Jul 18, 2005 12:04 am

We have preliminary support for subfactions, (use faction_shps.get_parentfaction(fac) in phyton) and the trading model has more or less been done -- you get cargo missions that (1) pertain to the ship you own, i.e. courier missions for fighters/bombers and bulk cargo (200s of units) if you own a bigtransport, and (2) usually pertain to the unit you are docked with, so if you land on a mining base, your cargo missions will mostly involve iron and tungsten etc.

What needs to be done is, the new bases need an export model -- I did the best I could to make it modular (look at the "buysell" entries in units.csv) but someone needs to tweak it. For example refineries should not produce computers etc.

A note on the ship upgrading (specifically the software screen): I want only maps in there, so replace piccies of radars with piccies of maps. Reason being, we buy radars in the upgrade screen, and since WCU is a lot bigger , we will need the extra slots.

Look in weapons_lib.py to see how I implemented mapping by sector without having to punch in each system by hand

just use that for the other sectors.

Post by **chuck_starchaser** » Mon Jul 18, 2005 9:51 am

Okay, here's a basecomputer.png. Just download it into you textures folder, start the game, go to commodities, and click on the little screen. I think the translucent panels could be a bit darker, and there need to be variants for news, info, etc.; but the code needs to change to call in the variants; --right now it uses one background for everything. If the general idea is liked, I'll go ahead and improve this one and make the variants.

spiritplumber · Post by **spiritplumber** » Mon Jul 18, 2005 12:40 pm

Very cool -- perfect! I'm looking into the variants today. Can you make two more, one for the mission computer (use the old Priv mission comp, there should be screenies around) and one for the upgrade/repair place?

Post by **chuck_starchaser** » Mon Jul 18, 2005 1:04 pm

It's almost working time; I'll get back to it after 5pm. I can do the upgrades screen tonight, for sure. I don't have the original's mission computer screen, though. If you have it, could you email it to me? Actually, if you have the original's PDA, would be nice for the save screen...
I hope you realize you'll need to change code and recompile. The code calls for the same file for all the screens, right now. And there's no xml file calling for "basecomputer.png". The call comes from the executable. And I no longer have the cvs 'cuz I screwed up my Linux install ^^.

Post by **chuck_starchaser** » Mon Jul 18, 2005 2:34 pm

Okay, here's another basecomputer.png. This one works for the upgrades...

crouton · Post by **crouton** » Mon Jul 18, 2005 2:44 pm

Very nice, chuck.

Post by **chuck_starchaser** » Mon Jul 18, 2005 3:54 pm

Thanks. So, besides the Commodities and Upgrades screens, there's also:

Ships screen (I can use the dealer screen as background.)
Info screen (Maybe the old PDA could work as background, but I don't have it)
News screen (Maybe the original computer terminal, but I don't have it)
Missions screen (same as above)
Save screen (same as Info screen)
Save Confirm screen (same as Info screen)

Currently, the executable calls "basecomputer.png" for all these, so to separate them will require a small engine mod and recompiling.

spiritplumber · Post by **spiritplumber** » Tue Jul 19, 2005 4:39 am

Done! Get the little update.

What needs to be done the most right now is docking ports for capships and especially bases (I did the capships, mostly, but not the bases), and cockpits.

What else...

Fluff text in phyton scripts: English is not my first language, so can please someone look into it? I would like more randomly-recombinable options for news texts etc. so as to avoid repetition.

Base art: PLEASE PLEASE PLEASE! I can barely draw stick figures so....

Kilrathi civilian ships: We need at least four (since there are four main Priv ships). Use your imagination as the canon is silent about it

crouton · Post by **crouton** » Tue Jul 19, 2005 5:05 am

I am currently trying to figure out how to get 1024x1024 .PNG files to display correctly for base backgrounds. I've started a thread over in Artwork to discover how to get it to work properly; I'm beginning to fear that the engine is limiting the resolution for some reason.

Which python scripts would you like reviewed?

Post by **mkruer** » Tue Jul 19, 2005 7:56 am

Core improvements required for the first beta of WCU

Since we are taking the time to come up with the task list there are a few improvements that I would like to be made before the first beta of WCU is released to the public.

Most of the improvements that I'd like to be made or all behind the scenes programming tweaks, mainly for the ease of development. The first tweak that I would like to see made is added support for pixel coordinates of all images. To some of briefly what pixel coordinates does; currently when creating an interface that interface is broken down into four quadrants with 1,-1 at the top some left corner and -1,1 at the bottom most corner 0,0 being the center. Everything must fit with inside these coordinates in order to be displayed on screen the problem arises when it comes to easy manipulation of the applied images, we as developers must take the standard screen dimensions of 1024 by 768 divide that by half and then assign fractions to the location to come up with the proper location. In the end not difficult to do but amazingly annoying after a while, and something that could be done on the fly.

The second and development would like to see have been use the support for nonstandard sized images directly with inside the engine. Currently all images have to meet the divisible by two requirement. (2x2 4x4 8x8 16x16 etcâ€¦ or any combination divisible by 2) is seen there are few in the resolutions that can fit into this category. The closest screen resolution perhaps is 1024x768 and even then this is a nonstandard size image. The trick is to take a bunch of nonstandard size images and rearrange them like a puzzle to fit with inside the video card memory which has to be in increments also divisible by two. The benefit of this is first use of nonstandard size images but more importantly better space allocation of video memory due to nonstandard size images. Again the something trivial that other engines do on-the-fly and should also be done within Vega strike. A

The following excerpt is from conversation I have with Dan regarding the inclusion of pixel coordinates and support for nonstandard image sizes.

Myself
by the way I was wondering if / when you were going to add support for using pixels coordinates and support for non square image?

HellcatV
when video cards support compression on rectangle format textures
which is apparently GL 2.0
I removed the checks for it now---it's up to the driver to wig out
which they have to before GL 2.0
and apparently the new GL2.0 drivers aren't supposed to

Myself
Do you know what I meant? Right now some texture is have been stretched to fill the entire 512 x 512 region of the bitmap. However there is a better way of doing it. Someone once told me that there is a way to take multiple images and rearrange them so all parts fit with inside the standard OpenGL format sizing. It's like taking a bunch of nonstandard images and making one standard size image that has multiple parts. Hope you understand that

Unfortunately I do not share Dan's positive outlook on the future. I brought this up 3yrs ago and still nothing has happened. And the video drivers still do not support it. The code is out there, it exists, it just needs to be implement.

Another improvement that I would like to see made is for the reduction of small script files that seem to litter all the directories. As outlined above when the biggest offenders is cockpits. For each image inside the cockpit it requires its own small script file this seems a little absurd. Since we are moving away from XML to Python but I would like to see happen is changing the current cockpit XML script into a Python script and adding all the other small script files that tell the image how large it should be to be directly included inside the Python's script for that cockpit. You should eliminate everything from the cockpit directory save images and one Python script file.

crouton: since you are the keep of the task list. summerize what i said and add it to the task list.

spiritplumber · Post by **spiritplumber** » Tue Jul 19, 2005 8:07 am

whoa, WAY out of my league... I'm doing little things to vs.exe mainly for the purpose of teaching myself how to do it, I don't expect any of it to survive the next sync. I hope a REAL programmer picks this up!

crouton · Post by **crouton** » Tue Jul 19, 2005 1:15 pm

3 points added to the list. I'll make a webpage version of it tonight and point to that instead.

Your comment on pixel assignments - are you attempting to change the position coordinates for images? i.e. Will upper left corner be 0,0 and the image will be displayed accordingly? I ask because it seems natural to replace the original low-res art with higher-res reworks, and other than the ships it seems very difficult to do so.

spiritplumber · Post by **spiritplumber** » Tue Jul 19, 2005 2:10 pm

Bit of a hairy issue -- screen bounds are represented with -1....+1 with zero being the center (-1 -1 is top left I think). This causes all sort of coordinate conversion unpleasantness.

spiritplumber · Post by **spiritplumber** » Tue Jul 19, 2005 2:29 pm

fixed *transport shuttle in escort missions didn't show
fixed *assault shuttle can't tractor stuff in
*troops sometimes still end up going stupid straight
*HUDs show up upside down
*vegastrike initial message still mentions SPEC
fixed mostly*AI scripts come too close before turning back (CODE: Make sure meterdistance checks for radii!)
fixed *Remora needs either token shields or a different AI because all it does is evade
*Big turrets sometimes are untextured
*Caernaven sometimes is all dark
*Vindicator texture still being a bitch
*Ranger and Durango need hangar holes
fixed *Put flak gun on non player owned draymen, corvette etc. (add a flak turret for this?)
fixed *ejected pilots display the same newtonian nastiness as cargo used to, give them ai and nerf it for rescue missions
*invent way to uniquely identify capunits and make them eject a shuttle rather than a man OR add an eject shuttle to buysell_capship
fixed *make cargo tougher so it will survive parent unit explosion
no *cause turrets to draw from parent unit's energy pool?

Post by **klauss** » Tue Jul 26, 2005 8:06 pm

I was thinking about adding non power-of-2 size support for sprites only, where it would be "simple" and useful, but not the way you say.

Non power-of-2 (rectangle) textures are not compressed, so basically you loose memory efficiency instead of gaining it. Also, there's a lot of hardware (I know from personal experience) that reports support for rectangle textures but actually supports it in software emulation, which sucks. So, we have no way of knowing if it will run smooth or like 0.5FPS, so I wouldn't use rectangle textures (damn those dicks that made drivers with phoney support, they ruined it for all of us).

But, what I can do, is make all non power-of-2 images load into power-of-2 texture objects, and adjust texture coordinates (that's easy on sprites, but not on meshes, see?)

But, support for it relays on some other features that I'm working on with sprites and animations, that presently broke my code tree. So I wouldn't expect it soon.

Also, I fixed the tractor beam a while ago, but couldn't commit due to lack of time. I'll be comitting those changes in the next few days, so... spirit: what does your fix consist of? Because I have my own fix, and it's time to decide which one stays...

FYI, mine has a set of flags for "tractorability" (a little expansion on chuck's fix): Push, and Tractor-in are the two defined ones, but it's easy to add flags. The idea is that you can specify, unit-wise, whether it can be pushed with the tractor/repulsor beam, and whether it can be tractored into the cargo hold (by the tractor beam). It's very useful, but I haven't tested it much. All I tested is that it doesn't break the game, and it doesn't.

I'll be comitting lots of fixes along with that one, but I'll make a list when I commit (not sooner, since I don't remember them all). It'll take some time to filter out the sprite/animation stuff, which is slightly broken for now. (only problem is with a missing cursor in base interface, but that's just the simptom of a bigger problem, I feel).

charlieg · Post by **charlieg** » Wed Jul 27, 2005 12:15 am

I had started one here over when we frequented the crius.net forums:
http://vegastrike.sourceforge.net/wiki/MOD:WCU:Status

Perhaps the layout is a bit unecessary (in that it makes modifying the task list a little cumbersome) and it can be simplified into a simple bullet list of tasks with a word in bold at the front (e.g. FIXED or URGENT or LOW PRIORITY) describing the status of the task.

charlieg · Post by **charlieg** » Wed Jul 27, 2005 12:16 am

mkruer wrote:crouton: since you are the keep of the task list. summerize what i said and add it to the task list.

I think he kinda got scared off for one reason or another.

spiritplumber · Post by **spiritplumber** » Wed Jul 27, 2005 7:58 am

so do i

i tried to get a hold of him but no luck.

crouton · Post by **crouton** » Wed Jul 27, 2005 6:33 pm

As I stated in a different thread, you guys want a secretary not a manager. I don't see the need to stick around and act as a note-taker, especially since this is a pet project for the majority of the developers. Best of luck to you guys, but there's a reason why other, newer projects have more mindshare.

Post by **chuck_starchaser** » Wed Jul 27, 2005 8:35 pm

I don't know if you're insinuating something about me, and I don't like going back over old stuff, but I had told you 2 or 3 times we needed a few more days for the sounds, and then you basically threatened to release without the sounds, on the basis of some imaginary rush, and for no reason whatsoever I could see. Now the sounds have been there sitting in a zip for weeks.
So, putting together a release is "taking notes"? You want people to fear you?
Anyways, do what you will. I've got one manager already, in "real life", and that's enough for me. Good luck to you, sir.

Vega Strike Forums

Tasklist?

Tasklist?

my personal little bug list.