SSU Development Thread (2.0 to 3.0)

[DaveS]

No, I never used anything but SVN. The local repository thing seems interesting as a backup to the server, which is something I wanted to get for sometime now... any idea how big the history of SSU is?

I believe it goes all the way back to the very start of SSU, back in 2008 before SSU was SSU and Space Shuttle Deluxe.

 

[Urwumpe]

I believe it goes all the way back to the very start of SSU, back in 2008 before SSU was SSU and Space Shuttle Deluxe.

Yes. Also that was at a time when Mercurial and git had still been pretty exotic (git and Mercurial started development in 2005, I had not seen a stable windows client of any of them before 2010)

I would prefer git over Mercurial in that question, simply because git support is now standard in Visual Studio and also supported by other Microsoft development tools. For Mercurial, we would need third-party tools like VisualHG. (And I have more practical experiences in using git with the internal Visual Studio client)

By the features, Mercurial and git are both almost identical, there is only the small conceptual difference that Mercurial operates by change sets, while git uses snapshots. Practically, you only notice the difference by the two in extreme conflict situations.

---------- Post added at 06:25 PM ---------- Previous post was at 05:46 PM ----------

Another extreme is of course to fall back to diffing and patching. Don't know why you want that now out of a sudden.

Look, lets make it much easier. You have no problem here at all. We have it. The milk is already poured here and your friendly suggestions from the sideline how much better we would have had it, had we been using your favorite tool, are not really helping us right now. But you sure feel like a hero about your hindsight having 20/20.

Also, what you call extremes are normal situations. It is not like what I describe there does not happen except in Roland Emmerich movies. If you tell me that you never had such problems in development to deal with, maybe you never had the problem that the real world consists of you knowing many better tools, but you having to stick to the good enough for economic reasons. Or you had been extremely lucky. Even having Mercurial did not prevent problems (Some bugs in TortoiseHg even caused their own problems back then)

And trust me: Diff/Patch is not the most low-tech solution to get code changes into the master instance.

Extreme would be using printed sources with text marker highlights of the changed statements and mail.

---------- Post added at 08:47 PM ---------- Previous post was at 06:25 PM ----------

No, I never used anything but SVN. The local repository thing seems interesting as a backup to the server, which is something I wanted to get for sometime now... any idea how big the history of SSU is?

It is more than just a back-up for a central master repository. You can for example also create local branches in git, which allow you to work locally on stuff without somebody else ever seeing it, which makes feature branches less painful than they are in SVN.

Also, since you not only commit or revert changes to your local repository, but also have to push/pull changes from outside (master or any other instance), you have a completely different way to organize your development work.

You can't make people better developers with git (Some still only sync their changes shortly before release and then wonder why they need weeks for fixing the collisions), but if you plan to operate agile and especially if you are interested in continuous delivery, git is a great tool.

 

[Donamy]

I thought Face was just trying to be helpful. Here I thought we were close to a release, boy was I mistaken.

 

[DaveS]

I thought Face was just trying to be helpful. Here I thought we were close to a release, boy was I mistaken.

Well, with SVN still down none of us can add our bug-fixes to the release pack. So all hinges on when SourceForge gets to restoring SVN services.

Edit:
Also none of Face's suggestion solves the fact that we don't have a common place to pool our work.

 

[GLS]

It is more than just a back-up for a central master repository. You can for example also create local branches in git, which allow you to work locally on stuff without somebody else ever seeing it, which makes feature branches less painful than they are in SVN.

Also, since you not only commit or revert changes to your local repository, but also have to push/pull changes from outside (master or any other instance), you have a completely different way to organize your development work.

You can't make people better developers with git (Some still only sync their changes shortly before release and then wonder why they need weeks for fixing the collisions), but if you plan to operate agile and especially if you are interested in continuous delivery, git is a great tool.

I've read somethings today about DVCS and I'm trying to wrap my head around it. I think it might be possible to avoid the users getting isolated from each other (due to each having his/hers repository) by having a policy (probably unenforceable) of doing commits and pushes together, and on the other end having devs trying to keep the local repositories as updated as possible. In a way just using the local repository as a back up, and in situations like this it would allow for some work to continue. I still haven't thought about how the branches would work.

 

[Urwumpe]

I thought Face was just trying to be helpful. Here I thought we were close to a release, boy was I mistaken.

Same was my thought until last weekend. Right now I feel like I am in the wrong project.

---------- Post added at 10:16 PM ---------- Previous post was at 10:11 PM ----------

I've read somethings today about DVCS and I'm trying to wrap my head around it. I think it might be possible to avoid the users getting isolated from each other (due to each having his/hers repository) by having a policy (probably unenforceable) of doing commits and pushes together, and on the other end having devs trying to keep the local repositories as updated as possible. In a way just using the local repository as a back up, and in situations like this it would allow for some work to continue. I still haven't thought about how the branches would work.

Well, you can work like that. But again, this only solves the low-level problems. When we want to do a release, we have to make sure that everybody who has something that must get into the release also pushes his changes to the master branch on the repository that should be reference for the release. It must not be the repository on a central server. But having one single point of contact that is available 24/7 makes the work a lot easier as you can expect.


Also, the branches work pretty much like that: You create a branch locally on your repository. You can keep it like that. Or you can make the branch public, so that it is exchanged when you sync with another repository.

 

[GLS]

Well, with SVN still down none of us can add our bug-fixes to the release pack. So all hinges on when SourceForge gets to restoring SVN services.

Edit:
Also none of Face's suggestion solves the fact that we don't have a common place to pool our work.

I think tomorrow afternoon/night it might be back up. According to the updates there's one more system to be restored and then SVN is next. We should then give it a few hours to allow it to "stabilize" and also to let the initial wave of traffic pass (it will have most/all SVN projects there doing changes and who knows what will happen to the servers). So I'd guess Saturday morning we will be back on business.

 

[DaveS]

I think tomorrow afternoon/night it might be back up. According to the updates there's one more system to be restored and then SVN is next. We should then give it a few hours to allow it to "stabilize" and also to let the initial wave of traffic pass (it will have most/all SVN projects there doing changes and who knows what will happen to the servers). So I'd guess Saturday morning we will be back on business.

AFAIK, the servers are fine. It is the file system that for some reason took a dive and became corrupted. If it had been the hardware SF.net would been 404's and not maintenance/503's.

 

[Urwumpe]

AFAIK, the servers are fine. It is the file system that for some reason took a dive and became corrupted. If it had been the hardware SF.net would been 404's and not maintenance/503's.

Thats not that easy on a bigger infrastructure, since it is a lot different to your local computer. Often you have a multi-tier architecture behind the address. This means, your filesystem servers can still be partially down or in maintenance, while the front-end web-servers still reply and give you 503s, while work is underway.

 

[GLS]

SourceForge Mercurial (Hg) service online
I think SVN is next :woohoo:

 

[SiameseCat]

I would prefer git over Mercurial in that question, simply because git support is now standard in Visual Studio and also supported by other Microsoft development tools. For Mercurial, we would need third-party tools like VisualHG. (And I have more practical experiences in using git with the internal Visual Studio client)

I actually prefer Mercurial over Git for that reason; TortoiseHG is really good, better than TortoiseSVN and anything I've seen for Git. I haven't tried Git in Visual Studio, though.

 

[Face]

Also none of Face's suggestion solves the fact that we don't have a common place to pool our work.

What suggestions? I wasn't even able to suggest something - beyond trying to migrate away from centralized version control - before being attacked for daring to speak up.

As I wrote before: I just joined the discussion because you seemed to be in need of some help, and because my nick was mentioned. But getting ridiculed is certainly nothing that will motivate me to continue it.

 

[GLS]

About the new talkbacks, can we edit the groups directly with this?

	/**
	* \brief Returns a pointer to the group specification of a mesh group.
	* \param hMesh mesh handle
	* \param idx group index (>=0)
	* \return pointer to mesh group specification (or NULL if idx out of range)
	* \note \b MESHGROUP is a structure that contains the components of the
	*   group, including vertex list, index list, texture and material index.
	* \note This method can be used to edit the a mesh group directly (for geometry
	*  animation, texture animation, etc.)
	* \note This function should only be applied to device-independent meshes,
	*   such as mesh templates.
	* \note For device-dependent mesh instances (such as returned by
	*   \ref VESSEL::GetDevMesh) use \ref oapiEditMeshGroup instead.
	* \sa oapiEditMeshGroup
	*/
OAPIFUNC MESHGROUP *oapiMeshGroup (MESHHANDLE hMesh, DWORD idx);
OAPIFUNC MESHGROUP *oapiMeshGroup (DEVMESHHANDLE hMesh, DWORD idx);

Or for us this just to get the data for a group?

 

[DaveS]

Latest SourceForge update: http://sourceforge.net/blog/sourceforge-infrastructure-and-service-restoration-update-for-724/

SourceForge Allura Subversion (SVN) service – offline, filesystem checks complete, data restoration has completed 22 letters (4 remain). This is our current restore priority. We project restore of data to complete by 7/25, to be followed by data validation and restore of service. ETA to follow once I/O performance calculated during data validation.

 

[GLS]

About the new talkbacks, can we edit the groups directly with this?

	/**
	* \brief Returns a pointer to the group specification of a mesh group.
	* \param hMesh mesh handle
	* \param idx group index (>=0)
	* \return pointer to mesh group specification (or NULL if idx out of range)
	* \note \b MESHGROUP is a structure that contains the components of the
	*   group, including vertex list, index list, texture and material index.
	* \note This method can be used to edit the a mesh group directly (for geometry
	*  animation, texture animation, etc.)
	* \note This function should only be applied to device-independent meshes,
	*   such as mesh templates.
	* \note For device-dependent mesh instances (such as returned by
	*   \ref VESSEL::GetDevMesh) use \ref oapiEditMeshGroup instead.
	* \sa oapiEditMeshGroup
	*/
OAPIFUNC MESHGROUP *oapiMeshGroup (MESHHANDLE hMesh, DWORD idx);
OAPIFUNC MESHGROUP *oapiMeshGroup (DEVMESHHANDLE hMesh, DWORD idx);

Or for us this just to get the data for a group?

Never mind that.
So I managed to come up with something that works.... sometimes. I think the "core" is good, but there's some issues to work out: doesn't work in D3D9, it updates after the first frame (instead of before) and it's still missing the "reset" part for when the visuals are re-created during the simulation. Other than that it does what it was expected. I've redone the talkback.dds texture to have bigger talkback "labels", and I'm using panel R13L for testing as it already has all the talkback groups in the correct place and they use the talkback.dds texture, so I just had to tweak the UVs of those groups in the mesh to lineup correctly.

---------- Post added at 03:13 PM ---------- Previous post was at 03:07 AM ----------

Talkback status report: fixed 2 of the 3 problems above, but it still doesn't work in D3D9. The problem seems to be the call to oapiMeshGroupEx (to get the current UVs), as it returns trash in D3D9 but works as expected in MOGE. If I use oapiMeshGroup it goes BUM in both clients.

 

[DaveS]

Never mind that.
So I managed to come up with something that works.... sometimes. I think the "core" is good, but there's some issues to work out: doesn't work in D3D9, it updates after the first frame (instead of before) and it's still missing the "reset" part for when the visuals are re-created during the simulation. Other than that it does what it was expected. I've redone the talkback.dds texture to have bigger talkback "labels", and I'm using panel R13L for testing as it already has all the talkback groups in the correct place and they use the talkback.dds texture, so I just had to tweak the UVs of those groups in the mesh to lineup correctly.

---------- Post added at 03:13 PM ---------- Previous post was at 03:07 AM ----------

Talkback status report: fixed 2 of the 3 problems above, but it still doesn't work in D3D9. The problem seems to be the call to oapiMeshGroupEx (to get the current UVs), as it returns trash in D3D9 but works as expected in MOGE. If I use oapiMeshGroup it goes BUM in both clients.

Maybe you should post about oapiMeshGroupEx's behavior in the D3D9Client thread? If it indeed is not working D3D9Client but the inline client maybe it is a D3D9Client bug that needs attention?

 

[Urwumpe]

Everything that is DEVMESHHANDLE based should work on a graphics client.

 

[GLS]

This is the code:

		if (STS()->hDevVCMesh == 0) return;
		MESHGROUPEX* mg = oapiMeshGroupEx( STS()->hDevVCMesh, grpIndex );

		for (unsigned short i = 0; i < mg->nVtx; i++)
		{
			mg->Vtx[i].tu += (TALKBACK_U_OFFSET[tkbk_next_state] - TALKBACK_U_OFFSET[tkbk_state]);
			mg->Vtx[i].tv += (TALKBACK_V_OFFSET[tkbk_next_state] - TALKBACK_V_OFFSET[tkbk_state]);
		}
		tkbk_state = tkbk_next_state;

		GROUPEDITSPEC grpSpec;
		grpSpec.flags = GRPEDIT_VTXTEX;
		grpSpec.Vtx = mg->Vtx;
		grpSpec.nVtx = mg->nVtx;
		grpSpec.vIdx = NULL;
		oapiEditMeshGroup( STS()->hDevVCMesh, grpIndex, &grpSpec );
		STS()->MeshModified( STS()->hDevVCMesh, grpIndex, 0 );

After the call in the 2º line is made, accessing mg does BUM. And yes. it's using DEVMESHHANDLE.

 

[jarmonik]

I'll take a look and let's see what I can find. I'll report back.
Edit: What's a MOGE ?

 

[GLS]

I'll take a look and let's see what I can find. I'll report back.
Edit: What's a MOGE ?

Martin's Own Graphics Client :rofl:
Anyway, with some help, this seems to be working now. Instead of giving the DEVMESHHANDLE to oapiMeshGroupEx, I now give the GetMeshTemplate handle. This way, D3D9 works as expected, except now the log file has several lines "EVENT_VESSEL_MODMESHGROUP Not Implemented".:shrug: