Re: [Vegastrike-devel] Upgrading complete: Reliant: Feature request

[Sabarok A. <sa...@st...>]

Original message from: Daniel Horn <dan...@mi...>
>
>I have finished upgrades.....
>what this means is that now that you're docked you can go to the
commodity 
>exchange (by pressing SHIFT-C  )..... it's basically a hack...in the
future I 
>hope ot have some interface to do that....
>
>anyhow once you're there, you can do a number of things 
>you can upgrade, add, buy or remove.....
>
>RELIANT: upgrading ships is exactly like selecting missions...you
enter a 
>name of a shipfile in a directory and then it buys that ship..... in
this one 
>the directory path is eliminated, but it's the same idea as your
mission 
>selector...I was wondering if you couldn't just tack that on to
vegastrike 
>instead of the lengthy and STUPID functioN I wrote .
>mine is called "Unit::UpgradeInterface (Unit * base) {}
>it's on line 389 of unit_customize.cpp

I'll take a look when I have some time, but it should be really easy
to tack onto Vega Strike. I've designed it that way.

>basically instead of asking all these questions, the glut window
should be 
>displayed ont eh screen and users shoudl be able to select a file
(hence no 
>LOAD_FAILED messages, sinec you will select correct stuff with the
mouse)
>we'll eventually need credits in there and mechanisms for purchases
to 
>fail...but right now to have a simple interface in GLUT would be
extremely 
>nice....because windows users cannot use the entire feature
documented below 
>since they do not have a console in vegastrike--so they do not have a
place 
>to type.....
>
>anyhow I'd appreciate if you could convert your stuff....I think
we'll need 
>to somehow change the glutMouseMotionFunc and stuff back to what they
>were...but that should be like 2 lines of code at the end of the
function

Not much needs converting. The glutMouseMotionFunc and all the other
mouse routines are all controlled outside the Text Area class (means
in the function where you get the mouse, you just hand off to a
function, then get the return).

Here's how it would work in Vega Strike's source:

TextArea *MyArea;
MyArea = new TextArea(x,y,wid,height,with_scrollbar);
MyArea->AddTextItem("./data/unit/file", "Displayable text");

int GotClick = MyArea->MouseClick(button,state,x,y);
if (GotClick)
    char *NameOfChoice = MyArea->GetSelectedItemName();
MyArea->Refresh();

That's just about all there is to it (there's functions for MouseMove
and MouseMoveClick, both are needed. One for highlighting, the other
for the scrollbar).

All x,y,width,height values must be in glut float notation (-1,-1 is
bottom left, 1,1 is top right. the boxes are drawn from the top left
corner, so the x,y would be for the top left corner. -1,1,2,2 would be
a full screen box).

Daniel, the class I sent you the other night can handle this, but I've
fixed the last known bugs. Only part mission is a multi-line text
display (for briefings and description).

Anyway, I'm really excited that it's almost ready. I really want to
see this compiled for windows so I can try it on my 3D accelerated
machine :) (goes a little slow in software mode at first while things
load).

There might be some small memory leaks. It shares the menu textures
between every instance. It loads the textures once, and repeats. It
doesn't unload them (only really an issue if you need the menu only
once at the beginning).

I'd like to keep the TextArea class portable (meaning between
projects, not just platforms), so try and keep changes to that class
specific to the class. It'll make things easier when we need to reuse
it for something else in Vega Strike.

Reliant
uss...@us...

>for now I'm happy with just pausing the game until the interfacing is
>done...in the future we might want to have the game run in teh 
>background...but that's a completely different story :-)
>
>anyhow what do you think? could you do this?
>
>anyhow on with the documentation about how to upgrade your ships
(this will 
>give players a reason to do the trading and the missions...tehy will
get 
>money they can use to get better ships)
>I'm almost done with this whole feature...I need a few more lines of
code to 
>load the serialized starship from the hard disk when the player
starts a 
>mission and then finally a few lines of code to check how much the
current 
>station is selling these things for and some lines to make sure you
have 
>enough credits.....
>also cargo will fit in this schmea nicely when we have it.... cargo
will 
>prolly be a vector <std::string> or something :-)
>
>ok let me continue
>
>the names "add upgrade remove   and     buy"  are confusing because
I'm 
>really tired...let me explain
>
>add means  "add this on to your current stuff"  basically if you have
5 armor 
>and add a unit with 10 armor...you end up with 15 armor
>upgrade means "replace this onto your current ship if it is better"
>hence if you have 5 armor and buy an upgrade that has 10 then you end
up with 
>10.  This one calculates that you should get refunded 50% (since you
started 
>with half....) (later we must minus used price ;-) )
>
>if you're dealing with turrets or guns, add and upgrade are
equivalent
>
>buy means to actually purchase a new ship.....   so you can type in
>buy
>then  f109vampire
>and voilla your ship changes :-)
>
>
>finally there's remove
>
>basically you sell what you've bought... you can remove any
upgrade......
>
>ok so I've told you what you can do...let me explain to you what an
upgrade 
>is....
>upgrade is a new faction...this faction does not fight.... it has no
meshes 
>on its units..... the upgrade faction has 1 purpose: provide the
player with 
>"stuff" he can buy or sell.
>I have already committed a unit named "blank"  this is the
baseline...it has 
>the worst of everything.  If you buy this unit you will spend nothing
and you 
>will get nothing.   When designing an upgrade you should start with
the blank 
>unit (or you might give some default values to the unit...which is
bad)
>
>I also included a couple of upgrade units....
>shield_4 will ugprade any ship that has 4 shield facings (most aera
ships) to 
>the values listed (or will add those)
>laser will upgrade a weapon to a laser  ion will upgrade a weapon to
ion
>
>small_turret will upgrade a turret to a smallturret  (or if you
remove it, it 
>will remove that turret)
>
>it's quite nice :-)
>
>I also added the feature of a template...... this implies two
things....
>a) from now on if a unit has a dot in its name  (myunit.xunit) it
will be 
>stored in a directory
>myunit/
>b) templates are named  myunitfilename.template
>
>so osprey has been checked in as osprey.template
>
>What a template is means the following:
>a)when you are buying a weapon, and your upgrade adds or subtracts
mass.... 
>then the mass cannot be BELOW the template mass
>b) when you are upgrading armor or shields or number values, they may
not 
>exceed the template's values. these are hard, maximal values for each
>ship.... to maintain some balance in the game....
>of course more expensive ships will have better templates....but
templates do 
>not have <MESH> tags so they do not have geometry...they are merely 
>descriptions of a unit
>
>
>so ya I do this all with unit serialization and the whole upgrade
idea from 
>the enhancements.... I really had to change a lot to make this work
in 
>general, but I like the code I have spit out.....except of course my
sutpid 
>interface
>
>-- 
>- Daniel Horn (hel...@ho...)
>Vegastrike Lead Developer ( http://vegastrike.sourceforge.net )
>
>_______________________________________________
>Vegastrike-devel mailing list
>Veg...@li...
>https://lists.sourceforge.net/lists/listinfo/vegastrike-devel
>.
>


__________________________________________________________________
Get your free Australian email account at http://www.start.com.au