Haha, torque just began complaining at me too, Fatal-ISV: (..\engine\gui\core\guiCanvas.cc @ 201) CreateCanvas: canvas has already been instantiated is the error in a little pop up window.

Edit: it has something to do with loading a .zip in the mods system. I've been playing with it, execing two files in the zip. This shouldn't give me trouble, should it? I am going to try loading everything in the file with wildcards, and see what happens. I am also trying to get the starts of a system where people can put info like their name, the version number and a description in there as well.

Finally, two things: one. What does the fixer mod do?
two. how in gods name does this work with the zip and executing things inside it and whatnot!? I am going to give up and release the changes I made to the svn, and then try this bullshit with the mod system again.
CyberPrime wrote:
Haha, torque just began complaining at me too, Fatal-ISV: (..\engine\gui\core\guiCanvas.cc @ 201) CreateCanvas: canvas has already been instantiated is the error in a little pop up window.

Edit: it has something to do with loading a .zip in the mods system. I've been playing with it, execing two files in the zip. This shouldn't give me trouble, should it?

That means your mod being loaded is calling CreateCanvas unnecessarily. as a rule, mod's shouldn't use that function.

Quote:
I am also trying to get the starts of a system where people can put info like their name, the version number and a description in there as well.

This is good, I'd like to see what you have.

Quote:
Finally, two things: one. What does the fixer mod do?

Is forartists.txt still hanging around in the svn? Basically, it's for fixing terrain texture paths for use with TBG.

Quote:
two. how in gods name does this work with the zip and executing things inside it and whatnot!? I am going to give up and release the changes I made to the svn, and then try this bullshit with the mod system again.

The ModLoaderGui can be used to select which mods should be automatically loaded at startup (or you can use the -mod command line option, or edit modload.dyn by hand).
elfprince13 wrote:

That means your mod being loaded is calling CreateCanvas unnecessarily. as a rule, mod's shouldn't use that function.


I figured as much, but I can't find that anywhere in the mod. I didn't make many changes.

Edit: I figured it out, it happens when I exec another file from within the zipped mod. Why the hell does that happen?

elfprince13 wrote:

This is good, I'd like to see what you have.


Not much at all, it's just with some predefined prefs in a cs file. The only problem is I can't exec other files from within the zip, so it's a little tricky. I was also trying to get a script to echo those prefs with something like "echo($mod:: @ %modname @ ::author);" but I can't figure out how to embed a variable in a pref and echo it. the %modname variable is already defined within the package as the correct variable, but I just can't figure out how to embed it like that. From there it would be a simple matter to make a properties window that contains the info in text boxes.

elfprince13 wrote:

Is forartists.txt still hanging around in the svn? Basically, it's for fixing terrain texture paths for use with TBG.


I see, I figured it was something like that. And yes, it's still in the SVN. Is that something that will be folded into the game or will we leave it as a mod? Perhaps we can leave it as a mod just for testing purposes.

elfprince13 wrote:

The ModLoaderGui can be used to select which mods should be automatically loaded at startup (or you can use the -mod command line option, or edit modload.dyn by hand).


I got that much, but I mean how does it deal with the zip compression as I think that's the root of my exec problems.


As well, what's going on with querying the master server? I know you disabled the button and commented out the joinserver.query(); function, but I uncommented it and it seems like you did something with the querymasterserver(); function, or maybe I am completely wrong and it's just some little bug. Actually, come to look at it it seems that there just aren't any servers. Either way we should really get a dedi up just to be able to bug test.
CyberPrime wrote:
I figured it out, it happens when I exec another file from within the zipped mod. Why the hell does that happen?

Because the file you exec() is calling CreateCanvas Wink

CyberPrime wrote:
Not much at all, it's just with some predefined prefs in a cs file. The only problem is I can't exec other files from within the zip, so it's a little tricky. I was also trying to get a script to echo those prefs with something like "echo($mod:: @ %modname @ ::author);" but I can't figure out how to embed a variable in a pref and echo it. the %modname variable is already defined within the package as the correct variable, but I just can't figure out how to embed it like that. From there it would be a simple matter to make a properties window that contains the info in text boxes.

I'd recommend just having a file with a set name in the zip and use getRecord() to access it and parse values by hand.

CyberPrime wrote:
Perhaps we can leave it as a mod just for testing purposes.

Keep it as a mod. It's only necessary for map artists, not for core functionality.

CyberPrime wrote:

I got that much, but I mean how does it deal with the zip compression as I think that's the root of my exec problems.

The engine treats .zip files almost exactly like a normal directory. It's transparent, and as been built in for a long time.


CyberPrime wrote:

As well, what's going on with querying the master server? I know you disabled the button and commented out the joinserver.query(); function, but I uncommented it and it seems like you did something with the querymasterserver(); function, or maybe I am completely wrong and it's just some little bug. Actually, come to look at it it seems that there just aren't any servers. Either way we should really get a dedi up just to be able to bug test.


my guess is there just aren't any servers. A dedi would definitely be a good idea in the very near future. My plan is to use Cemetech to replace the Torque master server stuff, and I have a lot of that ready, but we should have a fallback to GG master servers for when Cemetech is down.
[quote="elfprince13"]
CyberPrime wrote:

Because the file you exec() is calling CreateCanvas Wink

It seems to have been a typo. I'm an idiot.

elfprince13 wrote:

I'd recommend just having a file with a set name in the zip and use getRecord() to access it and parse values by hand.


I tried reading up on getRecord(), but the documentation I am seeing is less than good, and the usage of it in the scripts are not helpful at all. How would it help parse a file for prefs? And how do I use it?

elfprince13 wrote:

Keep it as a mod. It's only necessary for map artists, not for core functionality.

Sounds good.

CyberPrime wrote:

The engine treats .zip files almost exactly like a normal directory. It's transparent, and as been built in for a long time.

Interesting. I never knew about that. Could come in handy.


elfprince13 wrote:

my guess is there just aren't any servers. A dedi would definitely be a good idea in the very near future. My plan is to use Cemetech to replace the Torque master server stuff, and I have a lot of that ready, but we should have a fallback to GG master servers for when Cemetech is down.

Interesting. I would like to see the program that will do that, as I have been interested in making a private master server for some time now.
CyberPrime wrote:

I tried reading up on getRecord(), but the documentation I am seeing is less than good, and the usage of it in the scripts are not helpful at all. How would it help parse a file for prefs? And how do I use it?

Get yourself a copy of "TorqueScript Quick References.pdf"

The [action]Record(s) and [action]Field(s) functions let you retrieve data from a string. Records are newline separated, and Fields are tab or newline separated. A mod info file could be set up as follows:

Code:

AUTHOR   CyberPrime
MODNAME   ToothyGrin
VERSION   42.1337
SUMMARY   blahblahblah


CyberPrime wrote:
Interesting. I never knew about that. Could come in handy.

That's why it's so handy for self-contained mods. Add in a little activatepackage-magic, and some package-stack monitoring, and we're all set for starters. I'd like to add some form of dependency checking though.

CyberPrime wrote:

Interesting. I would like to see the program that will do that, as I have been interested in making a private master server for some time now.

It doesn't actually use the Torque Master Server protocol, but stores all the relevant information and is accessible via http. There are also actual Master Server implementations in Perl and Python as resource on GG.
elfprince13 wrote:

Get yourself a copy of "TorqueScript Quick References.pdf"

Could have sworn I had that. The TDN requires a login. Mind sending it to me?

elfprince13 wrote:
The [action]Record(s) and [action]Field(s) functions let you retrieve data from a string. Records are newline separated, and Fields are tab or newline separated. A mod info file could be set up as follows:

Code:

AUTHOR   CyberPrime
MODNAME   ToothyGrin
VERSION   42.1337
SUMMARY   blahblahblah

I see, I was just curious about the actual use of the getrecord() function, and it's calls. The documentation says getRecord( sourceString , index ) but the sourceString and index are confusing me. Anyway, I am sure I could figure it out.

elfprince13 wrote:

That's why it's so handy for self-contained mods. Add in a little activatepackage-magic, and some package-stack monitoring, and we're all set for starters. I'd like to add some form of dependency checking though.
Sounds good. I agree that we should use dependency checking, but hopefully people won't need too many. Perhaps we should implement something like a debian package management system, with a simple gui that you can use to find mods.

elfprince13 wrote:
It doesn't actually use the Torque Master Server protocol, but stores all the relevant information and is accessible via http. There are also actual Master Server implementations in Perl and Python as resource on GG.

Figures that everything would be on the TGN, to which I have no access. A system built with HTTP in mind from the ground up sounds great. When we get the Cemetech server up we can just have the function that executes when it sees the server is down change the master to the torque master. Perhaps we should broadcast the serverlist to both servers? I dunno.

Can you apply a torque license to more than one user? It would be nice to have access to the private forums.
CyberPrime wrote:
Mind sending it to me?

Not at all. What's your email?

CyberPrime wrote:
I see, I was just curious about the actual use of the getrecord() function, and it's calls. The documentation says getRecord( sourceString , index ) but the sourceString and index are confusing me. Anyway, I am sure I could figure it out.


Code:
getRecord(%filecontents, 0)
would return
Quote:
AUTHOR CyberPrime
if %filecontents contained the example I gave above.
calling

Code:
removeField(getRecord(%filecontents, 0), 0)
would return everything on the AUTHOR line except AUTHOR itself.

CyberPrime wrote:
Sounds good. I agree that we should use dependency checking, but hopefully people won't need too many. Perhaps we should implement something like a debian package management system, with a simple gui that you can use to find mods.

That's the eventual goal, though NOT something we need for the first release.


CyberPrime wrote:
Figures that everything would be on the TDN

It's not. Torque resources are publicly available.


CyberPrime wrote:
A system built with HTTP in mind from the ground up sounds great. When we get the Cemetech server up we can just have the function that executes when it sees the server is down change the master to the torque master. Perhaps we should broadcast the serverlist to both servers? I dunno.

The Cemetech side of things is already up, though I need to write a couple functions to keep the database table trimmed. I just need to write the client functions to access it. TGE automagically broadcasts itself to the GG master server, so all we have to do is check error codes from the libcurl integration and fallback to a normal master server check.

CyberPrime wrote:
Can you apply a torque license to more than one user? It would be nice to have access to the private forums.


The private forums actually just got unprivated to everyone a couple months ago.
elfprince13 wrote:

Not at all. What's your email?

cyberprime108@gmail.com

elfprince13 wrote:


Code:
getRecord(%filecontents, 0)
would return
Quote:
AUTHOR CyberPrime
if %filecontents contained the example I gave above.
calling

Code:
removeField(getRecord(%filecontents, 0), 0)
would return everything on the AUTHOR line except AUTHOR itself.


elfprince13 wrote:

That's the eventual goal, though NOT something we need for the first release.

Indeed, I don't really see people taking advantage of most of these things until some time in the future

elfprince13 wrote:

The Cemetech side of things is already up, though I need to write a couple functions to keep the database table trimmed. I just need to write the client functions to access it. TGE automagically broadcasts itself to the GG master server, so all we have to do is check error codes from the libcurl integration and fallback to a normal master server check.

Very cool.

elfprince13 wrote:
The private forums actually just got unprivated to everyone a couple months ago.

Thank god, I can't tell you how much that has pissed me off.

We also need to decide on some gui standards; how are the buttons going to look etc, but that's most a primary thing.

We should also think about people, and the openness of the project. In all honesty I think the bazaar style is better, and most open source writers would agree. Either way, we really need more people working on stuff, even if it's just coming up with ideas or working out little bugs.
CyberPrime wrote:
elfprince13 wrote:

Not at all. What's your email?

cyberprime108@gmail.com

Aight, you should have it Smile

CyberPrime wrote:

Indeed, I don't really see people taking advantage of most of these things until some time in the future

My guess is the ToB crowd will jump on it as soon as it's available.

CyberPrime wrote:
We also need to decide on some gui standards; how are the buttons going to look etc, but that's most a primary thing.

I actually need to finish reimplementing the guibitmapborderbuttons and then we have a profile for those that fits rather well with everything else.

CyberPrime wrote:
We should also think about people, and the openness of the project. In all honesty I think the bazaar style is better, and most open source writers would agree. Either way, we really need more people working on stuff, even if it's just coming up with ideas or working out little bugs.

Honestly.....eh, I've voiced my thoughts on this before, and the issue I have with going bazaar is that
a) (I'll be honest here) I'm a bit of a quality control freak. I like to make sure that what's going in the SVN is good quality code. With the project open to ANY contributions that's basically unfeasible for me to keep an eye on.
b) I'm happy to approve any number of coders to work with the SVN as long as they express interest with me, and give me an idea of their talents beforehand. It's not that I want to discourage the community from being involved, but lets be honest ^_^ The average age of the players is probably under 14, with a solid majority in the 8-13 range, with a few oldish Lego fanatics like myself hanging around. I really do want to encourage young coders to learn (which is one of the best arguments for making it open source....tweaking around with the code is a GREAT way to learn), but an overenthusiastic (and inexperienced) twelve year old with SVN access isn't necessarily a good thing. Having been programming at that age I know that I certainly would have, no matter how good I was compared to others that age. Again, this isn't to say that NO young 'uns will be able to contribute, but I'd like to have an idea of what each person is capable of before they get to commit things that I might have to clean up, and coach them/give them advice on what needs to be improved if they're not quite ready.
elfprince13 wrote:

Aight, you should have it Smile

Got it. Thanks.

elfprince13 wrote:

My guess is the ToB crowd will jump on it as soon as it's available.

No no, I am referring to the info section of the addons.

elfprince13 wrote:

I actually need to finish reimplementing the guibitmapborderbuttons and then we have a profile for those that fits rather well with everything else.

What do you mean, reimplementing? They look like they work to me. And thank god we have profiles for those, I really can hardly take the grey boxes for much longer. They complement the window border I assume? (Speaking of which, we have to do something about the close/minimize/maximize buttons on the borders, the bottom 1/4 doesn't click. I assume this has something to do with the numbers that define the size of the top border, but this is probably an engine thing.)

elfprince13 wrote:

Honestly.....eh, I've voiced my thoughts on this before, and the issue I have with going bazaar is that
a) (I'll be honest here) I'm a bit of a quality control freak. I like to make sure that what's going in the SVN is good quality code. With the project open to ANY contributions that's basically unfeasible for me to keep an eye on.
b) I'm happy to approve any number of coders to work with the SVN as long as they express interest with me, and give me an idea of their talents beforehand. It's not that I want to discourage the community from being involved, but lets be honest ^_^ The average age of the players is probably under 14, with a solid majority in the 8-13 range, with a few oldish Lego fanatics like myself hanging around. I really do want to encourage young coders to learn (which is one of the best arguments for making it open source....tweaking around with the code is a GREAT way to learn), but an overenthusiastic (and inexperienced) twelve year old with SVN access isn't necessarily a good thing. Having been programming at that age I know that I certainly would have, no matter how good I was compared to others that age. Again, this isn't to say that NO young 'uns will be able to contribute, but I'd like to have an idea of what each person is capable of before they get to commit things that I might have to clean up, and coach them/give them advice on what needs to be improved if they're not quite ready.

I think I've found the communication issue; I am not suggesting we open up the SVN. Dear god no. I suggest we set up a dedicated forums somewhere, with sections and whatnot where people can come, and look at things we have up which need coding. They can code the things, and post them back into the thread. We will take whoever's snippit is best and implement it. If they code nicely consistently then we could look at them to be invited into the dev team and give them SVN access.

Another major thing I suggest is that we release something, anything, and release it soon. People are loosing faith and patience, and I think it's only fair to give them something. We could wait until we get curl implemented or something, but it's high time we do something. It could help work out bugs and whatnot, which I really think we need.


Oh, on an unrelated note; I think we need to do something different with the mod gui. Checkboxes may not work as far as being able to click on the mod to get more info, or highlight it to open a properties window.
CyberPrime wrote:

No no, I am referring to the info section of the addons.

ohh, I aight, I thought you meant the dependency checking.

CyberPrime wrote:

What do you mean, reimplementing? They look like they work to me. And thank god we have profiles for those, I really can hardly take the grey boxes for much longer. They complement the window border I assume?

Yes. And they work because I just copied the button class and added the necessary extra data fields, I just haven't done the necessary GUI rendering adjustments to use those extra data fields. See if you can dig up some screenshots from the original TBG alpha's. The buttons were really sweet, and we lost those when we started over with the new engine stuff because we lost the engine changes Gobbles had made.

CyberPrime wrote:
(Speaking of which, we have to do something about the close/minimize/maximize buttons on the borders, the bottom 1/4 doesn't click. I assume this has something to do with the numbers that define the size of the top border, but this is probably an engine thing.)
hmmm, I'd check the profiles that are buried in one of the core/common subdirectories iirc. That would be a great thing for you to work on at some point.
CyberPrime wrote:

I think I've found the communication issue; I am not suggesting we open up the SVN. Dear god no. I suggest we set up a dedicated forums somewhere, with sections and whatnot where people can come, and look at things we have up which need coding. They can code the things, and post them back into the thread. We will take whoever's snippit is best and implement it. If they code nicely consistently then we could look at them to be invited into the dev team and give them SVN access.

Ahh, that's still Cathedral development with patch submissions Wink And it's basically what I've been saying would be good all along. I'd like to keep the forum here since many of the community features (and the master server) will be tied into it, but I'll talk to Kerm about giving us a full category and not just a single subforum.

CyberPrime wrote:
Another major thing I suggest is that we release something, anything, and release it soon. People are loosing faith and patience, and I think it's only fair to give them something. We could wait until we get curl implemented or something, but it's high time we do something. It could help work out bugs and whatnot, which I really think we need.

Big things to get working before a release:
Cemetech/fallback master server switching + SAX integration which will take some PHP + C++ coding on my part.
Fix up the GUIs.
Get the modloading + GameMode framework's basically in place. This is something you could do if you were feeling ambitious. It'll take some wackyhax with the package stack.


CyberPrime wrote:
Oh, on an unrelated note; I think we need to do something different with the mod gui. Checkboxes may not work as far as being able to click on the mod to get more info, or highlight it to open a properties window.

If you feel comfortable doing so, do as you see fit in terms of polishing that, and loading name/author/version/info.
[quote="elfprince13"]
CyberPrime wrote:

No no, I am referring to the info section of the addons.

ohh, I aight, I thought you meant the dependency checking.

elfprince13 wrote:

Yes. And they work because I just copied the button class and added the necessary extra data fields, I just haven't done the necessary GUI rendering adjustments to use those extra data fields. See if you can dig up some screenshots from the original TBG alpha's. The buttons were really sweet, and we lost those when we started over with the new engine stuff because we lost the engine changes Gobbles had made.

I see. I actually have the old TBG alpha, 0003. I did love those buttons. Sounds good, I will start changing the buttons I see.

elfprince13 wrote:
hmmm, I'd check the profiles that are buried in one of the core/common subdirectories iirc. That would be a great thing for you to work on at some point.

Ok, I will dig around.

CyberPrime wrote:

Ahh, that's still Cathedral development with patch submissions Wink And it's basically what I've been saying would be good all along. I'd like to keep the forum here since many of the community features (and the master server) will be tied into it, but I'll talk to Kerm about giving us a full category and not just a single subforum.

I see. And I agree that with all the infrastructure in place here already it might be silly to change now.

elfprince13 wrote:

Big things to get working before a release:
Cemetech/fallback master server switching + SAX integration which will take some PHP + C++ coding on my part.
Fix up the GUIs.
Get the modloading + GameMode framework's basically in place. This is something you could do if you were feeling ambitious. It'll take some wackyhax with the package stack.

Alright, I will add these to the checklist file, and get working on stuff. What exactly did you have in mind as far as the gamemode framework?

elfprince13 wrote:

If you feel comfortable doing so, do as you see fit in terms of polishing that, and loading name/author/version/info.

Alright, I will think about how to setup the gui. I have the getrecord and whatnot setup, and the properties gui is there and it's all ready to go, I just have no way to know which mod you wanna know about as it is. As well, I eliminated some sloppy gui stuff on the mod gui where it looked like somebody was trying to hardcode the fixer checkbox into the gui. Anyway, now the gui actually dynamically loads the zip files that are in the folder.
CyberPrime wrote:
I see. I actually have the old TBG alpha, 0003. I did love those buttons. Sounds good, I will start changing the buttons I see.

The buttons are actually all using the that class, I just haven't modified the engine to support the rendering that needs to happen to display them properly. It's hopefully a 10 minute job though.

CyberPrime wrote:

I see. And I agree that with all the infrastructure in place here already it might be silly to change now.

Ok, good, I think we're on the same page then Smile

CyberPrime wrote:
Alright, I will add these to the checklist file, and get working on stuff. What exactly did you have in mind as far as the gamemode framework?

A hook system through which mod-ders could override/extend core engine functions to add rule checking behavior and stuff like that for CTF, Racing, Building contests, whatever, in a self-contained way. The TGE activate/deactivate package functions and Parent::blah() is perfect for this, and I've defined some skeleton functions to control loading a game mode (which should be based on a drop down menu in the start server + admin GUIs), but I'm pretty sure they don't do anything more (at this point) then set the text information which the engine sends to Cemetech about which type of game is running, and we need to develop a package-naming convention by which we can do this conveniently, some initialization + deinitialization functions which developers can hook into (should they be so inclined), and change the code to actually load the packages.

CyberPrime wrote:

Alright, I will think about how to setup the gui. I have the getrecord and whatnot setup, and the properties gui is there and it's all ready to go, I just have no way to know which mod you wanna know about as it is. As well, I eliminated some sloppy gui stuff on the mod gui where it looked like somebody was trying to hardcode the fixer checkbox into the gui. Anyway, now the gui actually dynamically loads the zip files that are in the folder.

O_o I don't remember doing that. Oh well, good catch. I thought it was dynamically loading already, but it's been a while since I looked at that code, so I'm happy to hear you improved on it.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 2 of 2
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement