Free Allegiance Forums

Orion wrote:QUOTE (Orion @ Jul 19 2010, 09:00 PM) You need to install Microsoft .NET 4.0

That was it.

Mods work fine, no surprise, but I found out OH crashes Alleg for some reason... not related to the mods.
I just wanted to launch OH to have a relaxed look at their tech while I'm testing and got a nasty surprise, followed by a lot of coming and going to remove mods and test it.
I'm still not 100% sure it's not my mods, so I'm not uploading yet.
Dammit, I shouldn't have been working on three mods at once... I maybe screwed something up doing something I don't even remember doing.

One thing is for sure, being unable to uninstall mods in 10s is fantastic.

EDIT:
Crash was unrelated (funky missionbrief.mdl) and fixed.
Uploaded HD prox and alternative ammo/fuel icons.

I'll review the mods tonight.

Edit: Tested & passed.

For future reference; you can put images etc in the description (remote linking) so dont hesitate to pretty them up, descriptions support HTML.

I want to re-upload one of my mods after editing only the description. (I took the HTML suggestion seriously)
The website says "same version". Agh.

What do I do? Do I have to change the version number?

Yes. Go e.g. from 1.0.0.0 to 1.0.0.1

Yep, then re-upload and I have to re-approve it.

Great.
Now I need to decide on a system for version numbers...

Suggestion and a half:
Separate the mod from the description, it will save a lot of pain later.
The way it is now, fixing a bad link in the description will force the author to re-upload, go thru re-approval and then users will get a message that a newer version is available... for no reason.
A minor issue for a 9k icon, a big headache for a 30MB texture pack.

I suggest a wiki-ish approach to description. Maybe even link the whole thing to the Alleg wiki, so Modulus users will not be dependent on just the author's description. Mod users will be able to edit details like conflicts etc. I don't think there's any serious downside to using the wiki for this and the advantages are obvious.

Another suggestion:
Add a tag system.
It doesn't have to be functional right away, just put it in there for the future and decide on just a few basic tags so authors can be ready.
Examples:
HD - anything high res
GUI - anything guish
HUD - ...
TEXTURE - ...
ICON - like my fuel/ammo icons (I'm going to make an improved missile icone next...)
DIALOG - anything which modifies dialog.mdl
VC - ...

rewrite_count.functionality_added_count.bugfix_count.repackage_count

Happy?

Spinoza wrote:QUOTE (Spinoza @ Jul 21 2010, 01:49 AM) Separate the mod from the description, it will save a lot of pain later.
The way it is now, fixing a bad link in the description will force the author to re-upload, go thru re-approval and then users will get a message that a newer version is available... for no reason.
A minor issue for a 9k icon, a big headache for a 30MB texture pack.

Strongly against. No two releases should ever have the same version number, that's just asking for pain. Support request: "Well, are you using the version 1.2.3 I uploaded before Friday or the one I uploaded afterwards?" A description change is a change like any other, treat it as such. Just think about your description before you upload.

major.minor.bugfix.build#, it's an industry standard. There are various ways to use the build number. Some just increase it with each full build they do (Windows), some just use the revision number (centralized version control like SVN), some the revision's ID (distributed version control like Git), I even know one project which uses the days since the company was founded.

CortUI currently uses manually incremented build numbers (which always requires an extra commit, and attention), but I should switch to just using the reposition revision, which has the added bonus that it makes it dead easy to restore an old state of the mod just from the version number.

Spinoza wrote:QUOTE (Spinoza @ Jul 21 2010, 01:49 AM) Add a tag system.
It doesn't have to be functional right away, just put it in there for the future and decide on just a few basic tags so authors can be ready.

Now that idea I like.

I also like the tag idea, I will see about implementing it in the next version.

As for the other idea... that's probably not going to happen, sorry. The description is baked into the mod file, I'm not going to separate them, so you'll have to upload a new version. New versions update messages are not presented as popup alerts or anything anyway.

Cort wrote:QUOTE (Cort @ Jul 21 2010, 04:03 AM) Strongly against. No two releases should ever have the same version number, that's just asking for pain. Support request: "Well, are you using the version 1.2.3 I uploaded before Friday or the one I uploaded afterwards?" A description change is a change like any other, treat it as such. Just think about your description before you upload.

I see your point, but I'm talking about a totally different thing (at least that's the way I see it).
I see the description as a web page, plain and simple.
Just like Mesial had web pages on his website...
Mesial's page shows my prox mine upside down. If he fixes it, should he increase the version number?

That's why I said separate. Every release should must have it's own number, but not everything has to be "baked in" to the release... people should not be downloading the description.
Anyhow, Orion calls the shots, whatever he likes...


I suppose I could cheat by putting a frame or some other HTML thingie inside the description, pointing somewhere else... muahahaha!
In a way, I already did, by linking to an image.

PS
I'm not trying to be argumentative, just explaining myself.