Jump to content
XCOMUFO & Xenocide

Xna Progress Release 0.2


dteviot

Recommended Posts

So, I'm asking for people to post their feed back, which behavior do they prefer?

Actually, while we're about it, is anyone willing to write up the requirements for what sound needs to do?

I don't know, I kind of prefer the current track to stop playing as soon as you exit the screen (it's how the original game handled music). I wouldn't want to hear a long interception track running in the battlescape. That would destroy the atmosphere. :D

 

- Zombie

Edited by Zombie
Link to comment
Share on other sites

  • Replies 239
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

I would prefer having it change immediately (maybe a crossfade is possible?). Our songs are too long to play them until the end, in my opinion this might destroy the mood the game (read: we) want(s) to set on the specific screen.
Link to comment
Share on other sites

I would prefer having it change immediately (maybe a crossfade is possible?). Our songs are too long to play them until the end, in my opinion this might destroy the mood the game (read: we) want(s) to set on the specific screen.

OK, it's a sample size of 4 (including Darkhomb) probably not sufficient by Zombie's standards, but it will do for me. Change immediately it is.

And yes, a cross fade is almost certainly possible, but it would probably take me a while to figure out how to do it correctly and implement. Another task for a recruit.

Link to comment
Share on other sites

You don't really need to crossfade if it is too difficult. (I assume crossfading is fading out one track while fading in another). You could fade out the one track for something like 2-3 seconds, then just start playing the second track immediately. That might be easier and it wouldn't partially mute the start of a track. Besides, most tracks usually have some blank space at the beginning so it wouldn't make much sense to fade in to, well, nothing. :wink1:

 

- Zombie

Edited by Zombie
Link to comment
Share on other sites

  • Merged in Darkhomb's patch to add a sound options dialog
  • Change of screen now changes sound immediately.

Notes:

  • Unfortunately, the patch Darkhomb posted does not include the SoundOptionsDialog file. However, I have merged in the updated OptionsDialog.cs Frame.cs and strings.resx, in anticipation of SoundOptionsDialog turning up.
  • To add a new file to SVN (so it's included in a patch, you go to the file in Explorer, right click on file, select "TortoiseSVN" on the first drop down menu the "Add" on the second.
  • Darkhomb, you will need to uncomment the line ScreenManager.ShowDialog(new SoundOptionsDialog()) in OptionsDialog
  • I've also been thinking a bit more about the "Earth scene in the Geoscape screen turning blue. My original theory was we were loosing the graphics device and not recovering it correctly. However Taz0k reported the problem happening when he tried spinning the globe. Which is when it happened to me.
    So, my current thought is the problem might be there's some error in the globe spinning calcs that put the camera in a weird position (possibly a divide by zero that results in an invalid matrix, preventing anything from being drawn.
    So, to collect more evidence, if anyone else encounters the problem, does it occur when you spin the globe, expecially when the cursor is near the north pole?
    Second, if it occurs, can you go to the base facility layout screen and see the facilities on the left, and go to X-Net and see models in the 3D window?
  • I had a quick look at FMOD docs to see if they support cross fading. It's mentioned in FMOD designer, but I think it's more for sound effects than music. Still a starting point if someone wants to look.
  • Also, to handle shuffle play a little more efficiently, someone might like to remove the polling in FmodGameComponent.Update() and use Channel.setCallback()

Link to comment
Share on other sites

[*] I've also been thinking a bit more about the "Earth scene in the Geoscape screen turning blue. My original theory was we were loosing the graphics device and not recovering it correctly. However Taz0k reported the problem happening when he tried spinning the globe. Which is when it happened to me.

So, my current thought is the problem might be there's some error in the globe spinning calcs that put the camera in a weird position (possibly a divide by zero that results in an invalid matrix, preventing anything from being drawn.

So, to collect more evidence, if anyone else encounters the problem, does it occur when you spin the globe, expecially when the cursor is near the north pole?

Second, if it occurs, can you go to the base facility layout screen and see the facilities on the left, and go to X-Net and see models in the 3D window?

Hmmm I recall describing it, but no problem anyway, that's what happened to me:

I was happily spinning the globe, and WHILE SPINING the globe screen turned blue. The cursor was at Central Europe's level, near the edge of the globe. The controls on the right were rendered fine, but I don't think I tried the up/down/etc buttons. So, I entered the baseview... I am not 100% sure now, but I think I could see the base and the X-Net. Nevertheless, returning to the globeview didn't help, still the same problem. So, I abandoned the game, I started a new one, but the screen was still blue! I tried to setup my first base, and I clicked near the center (I didn't think at the time to click out of the "globe area"), and the game crashed with an error message.

 

Edit: Funny, it happened again 10 mins ago. Started a new game, and before placing my first base I spinned around (indeed near north pole), and then it turned blue! I couldn't press any buttons (of course), and I just clicked somewhere in the blue (near the edges where there wouldn't be a globe) and it crashed.

Edited by kafros
Link to comment
Share on other sites

  • Merged in Darkhomb's sound options dialog
  • Put Darkhomb's XenoNew.png and XenoXNA.imageset into Xenocide\Resources and set build script to copy them over the original Taharez imageset, so we get the xenolook GUI Widgets.

Notes:

  • In order to replace the Taharez image set, I also renamed XenoXNA.imageset to Taharez.imageset

Link to comment
Share on other sites

  • Merged in Darkhomb's sound options dialog
  • Put Darkhomb's XenoNew.png and XenoXNA.imageset into Xenocide\Resources and set build script to copy them over the original Taharez imageset, so we get the xenolook GUI Widgets.

Notes:

  • In order to replace the Taharez image set, I also renamed XenoXNA.imageset to Taharez.imageset

 

You can either just rename it to Taharez.imageset, or if you delete Taharez.imageset XenoXNA.imageset works, it reads all imagesets, you just can not have both with the same imageset name in the file.

Link to comment
Share on other sites

  • Merged in Darkhomb's sound options dialog
  • Put Darkhomb's XenoNew.png and XenoXNA.imageset into Xenocide\Resources and set build script to copy them over the original Taharez imageset, so we get the xenolook GUI Widgets.

Notes:

  • In order to replace the Taharez image set, I also renamed XenoXNA.imageset to Taharez.imageset

 

You can either just rename it to Taharez.imageset, or if you delete Taharez.imageset XenoXNA.imageset works, it reads all imagesets, you just can not have both with the same imageset name in the file.

I prefer to rename the file, it means one less step in the build process.

 

Progress

  • Removed Unit Test button from Bases screen
  • Added "Reset Camera" button to Geoscape
  • Added prisonerItemType to item.xsd/.xml

Notes:

  • I haven't been able to create tbe "blue screen" in geoscape problem. However, in an attempt to confirm the diagnosis, I've added a Reset Camera button to the Geoscape.
    So, the next time someone sees the "blue screen", can they press the "reset camera" button and see if the earth re-appears. And then let me know. Thanks
  • I'm now looking at storing alien prisoners in X-Corp Outposts, and have come to the conclusion that I'm going to need to have two entries in xnet.xml for each alien. One as a corpse, the other as a prisoner.
    The reason being, they have different storage requirements. Corpses can be treated like any other item. They are stored in the General Storage Facility, and are interchangeable. In that say, one Grey corpse is identical to any other Grey corpse.
    Prisoners on the other hand are different. They are stored in Xeno Containment, and are unique. (e.g. A Grey soldier is NOT the same as a Grey Commander)
  • I've also updated research.xml to allow for this as well. (For research prerequisites, dead aliens are items, not combatants.)

Link to comment
Share on other sites

[*] I haven't been able to create tbe "blue screen" in geoscape problem. However, in an attempt to confirm the diagnosis, I've added a Reset Camera button to the Geoscape.

So, the next time someone sees the "blue screen", can they press the "reset camera" button and see if the earth re-appears. And then let me know. Thanks

 

Good idea. Just got a blue screen while zooming or rotating (not sure of which). After one click on the "reset camera" button the earth and sky map returned! One step closer to the core of the problem =b

 

--

 

I added a debug message to show Scene.CameraPosition and then managed to get another blue screen. The debug message wrote the Scene.CameraPosition as {X:NaN Y:NaN Z:2.021985}

 

Somehow I've always thought that illegal operations would cause exceptions but apparently not (see http://msdn2.microsoft.com/EN-US/library/a...46(VS.71).aspx).

 

--

 

I continue under the 0.1 Bugs topic.

Edited by taz0k
Link to comment
Share on other sites

I added a debug message to show Scene.CameraPosition and then managed to get another blue screen. The debug message wrote the Scene.CameraPosition as {X:NaN Y:NaN Z:2.021985}

Excellent work. We're hot on the trail of the bug.

 

Progress:

  • taz0k patch, to make zooming smother on Geoscape an X-Net
  • Can asign scientists to work on research topics
  • Destruction of an outpost kills all scientists in the outpost
  • SellScreen, can only sell idle Engineers and Scientists
  • StartSettings can include prisoners (however, more work is needed to make safe)

Notes:

  • At moment, can only add more scientists to a research project. Can't reduce the number.

 

I think I've posted this before, but I'm going to do it again, just to confirm everyone's willing to accept it.

The way research is going to work in v1.0 is:

  • There is a single reseach queue, and all available scientists work on the topmost topic in the queue. When it's done, they move onto next topic.
  • This means, the research capacity of all the X-Corp outposts is combined.
  • Player just gets to set the order of items in the queue.
  • As new topics become available, they're added to the bottom of the queue.
  • If a topic needs multiple items before it can be researched and the necessary items are in different outposts, the items do not need to be brough together before the research can start.
  • Manufacturing is probably going to be done on a per Outpost basis.

Note, the way it's currently been implemented (I think it was Rincewind) goes:

  • There is a single reseach queue.
  • The research capacity of all the X-Corp outposts is combined.
  • Player specifies which topics to research, and how many scientists to assign. (So you can research multiple topics at once.)
  • Note, research projects are not confined to specific outposts. (So loosing an outpost won't kill a research project.)
  • If a topic needs multiple items before it can be researched and the necessary items are in different outposts, the items do not need to be brough together before the research can start.

Link to comment
Share on other sites

Is there a technical Reason to change the research system? Because, I have to say, I've grown to love the X-COM:EU way of research, and I would like to keep it, if possible. Your way seems to be too restricting in my eyes.

 

Edit: Especially these two points strike me as too restrictive:

 

  • There is a single reseach queue, and all available scientists work on the topmost topic in the queue. When it's done, they move onto next topic.
     
  • Player just gets to set the order of items in the queue.

Edited by Mad
Link to comment
Share on other sites

Is there a technical Reason to change the research system? Because, I have to say, I've grown to love the X-COM:EU way of research, and I would like to keep it, if possible. Your way seems to be too restricting in my eyes.

 

Edit: Especially these two points strike me as too restrictive:

 

  • There is a single reseach queue, and all available scientists work on the topmost topic in the queue. When it's done, they move onto next topic.
  • Player just gets to set the order of items in the queue.

No, there's no technical reason for doing it. Main motivation was make the interface as simple as possible, research becomes a single screen, and user just puts items into priority order.

 

But, just to keep things straight, you're saying you prefer Rincewind's system (as currently implemented) or you want the original X-Com system, where research is per base? (Note, that's actually slightly easier to implement than Rincewind's system.)

 

Also, progress update:

  • Darkhomb's patch updating time display on Geoscape
  • taz0k patch, fix "blue screen" bug on Geoscape.
  • As blue screen has been fixed, I also removed the "Reset camera" button

Link to comment
Share on other sites

progress:

  • geerzo patch to specify model orientation in xnet
  • darkhomb's patch, adding funds to geoscape, and resizing zoom in/out left/right buttons
  • I have not included taz0k's mouse move patch at this time. I wish to contemplate it some more.

Notes:

  • geerzo patch means someone should now go through xnet.xml, fixing up the model initial orientations. x, y & z are rotations in degrees around x, y and z axis.
  • geerzo Nice work. you might like to inspect the changes I made to your patch.
  • taz0K mouse move patch. My current thinking is, you're correct that a mouse move of 0 is not really valid. (It's almost certainly responsible for the GetAzimuth() problem you recently tracked down.)
    However, the ideal place to fix the problem is in the CeGUI library, not our code. I suggest you start by looking at xenocide\Dependancies\CeGui\CeGui.Renderers.Xna\Source\InputInjector.cs
  • geerzo, I ran out of time to check the dialog title patch.

Link to comment
Share on other sites

But, just to keep things straight, you're saying you prefer Rincewind's system (as currently implemented) or you want the original X-Com system, where research is per base? (Note, that's actually slightly easier to implement than Rincewind's system.)

I would prefer Rincewinds system. That said, I would love to have the previously discussed "researched item not in researching base" i.e. "comunication" research penalties for v 1+

Link to comment
Share on other sites

Notes:
  • geerzo patch means someone should now go through xnet.xml, fixing up the model initial orientations. x, y & z are rotations in degrees around x, y and z axis.

I'll do it. What orientation should all models have by default? Top view, side view, 3/4, ...?
Link to comment
Share on other sites

progress

  • darkhomb's patch for image buttons on Geoscape
  • taz0k patch to avoid injecting mouse moves of zero distance merged. (It required significant revision.)
  • cgoat's patch to allow manually starting UFO missions

Notes:

  • Darkhomb, when I suggested copying the graphics from planetview.png into XenoNew.png, I meant only the ones that are actually used in the Geoscape.
    It's not really a problem, but at some time in the future someone might want to cull the unused graphics from XenoNew.png.
  • taz0k, you might like to have a look and see how I've changed GuiSystem.cs to avoid getting Mouse Moves of 0 distance.
  • cgoat, nice work. Thank you for pointing out I hadn't connected up the Abduction and Harvest missions. You actually did more than I anticipated, I was thinking just use the X-Corp Base as the centroid for the missions.
    Actually, I might remove the TargetAlienMissionState from GeoscapeScreen anyway, just to cut down the file size.
    One minor point, you need to put a copyright notice on the files you create. And I believe you need to use your real name (for legal reasons.) I've been doing that wrong.

Link to comment
Share on other sites

Actually, I might remove the TargetAlienMissionState from GeoscapeScreen anyway, just to cut down the file size.

 

I feel like there should just be a single "targeting" state that can be used for everything: targeting craft, selecting a base site, selecting an alien mission site. That seemed like too much of a change for a debug function. I do think that being able to select the site offers additional debug functionality that may be desired down the road and is probably worth keeping.

Link to comment
Share on other sites

I suggested copying the graphics from planetview.png into XenoNew.png, I meant only the ones that are actually used in the Geoscape.

It's not really a problem, but at some time in the future someone might want to cull the unused graphics from XenoNew.png.

 

 

The reason I put those in there is because I plan on using them, they will be the buttons for time/stop and some static images to get it fully looking like it did.

Link to comment
Share on other sites

Quick status update since a lot is going on:

 

1) The Frame/Dialog framework now supports defining dialogs using .layout files removing the need to define widgets in code.

2) 3/4 of the current dialogs have been converted to use the .layout files.

3) The MessageBox and YesNo dialogs will not be converted at this time since they are "customizable" dialogs.

4) .layout files support connecting widget events to code handlers directly

5) I've started creating a Xenocide widget set for CeGUI#. This allows us to add capabilities we need. The only widget I have so far is a button which supports defining an "AudioFilename" string so that we can define sounds to be played when the button is pressed (still requires one line of code in the dialog to hook it up but I'm hoping to fix that). This is based upon the Tarahaz code base.

6) Started to add XML Schema support to CeGUI#. While this adds a little overhead (we now have to define namespaces within our xml files) it gives the benefit for expansion over time through versioning. It also makes it much easier to enable XML code completion when editing xml files such as .layout files.

 

Current Limitations:

 

1) Only properties specifically marked with certain attributes are able to be set from the .layout files (i.e. XPosition, Width...). We can however very easily make more properties available by adding the attributes.

2) Only properties whose value type has a static Parse(string) method are supported. I think we can add support for other types but it will be in the future. This requires us to define two properties (XPosition, YPosition) instead of a single one (Position) in some cases.

3) Event Handlers that are mapped from .layout files must be public and have the [GuiEvent()] attribute.

4) CeGUI only finds new widget sets whose filename is in the format of CeGUI.WidgetSets.*.dll. So our new set is called CeGUI.WidgetSets.Xenocide.dll. I don't particularly like this but we'll fix it later.

 

Next Steps:

 

1) Extend the new button to support defining custom images from the .layout file.

2) Evaluate what it is going to take to build out the scheme and falagard capabilities within CeGUI#

3) Tweak CeGUI# to add a Assembly level attribute to denote if the dll contains a widget set. This will allow us to rename our custom widget set Xenocide.WidgetSet or something similar so it doesn't look like CeGUI project code.

4) Add support for .layout files to the screen framework and convert the screens over.

 

Questions:

 

1) Copyrights. When reusing (copying) code from CeGUI# which is released under LGPL, what copyright do we use? Can we use ours or do we have to stick with LGPL or list both? I'm sure there is some attribution we have to do also.

2) What other "custom" widgets capabilities would people like to see over time?

Link to comment
Share on other sites

1) Copyrights. When reusing (copying) code from CeGUI# which is released under LGPL, what copyright do we use? Can we use ours or do we have to stick with LGPL or list both? I'm sure there is some attribution we have to do also.

I'm not a laywer, so I'm not sure.

Easiest solution might be we just give CeGUI.WidgetSets.Xenocide.dll a LGPL license and in the copyright notice add that parts of the source were copied from CeGUI#. Is that a problem?

Although ideally we'd want to factor out as much common code as possible, and push the common code into CeGUI# itself.

 

 

2) What other "custom" widgets capabilities would people like to see over time?

I did a list a while ago.

I think, beyond the controls we already see there's only a couple of other widgets that would be useful (regrettably, they're probably going to be a lot of work to implement.)

  • tree control. (X-Net)
  • multi line text box with fast scrolling (X-Net)
  • List box with checkbutton items (Statistics.)
  • Horizontal slider control

Link to comment
Share on other sites

1) Copyrights. When reusing (copying) code from CeGUI# which is released under LGPL, what copyright do we use? Can we use ours or do we have to stick with LGPL or list both? I'm sure there is some attribution we have to do also.

I'm not a laywer, so I'm not sure.

Easiest solution might be we just give CeGUI.WidgetSets.Xenocide.dll a LGPL license and in the copyright notice add that parts of the source were copied from CeGUI#. Is that a problem?

Although ideally we'd want to factor out as much common code as possible, and push the common code into CeGUI# itself.

 

My other option was to extend from the Taharez widget set but having dependent widget sets doesn't sound like a good long term plan. If they are completely separate (yet similar) it will make it easier for us to do things like rename out imageset to Xenocide instead of having to stick with Tarahez so it just drops in place. Plus, in case they make changes it won't break us down the road.

Link to comment
Share on other sites

Actually, I might remove the TargetAlienMissionState from GeoscapeScreen anyway, just to cut down the file size.

 

I feel like there should just be a single "targeting" state that can be used for everything: targeting craft, selecting a base site, selecting an alien mission site.

Sounds reasonable, although I think you'll find most of them ARE targetting states, each with the logic that's specific to the type of entity being targeted. So I'm not sure you'd gain anything by rolling them into a single targetingState class.

 

That seemed like too much of a change for a debug function.

I do think that being able to select the site offers additional debug functionality that may be desired down the road and is probably worth keeping.

I stand corrected.

 

I suggested copying the graphics from planetview.png into XenoNew.png, I meant only the ones that are actually used in the Geoscape.

It's not really a problem, but at some time in the future someone might want to cull the unused graphics from XenoNew.png.

 

 

The reason I put those in there is because I plan on using them, they will be the buttons for time/stop and some static images to get it fully looking like it did.

That makes sense.

 

My other option was to extend from the Taharez widget set but having dependent widget sets doesn't sound like a good long term plan. If they are completely separate (yet similar) it will make it easier for us to do things like rename out imageset to Xenocide instead of having to stick with Tarahez so it just drops in place. Plus, in case they make changes it won't break us down the road.

You're correct, extending Taharez is not a good idea.

IIRC, the way CeGUI is supposed to be used (in 0.4) is you create a widget set and use it. The supplied Suave, Taharez and Windows are really just sample sets.

That said, in 0.5, the idea is build your widget sets using looknfeel.

So even if we copy code initially, when/if falgard works we may well obsolete it.

Link to comment
Share on other sites

Just a couple of things, I had to study a lot the licensing terms... Even though I am not a lawyer the copyright is not required as you using the Creative Commons can use the code you do in whatever you like because you are giving a license to Xenocide to use for whatever it may fit; nonetheless Xenocide derived code must be free too. So as long as you can identify that you created some code it is ok. The point is that in a very entangled codefile almost everything you do is "derived" in the CC sense. For example if you provide the whole battlescape code, and reuse it somewhere else as long is the version you provided is valid for the license... too much legalize but the only "required" step is tracking who worked and everything given from the start that cannot be considered "derived work" a pretty difficult thing that only a court can really disambiguate (even if wrongly ;) ). So in short, just keep a list of "features" for credits purposes ;)

 

About the LGPL you cannot copy code from the CeGUI# base, either you reimplement it or use it through a .dll (only way).

 

Greetings

Red Knight

Link to comment
Share on other sites

About the LGPL you cannot copy code from the CeGUI# base, either you reimplement it or use it through a .dll (only way).

 

I will need to chew on this then. Most of the code seems rather standard so I'll have to figure out how to reimplement it so it's different enough. It will just take me a while to understand it well enough. Would it be possible to release the majority of Xenocide under CC yet release just this piece under LGPL? Another option would be to develop the widget set we think we need then submit it as part of CeGUI#.

 

Just some thoughts.

 

So even if we copy code initially, when/if falgard works we may well obsolete it.

 

I'll look again at falagard and see more specifically how it works.

Link to comment
Share on other sites

Just a couple of things, I had to study a lot the licensing terms... Even though I am not a lawyer the copyright is not required as you using the Creative Commons can use the code you do in whatever you like because you are giving a license to Xenocide to use for whatever it may fit; nonetheless Xenocide derived code must be free too. So as long as you can identify that you created some code it is ok. The point is that in a very entangled codefile almost everything you do is "derived" in the CC sense. For example if you provide the whole battlescape code, and reuse it somewhere else as long is the version you provided is valid for the license... too much legalize but the only "required" step is tracking who worked and everything given from the start that cannot be considered "derived work" a pretty difficult thing that only a court can really disambiguate (even if wrongly ;) ). So in short, just keep a list of "features" for credits purposes ;)

 

About the LGPL you cannot copy code from the CeGUI# base, either you reimplement it or use it through a .dll (only way).

 

Greetings

Red Knight

I think there might be a bit of a mis-communication here.

What geerzo was suggesting was building a DLL to hold the Xenocide widgets, similar to the CeGui.WidgetSets.Taharez.dll that is part of CeGui. To build this CeGui.WidgetSets.Xenolook.dll the easiest way would be copy the Taharez DLL's code, and modify for our needs.

Doing this (copying code from Taharez) would mean that the CeGui.WidgetSets.Xenolook.dll would need to adopt the LGPL license. However, the LGPL would only need to apply to this library. It would not need to apply to Project Xenocide as a whole, which uses the DLL.

Link to comment
Share on other sites

Just a couple of things, I had to study a lot the licensing terms... Even though I am not a lawyer the copyright is not required as you using the Creative Commons can use the code you do in whatever you like because you are giving a license to Xenocide to use for whatever it may fit; nonetheless Xenocide derived code must be free too. So as long as you can identify that you created some code it is ok. The point is that in a very entangled codefile almost everything you do is "derived" in the CC sense. For example if you provide the whole battlescape code, and reuse it somewhere else as long is the version you provided is valid for the license... too much legalize but the only "required" step is tracking who worked and everything given from the start that cannot be considered "derived work" a pretty difficult thing that only a court can really disambiguate (even if wrongly ;) ). So in short, just keep a list of "features" for credits purposes ;)

 

About the LGPL you cannot copy code from the CeGUI# base, either you reimplement it or use it through a .dll (only way).

 

Greetings

Red Knight

I think there might be a bit of a mis-communication here.

What geerzo was suggesting was building a DLL to hold the Xenocide widgets, similar to the CeGui.WidgetSets.Taharez.dll that is part of CeGui. To build this CeGui.WidgetSets.Xenolook.dll the easiest way would be copy the Taharez DLL's code, and modify for our needs.

Doing this (copying code from Taharez) would mean that the CeGui.WidgetSets.Xenolook.dll would need to adopt the LGPL license. However, the LGPL would only need to apply to this library. It would not need to apply to Project Xenocide as a whole, which uses the DLL.

That is a valid approach as long as that code is used only in binary form :)

 

Greetings

Red Knight

Link to comment
Share on other sites

So even if we copy code initially, when/if falgard works we may well obsolete it.

 

I'll look again at falagard and see more specifically how it works.

Since I worked extensively with CEGUI on the C++ branch, I figured I'd share what I know.

 

As dteviot pointed out, Falagard completely obsoletes the separate Widget Set packages. The code that defines the individual elements (what makes a button, listbox, etc.) becomes part of CEGUI while the widget set itself is reduced to XML that defines the look of said elements (as well as having sub-types). This automatically gets rid of the problem of deriving everything off Taharez and worrying about licenses for modifying said code, the problem of XenoWidgets being so damn non-standard and the problem of every button looking the same.

 

As for having custom properties, I don't know how you're implementing it, but CEGUI just had some get/setProperty("PropertyName") functions which allowed you to use whatever crazy properties one added in layouts. Speaking of which, nice job implementing them. :)

 

Let me know if you have any more CEGUI-related questions.

Edited by SupSuper
Link to comment
Share on other sites

I was going to post a beta patch for the .layout changes so people could see what's going on but ran into a problem with generating the patch. I had to add a folder or two plus new files however the TortoiseSVN patch utility won't add files that were added under an added folder to a patch (new folder with new files in it). Should I just generate the patch then seperately zip up the new files that the patch doesn't include or is there a better work around?
Link to comment
Share on other sites

I was going to post a beta patch for the .layout changes so people could see what's going on but ran into a problem with generating the patch. I had to add a folder or two plus new files however the TortoiseSVN patch utility won't add files that were added under an added folder to a patch (new folder with new files in it). Should I just generate the patch then seperately zip up the new files that the patch doesn't include or is there a better work around?

 

 

Try right clicking the files in the folder and under the TortoiseSVN menu click the add option, then create the patch and the files will be in there.

Link to comment
Share on other sites

I was going to post a beta patch for the .layout changes so people could see what's going on but ran into a problem with generating the patch. I had to add a folder or two plus new files however the TortoiseSVN patch utility won't add files that were added under an added folder to a patch (new folder with new files in it). Should I just generate the patch then seperately zip up the new files that the patch doesn't include or is there a better work around?

 

 

Try right clicking the files in the folder and under the TortoiseSVN menu click the add option, then create the patch and the files will be in there.

 

I had done that before trying the patch. It seems to add the folder to the patch but not the files underneath it.

Link to comment
Share on other sites

I was going to post a beta patch for the .layout changes so people could see what's going on but ran into a problem with generating the patch. I had to add a folder or two plus new files however the TortoiseSVN patch utility won't add files that were added under an added folder to a patch (new folder with new files in it). Should I just generate the patch then seperately zip up the new files that the patch doesn't include or is there a better work around?

 

 

Try right clicking the files in the folder and under the TortoiseSVN menu click the add option, then create the patch and the files will be in there.

 

I had done that before trying the patch. It seems to add the folder to the patch but not the files underneath it.

 

Just add the new files to the zip. I did that and dteviot figured it out. :P

Link to comment
Share on other sites

Well, it appears to have included them in the patch this time, even though the warning said it wouldn't. This patch is code complete to covert the dialogs to use .layout files but I still need to go back and add/update comments. I just wanted to put this out there so people could see the direction I'm taking with it. I ended up removing the custom widget set so button sounds still need to be defined in code. Take a look at OptionsDialog to see how I tweaked that to make it work along with .layout setups.

Layouts.zip

Link to comment
Share on other sites

latest update:

  • Removed Prisoner and PrisonerItem classes
  • Mad's updates to item.xml and research.xml, work on corpse/prisioner items
  • Moved StartOfMonth processing to HalfHourRepeatingGeoAppointment class
  • Minor cleanup of XNetEntry XML parsing code
  • Moved GeoscapeScreen's nested state classes to separate file
  • Purchases now take 48 hours to arrive.
  • Implemented "Show transfers" screen. (which shows purchases and UFO salvage in transit)
  • Eliminated a number of FxCop warnings

Notes:

  • Note, I now assume salvage from missions is NOT carried on X-Corp craft, so it takes 48 hours to arrive at an outpost.

Link to comment
Share on other sites

Well, it appears to have included them in the patch this time, even though the warning said it wouldn't. This patch is code complete to covert the dialogs to use .layout files but I still need to go back and add/update comments. I just wanted to put this out there so people could see the direction I'm taking with it. I ended up removing the custom widget set so button sounds still need to be defined in code. Take a look at OptionsDialog to see how I tweaked that to make it work along with .layout setups.

Very nice. One minor point, it was possible to specify a multi column list's column titles in the .layout

e.g.

 

<Window Type="TaharezLook/MultiColumnList" Name="Demo7/Window2/MultiColumnList" >
<Property Name="UnifiedMaxSize" Value="{{1,0},{1,0}}" />
<Property Name="UnifiedAreaRect" Value="{{0.05,0},{0.6,0},{0.95,0},{0.98,0}}" />
<Property Name="ColumnHeader" Value="text:Server Name width:{0.33,0} id:0" />
<Property Name="ColumnHeader" Value="text:Address width:{0.5,0} id:1" />
<Property Name="ColumnHeader" Value="text:Ping width:{0.2,0} id:2" />
</Window>

Link to comment
Share on other sites

Well, it appears to have included them in the patch this time, even though the warning said it wouldn't. This patch is code complete to covert the dialogs to use .layout files but I still need to go back and add/update comments. I just wanted to put this out there so people could see the direction I'm taking with it. I ended up removing the custom widget set so button sounds still need to be defined in code. Take a look at OptionsDialog to see how I tweaked that to make it work along with .layout setups.

Very nice. One minor point, it was possible to specify a multi column list's column titles in the .layout

e.g.

 

<Window Type="TaharezLook/MultiColumnList" Name="Demo7/Window2/MultiColumnList" >
<Property Name="UnifiedMaxSize" Value="{{1,0},{1,0}}" />
<Property Name="UnifiedAreaRect" Value="{{0.05,0},{0.6,0},{0.95,0},{0.98,0}}" />
<Property Name="ColumnHeader" Value="text:Server Name width:{0.33,0} id:0" />
<Property Name="ColumnHeader" Value="text:Address width:{0.5,0} id:1" />
<Property Name="ColumnHeader" Value="text:Ping width:{0.2,0} id:2" />
</Window>

 

It is in the C++ version apparently but it doesn't work in the C# version, or at least not yet. In fact, Unified settings don't work either yet. At the moment you can only set true C# properties. Another limitation is that you can only set Properties thats value object has a static Parse method or there is a custom loader written (there aren't many). I'm looking at ways to expand on that capability. I'll probably be off in CeGUI# land for a bit.

Link to comment
Share on other sites

Progress:

  • Transfer items screen implemented

Notes:

  • At moment, cost of transfering an item is 1% of its buy or sell cost, whichever is greater. If this is unacceptable, we can always add a "transfer cost" attribute to each entry in item.xml.
  • I believe this concludes inventory. At least in terms of buy/sell/transfer items in a base. Please let me know if I've forgotten anything. Well, except for:
    • Adding full definition for the troopItemType objects and its derived classes.
    • Billing player for monthly rental/salaries for craft/personel in transit at start of month.

Link to comment
Share on other sites

progress:

  • StaffSergeant's patch, to record version info in save game file
  • Taz0k's patch, allow full rotation of X-Net camera

Notes:

  • StaffSergeant, nice patch. A couple of minor quibbles: You duplicated the get version string code (fixed), and there was an opportunity to encapsulate some more (which I took.) While I was in there, I also took the liberty of cleaning up some more of the code. (LoadSaveScreen was NOT my best work. In my defense, I was still learning C# when I wrote it.)
  • Taz0k, I can't find anything wrong with your patch. (Possibly because my Matrix math is very rusty.) At any rate, it appears to work and is an improvement. So I've accepted it.

Link to comment
Share on other sites

CEGUI++ added it by the time Falagard came along, that'd explain why CEGUI# doesn't have it. Technically speaking, it's just a matter of swapping all the X/Y and Width/Height in the slider code. Maybe geerzo could look into that, since we don't use vertical sliders anyways.
Link to comment
Share on other sites


×
×
  • Create New...