Server Help

ASSS Questions - Asss 1.5.0
Dr Brain - Wed May 20, 2009 10:33 pm
Post subject: Asss 1.5.0
As some of you already know, I'm taking over the maintenance and development of ASSS from Grelminar. I've been working on a new asss version for a while, but due to other obligations I was forced to put it on hold until now.

If you have any changes you'd like to see made to the core, post them here. I will only be integrating changes to the core to facilitate the addition of features by other modules, or to add features usable by the majority of zones. In other words, I'm not going to write you an elim module. On the other hand, if you have a core change needed to make *your* elim module work then that should be posted here.
Cheese - Wed May 20, 2009 11:39 pm
Post subject:
Dr Brain wrote:

Cheese wrote:

why does as3 have ?flagreset and not ?ballreset?

Because no one bothered to write one.

Cheese wrote:

why does it seem that arena->playing and arena->total give the same number, even while 2 are in ships and 1 in spec?

Because playing doesn't mean what one might think. If I recall correctly, playing in this context means game clients capable of entering the game. I think chatnet clients and fake players don't count toward that number.


Cheese wrote:

also, looking through the src, i cant seem to find how asss handles setting doors...
aka, it doesnt use cfg DoorMode, theres no game->door(250);, etc
or did i miss something...?


also, this: http://forums.minegoboom.com/viewtopic.php?t=8383
Hakaku - Thu May 21, 2009 12:15 am
Post subject:
Well assuming you haven't already implemented these changes, I'd like to see the following:

- The SHIPCHANGE and FREQCHANGE callbacks should return the player's previous ship/freq rather than their current ship/freq. (or both)

- Periodic points should not send the periodic reward packet to the player/frequency if the reward returns 0. (here)

- Antiwarp should be automatically disabled while a player is in safe (here)

- Add Snrrrub's patches (e.g. sendto)

- Ball game win callback (like this)

- A better way to be able to add stuff to the client settings list (i.e. esc+c).

- add ?packetloss, ?laghist

- Imo, remove the "-f" from setship and setfreq commands (i.e. don't respect freqmanager by default).

- Disallow jackpot from being negative using the ?setjackpot command.

- Make zone recycling (?shutdown -r) a separate command (if you accidentally typo, then you've just killed the whole zone)

- Make the arena numbering thing an option (I'd like to be able to use arenas appended with numbers, that aren't necessarily related. i.e. arena2 is [optionally] unrelated to arena)

- Fix the default directory servers so that only "sscentral.sscuservers.net" and "ssdir.playsubspace.com" appear (all others are dead)

I would also like to see a lot of messages cleaned up, especially in playercmd.c (Words without proper capitalization irks me just as much as you dislike ppl writing as3)

Cheating-wise, I would suggest that the server keep track of player's timer drift (and spec them). Higher than 25 or lower than -25 (in *einfo) is an indicator that a player is either of three: 1) cheating, 2) lagging too horribly to play anyways, 3) in an odd time zone (which shouldn't happen)
Dr Brain - Thu May 21, 2009 6:58 am
Post subject:
I'm not going to implement the ballreset thing because I don't work with powerball games enough to do it correctly. If someone familiar with the internals of the powerball games wants to write a patch, I'd be happy to integrate it.

I may add an arena->spectating variable in a later release. I may find that it's not be feasible to track this. It's on my list at least, though.

Doors can already be set with either a cfg change or a clientset override.

Hakaku wrote:
- The SHIPCHANGE and FREQCHANGE callbacks should return the player's previous ship/freq rather than their current ship/freq. (or both)


I'm rewriting the freqman from the ground up, and I'll make sure the callbacks make sense.

Hakaku wrote:
- Periodic points should not send the periodic reward packet to the player/frequency if the reward returns 0. (here)


I'll look into this.

Hakaku wrote:
- Antiwarp should be automatically disabled while a player is in safe (here)


I'm not going to make any changes that could affect current zone's gameplay. However, with my position packet callbacks one could make a new module to do this in about 10 minutes.

Hakaku wrote:
- Add Snrrrub's patches (e.g. sendto)


I added his first four. I haven't added his newer stuff. I'm still trying to get in contact with him about it.

Hakaku wrote:
- Ball game win callback (like this)


As I said to cheese, I'm not familiar enough with the powerball game to make this change. If someone wants to submit a patch, I'd be happy to integrate it into the core.

Hakaku wrote:
- A better way to be able to add stuff to the client settings list (i.e. esc+c).


Not sure what you mean here.

Hakaku wrote:
- add ?packetloss, ?laghist


I'm going to delay rewriting the lag module for a future release.

Hakaku wrote:
- Imo, remove the "-f" from setship and setfreq commands (i.e. don't respect freqmanager by default).


I think they should go through the freqman by default.

Hakaku wrote:
- Disallow jackpot from being negative using the ?setjackpot command.


Will do.

Hakaku wrote:
- Make zone recycling (?shutdown -r) a separate command (if you accidentally typo, then you've just killed the whole zone)


There used to be a ?recycle, but I don't know what happened to it. I'll look into it.

Hakaku wrote:
- Make the arena numbering thing an option (I'd like to be able to use arenas appended with numbers, that aren't necessarily related. i.e. arena2 is [optionally] unrelated to arena)


Might be difficult, but I'll look into it.

Hakaku wrote:
- Fix the default directory servers so that only "sscentral.sscuservers.net" and "ssdir.playsubspace.com" appear (all others are dead)


Good idea.

Hakaku wrote:
I would also like to see a lot of messages cleaned up, especially in playercmd.c (Words without proper capitalization irks me just as much as you dislike ppl writing as3)


If you make a list then I'll fix them all. I can give it a go myself if you don't have time.

Hakaku wrote:
Cheating-wise, I would suggest that the server keep track of player's timer drift (and spec them). Higher than 25 or lower than -25 (in *einfo) is an indicator that a player is either of three: 1) cheating, 2) lagging too horribly to play anyways, 3) in an odd time zone (which shouldn't happen)


This falls into the domain of a new lag module, which I'm going to delay until a future release.
Dr Brain - Thu May 21, 2009 7:04 am
Post subject:
Changes I've already integrated:



Things I'm still working on:


These are not exhaustive lists, but they give the major highlights.
Samapico - Thu May 21, 2009 10:52 am
Post subject:
The ?lag info has improper capitalization (no capitalization at all, actually)
same for ?jackpot
Initrd.gz - Thu May 21, 2009 5:01 pm
Post subject:
Perhaps a FOR_EACH_PLAYER_IN_ARENA macro?

Thanks for continuing ASSS! icon_smile.gif
Samapico - Thu May 21, 2009 5:57 pm
Post subject:
Cheese, in the topic he linked to wrote:
if i recall, mervbot provided BOTH.
Merv gives you the old ship/freq, and you have direct access to the new value with p->ship or p->freq (or p->team... forgot)
Hakaku - Thu May 21, 2009 6:29 pm
Post subject:
Dr Brain wrote:
Not sure what you mean here.

As it is, it's not exactly possible to add custom settings within the in-game command list (server.set I think?). In other words, rather than having to retrieve the file (e.g. arena.conf), modify it, then place it back all the time (whether in-game or via ftp), it is quite a hassle for something that could take a few seconds if it were recognized as a valid setting for esc+c/getsettings/quickfix.

Basically, what I'd like to eventually see is a more dynamic approach for being able to customize the settings list provided in-game, rather than having as an only option to modify clientset.c/def.

Dr Brain wrote:
I think they should go through the freqman by default.

Any specific reason for requiring them in the freqman? I would assume moderators responsible enough to know what frequency to place a player on, or what ship to put a player in; but it's honestly really redundant if they can use the '-f' feature anyways. The other advantage is that it provides backwards-compatibility for all bots/plugins (think of people who don't know how to modify bot plugins).

If you really aren't going to change it, I would say at least change it so that it detects if the player using the command is a bot or not.

Dr Brain wrote:
If you make a list then I'll fix them all. I can give it a go myself if you don't have time.

I made a lot of changes for Deva, most of them involve simple capitalization at the start of sentences, and for titles such as "arena owner" is capitalized as "Arena Owner". I also rendered a few of them more subgame-like, so that ?jackpot doesn't return "jackpot: 0", but "Current Jackpot: 0". I don't care if you don't make it subgame-ish, but at least capitalize some of it all.

Also, the ?uptime command should check if the words need to be pluralized (so that it doesn't say "uptime: 1 days 1 hours 1 minutes...") Oh, and the default ?lag command is ugly :/

-------
And just random notes:

As MTN pointed out to me, billing-wise it's possible for ASSS to rewrite the commands locally so that they're never sent to the biller. This poses a problem since not only can you disable biller commands, but you can easily eaves drop onto what biller operators are doing.

The way scores are stored in ASSS seems to be flawed, I've seen users have their scores reset for basically no reason whatsoever. And it's definitely not ?scorereset (nor biller score resets) as this happens to myself as well, and also seems to happen if you use a chat client to enter the zone. I haven't really had time to look at how scores work, but I suspect somewhere ASSS is resetting the score when a player logs in.

In regards to ?obscene, it would be nice if you could censor a single word, not every single occurence of that string. That is, if I add "nig" to the obscene list, I don't want "night" to be censored as well. Perhaps make it more like:
apple <- Only the word apple is censored
apple* <- The word apple, along with any word starting with apple is censored.
*apple <- The word apple, along with any word ending with apple is censored.
app*le <- All words starting with app-, and ending with -le are censored.
etc.
JoWie - Thu May 21, 2009 7:20 pm
Post subject:
Some things of the top of my head and some things I encountered while doing a project a year ago. Some of these might not be applicable anymore.

Dr Brain - Thu May 21, 2009 7:51 pm
Post subject:
Initrd.gz wrote:
Perhaps a FOR_EACH_PLAYER_IN_ARENA macro?


I'll add one, since it's not hard and will be useful.

Hakaku wrote:
As it is, it's not exactly possible to add custom settings within the in-game command list (server.set I think?). In other words, rather than having to retrieve the file (e.g. arena.conf), modify it, then place it back all the time (whether in-game or via ftp), it is quite a hassle for something that could take a few seconds if it were recognized as a valid setting for esc+c/getsettings/quickfix.

Basically, what I'd like to eventually see is a more dynamic approach for being able to customize the settings list provided in-game, rather than having as an only option to modify clientset.c/def.


Grel left me some notes on possible approaches for this, but they're all beyond the scope of what I want to do with the first few releases.

Hakaku wrote:
Any specific reason for requiring them in the freqman? I would assume moderators responsible enough to know what frequency to place a player on, or what ship to put a player in; but it's honestly really redundant if they can use the '-f' feature anyways. The other advantage is that it provides backwards-compatibility for all bots/plugins (think of people who don't know how to modify bot plugins).


It's more for safety than anything. I think mods typically use it to even teams, rather than to break team/ship limits.

Hakaku wrote:
If you really aren't going to change it, I would say at least change it so that it detects if the player using the command is a bot or not.


Just because I'm not going to change the default behavior doesn't mean I can't add a global.conf option to -f by default. If you think it's useful to your zone, then I'll add it. I just won't change the default behavior for other zones. I can add a config option for bots too, if desired.

Hakaku wrote:
I made a lot of changes for Deva, most of them involve simple capitalization at the start of sentences, and for titles such as "arena owner" is capitalized as "Arena Owner". I also rendered a few of them more subgame-like, so that ?jackpot doesn't return "jackpot: 0", but "Current Jackpot: 0". I don't care if you don't make it subgame-ish, but at least capitalize some of it all.


I'll go through the core and change everything I see. Let me know if there's anything I miss after 1.5.0 is released in a couple of weeks.

Hakaku wrote:
Also, the ?uptime command should check if the words need to be pluralized (so that it doesn't say "uptime: 1 days 1 hours 1 minutes...") Oh, and the default ?lag command is ugly :/


I'll fix ?uptime. I'm happy to take suggestions for a new ?lag output, but won't have time to come up with one myself for this release.

Hakaku wrote:
As MTN pointed out to me, billing-wise it's possible for ASSS to rewrite the commands locally so that they're never sent to the biller. This poses a problem since not only can you disable biller commands, but you can easily eaves drop onto what biller operators are doing.


There's nothing that can be done about this. The protocol is inherently insecure. A malicious zone could easily record the login information and execute arbitrary billing commands as the operator (which is much worse than simply logging the commands an operator executes). The moral of the story is don't enter your BanG information in strange zones.

Hakaku wrote:
The way scores are stored in ASSS seems to be flawed, I've seen users have their scores reset for basically no reason whatsoever. And it's definitely not ?scorereset (nor biller score resets) as this happens to myself as well, and also seems to happen if you use a chat client to enter the zone. I haven't really had time to look at how scores work, but I suspect somewhere ASSS is resetting the score when a player logs in.


I don't know much about scoring, but if you can give me more details and a use case that resets a player's score, I'll be happy to debug it and fix it.

Hakaku wrote:
In regards to ?obscene, it would be nice if you could censor a single word, not every single occurence of that string. That is, if I add "nig" to the obscene list, I don't want "night" to be censored as well. Perhaps make it more like:
apple <- Only the word apple is censored
apple* <- The word apple, along with any word starting with apple is censored.
*apple <- The word apple, along with any word ending with apple is censored.
app*le <- All words starting with app-, and ending with -le are censored.
etc.


Cerium wrote an obscene module for hyperspace that matched using regular expressions. I may have the opportunity to update the core's obscene module for a later release.

JoWie wrote:
A constant for that fuschia color of yours


I'll add it, but with a note saying that non-continuum clients will likely not support it.

JoWie wrote:
Last time I used ASSS the object module was buggy with a lot of objects (~800). Players entering would simply not get the updated position states (on/off states were fine if I recall correctly, which is a different packet)


The object module is a scary, confusing place. I don't know that I'm up to debugging it without further details, such as backtraces, or known problem conditions.

JoWie wrote:
Smongs objects module patch. I can't find a link but i have it laying around somewhere. This was from 2006 tho, it probably is already in the core


If this is the one I'm thinking of, then it was already merged.

JoWie wrote:
Better documentation on locking & threading in ASSS.


Documentation is the bane of every developer's existence. If someone volunteers to write this kind of thing, then I'll make sure that it gets put into the core's doc folder.

JoWie wrote:
points_goal: Setting to disable the soccer game. In other words, you score, you get points, nothing more, no game.


Powerball changes are out of the scope for the next release.

JoWie wrote:
Perhaps a Callback / Interface so that something like smong's fm_shiplimits doesnt have to replace the normal freq manager. http://www.toktok.sscentral.com/ss-asss.html


Already part of the new freqman rewrite.
Hakaku - Thu May 21, 2009 8:33 pm
Post subject:
Thanks for taking the time to reply to it all, I just wanted to throw that all out so that even if it's not added in the upcoming release(s), at least it's documented. I'm quite happy to see progress being made though.

I'll see if I can get more info on the scoring issue to narrow it down.
Quote:
points_goal: Setting to disable the soccer game. In other words, you score, you get points, nothing more, no game.

You can already do this using the [soccer] settings...
L.C. - Thu May 21, 2009 11:36 pm
Post subject:
Quote:
Quote:
I don't care if you don't make it subgame-ish, but at least capitalize some of it all.
I'll go through the core and change everything I see. Let me know if there's anything I miss after 1.5.0 is released in a couple of weeks.
Would it be possible to create some sort of "Sentences" file? I wouldn't mind trying to rewrite/grammar-fix/clone Subgame's messages. I think if AS3 looked like Subgame but with more features, more flexibility, etc, that would be awesome, great, and a better newb-attractor for creation.

Would it also be possible to finish the Subgame/old-commands module so that AS3 would even behave like Subgame except with more features and flexibility?

What about releasing a simple stripped down version of AS3 that is as close to Subgame as possible to allow people to configure AS3, add maps, arenas, staff, arena settings, defualt level, lvz, anything else I can't think of that you can do with Subgame straight off, and perhaps some abilities like peering?

Donno, don't care. It'd make it easier for newbs like me to switch over to AS3 (the least thing is that we newbies would be using AS3 as a core over the outdated Subgame, right?).

I think there should be AS3 (the way it is now and the way you want it to be for developers; advanced/programmers/developers) and a simple/Subgame-clone version (beginners/newbies). Perhaps there could be a way where you could easily do this so you don't have to maintain two copies of the same AS3?

Congratulations by the way for taking development over AS3. biggrin.gif


EDIT :: By the way, awesome to see that you've/you're also implementing Snrrrub's AS3 fixes and stuff too. :]
Samapico - Thu May 21, 2009 11:47 pm
Post subject:
The default configuration of ASSS should be this simple subgame-like version... Having 2 different versions would be way too complicated.
But someone who grabs ASSS package should get some kind of default setup, with all the subgame-equivalent modules loaded, and a couple of simple useful modules, and some placeholders for things like staff, arenas and whatnot.
Some people seem to have in mind that ASSS is for advanced users and they just have to configure it themselves, but if we want ASSS to completely overtake subgame, it needs to come ready-to-use with at least the same features as subgame.
Hakaku - Fri May 22, 2009 12:07 am
Post subject:
L.C. wrote:
it be possible to create some sort of "Sentences" file? I wouldn't mind trying to rewrite/grammar-fix/clone Subgame's messages.

Although I don't see this happening anytime soon, this type of format could be very useful if ever the game became multilingual. Not only could you change the server's default language, but you could actually have players choose their language of preference when playing. It would be really nifty if the client supported unicode as well, and sent the player's language preference to the server. Unfortunately though, the only client that natively supports UTF-8 is Starlight, while Continuum supports a few additional characters in-game only, and Discretion is basically ascii. We've had and still have players from various corners of the Earth, even so much as had Japanese websites that were dedicated to SubSpace/Continuum, but the game is basically limited to those who understand English, meaning that there still remains an untapped market of potential players. (wishful thinking of course)

Without the language factor, there's not a huge need to place all the messages in a single file, it would just be a greater hassle than it's worth.
JoWie - Fri May 22, 2009 2:20 am
Post subject:
Quote:

Hakaku wrote:
Any specific reason for requiring them in the freqman? I would assume moderators responsible enough to know what frequency to place a player on, or what ship to put a player in; but it's honestly really redundant if they can use the '-f' feature anyways. The other advantage is that it provides backwards-compatibility for all bots/plugins (think of people who don't know how to modify bot plugins).


It's more for safety than anything. I think mods typically use it to even teams, rather than to break team/ship limits.

Hakaku wrote:
If you really aren't going to change it, I would say at least change it so that it detects if the player using the command is a bot or not.


Just because I'm not going to change the default behavior doesn't mean I can't add a global.conf option to -f by default. If you think it's useful to your zone, then I'll add it. I just won't change the default behavior for other zones. I can add a config option for bots too, if desired.


You could add a simple capability which gives you -f by default. This would seem the fastest implementation.

Quote:

JoWie wrote:
Last time I used ASSS the object module was buggy with a lot of objects (~800). Players entering would simply not get the updated position states (on/off states were fine if I recall correctly, which is a different packet)


The object module is a scary, confusing place. I don't know that I'm up to debugging it without further details, such as backtraces, or known problem conditions.


I have tried debugging it a year ago. But I couldn't figure it out and made workarounds by triggering an object move for the player everytime he entered.
It also happened very randomly. Sometimes it would run for days without any problem, other times it required a server restart every couple of hours.
More players made it occur more tho. Kind of like that "lag coma" bug ASSS had years ago.

Quote:

JoWie wrote:
Smongs objects module patch. I can't find a link but i have it laying around somewhere. This was from 2006 tho, it probably is already in the core


If this is the one I'm thinking of, then it was already merged.

It's the one where the unmodified module verifies changes by matching to the "default" instead of the "current"
D1st0rt - Fri May 22, 2009 4:01 am
Post subject:
I personally think it is a bad idea to put unnecessary constraints on ASSS just because that is "how people are used to doing it". Yes there are some inconsistencies in the command formats but as a whole it is vastly superior to subgame. Development efforts would be better spent ensuring conformity throughout than making fabricating some extra layer so you can pretend the server is something it's not. All that is doing is delaying the inevitable though, because sooner or later you are going to have to learn how it works if you want to run your zone successfully. It is not as simple as Subgame by design, which is something you need to come to terms with.

Administration of ASSS is really not hard if you just read through the user guide. Also, if you have specific questions you can read through the source if you know how, or you can ask someone who does. Subgame does not offer that capability! Also the notion that you can have an ASSS zone without some kind of development support staff is dangerous at best. It's like having a race car with no mechanics, not a situation you really want to be in.

Bottom line, if you took the time to learn subgame, you can take the (less) time required to learn ASSS. You can even change it if you want! (additional assembly required)
Doc Flabby - Fri May 22, 2009 5:20 am
Post subject:
Hakaku wrote:
[..] Unfortunately though, the only client that natively supports UTF-8 is Starlight,

STF also supports unicode, unfortunalty ASSS and subgame doesn't, if you tried to use the full range of unicode in either it would cause problems.
Initrd.gz - Sat May 23, 2009 6:15 pm
Post subject:
Could you make more modules python compatible? (ex. clientset)
Cheese - Sun May 24, 2009 12:44 am
Post subject:
i would rather have the python modules made into c modules, especially the core ones, like the flag game modules
Grelminar - Sun May 24, 2009 5:27 am
Post subject:
I'd like to suggest using the new bug tracker to keep track of these issues. Just file all the bugs and requests that you have, and then dr brain and others can mark them as targeted to 1.5.0 or later versions. Of course, if you're not really sure if the request makes sense, feel free to discuss it here first.

http://bitbucket.org/grelminar/asss/issues/

Also, if there are bugs on the old bug tracker that are still valid, feel free to copy them over to the new one. (I'm going to take down the old one eventually.)

Finally, if you're actively working on stuff, make an account on bitbucket and send a message to dr brain or me so we can add you to the project.
Initrd.gz - Sun May 24, 2009 8:01 pm
Post subject:
Cheese wrote:
i would rather have the python modules made into c modules, especially the core ones, like the flag game modules

I meant for non core modules. Or did you misinterpret my message?
What I mean is that you can't currently, but would like to do this in python:
Code: Show/Hide
clientset = get_interface(I_CLIENTSET)
Goldeye - Mon May 25, 2009 7:01 am
Post subject:
Hakaku wrote:
As it is, it's not exactly possible to add custom settings within the in-game command list (server.set I think?). In other words, rather than having to retrieve the file (e.g. arena.conf), modify it, then place it back all the time (whether in-game or via ftp), it is quite a hassle for something that could take a few seconds if it were recognized as a valid setting for esc+c/getsettings/quickfix.


This is already possible using cfghelp comments in your files. Check the core modules for examples. However, to include these new settings, you need to rebuild cfghelp.inc, which unfortunately does not rebuild automatically. To do so, you can just remove build/cfghelp.inc and then build again.

This isn't quite dynamic, but its far easier than adding to clientset.

Initrd.gz wrote:
Could you make more modules python compatible? (ex. clientset)

Sometimes this is as easy as adding pyint comments to the interface definition. At a glance at clientset, nothing there should cause any trouble; see other core headers for some examples (eg config) of how to do it.

Brain, if you keep a todo list online I'd be inclined to chip away at it now and then. Ballreset sounds like something I might be able to do sometime soon.
Initrd.gz - Mon May 25, 2009 10:14 pm
Post subject:
Goldeye wrote:
Sometimes this is as easy as adding pyint comments to the interface definition.
Yes, but so is adding "#include <limits.h>" or whatever it is in that one module.
L.C. - Mon May 25, 2009 10:20 pm
Post subject:
Any news/updates/status information about 1.5.0 Dr Brain? biggrin.gif I am eager for its release.
Goldeye - Tue May 26, 2009 1:36 am
Post subject:
Initrd.gz wrote:
[..]

Yes, but so is adding "#include <limits.h>" or whatever it is in that one module.


I don't quite follow. What do you mean?
Dr Brain - Tue May 26, 2009 6:37 am
Post subject:
There's a bug on some systems that can be fixed by adding a missing limits.h to (I think) admincmd.c. I integrated that change already.

As for release date, I'm hoping to get everything on my list polished off in the next couple of weeks, and release 1.5.0rc1. If that goes smoothly, I'll release 1.5.0 shortly thereafter.
Initrd.gz - Tue May 26, 2009 6:49 pm
Post subject:
Goldeye wrote:
[..]



I don't quite follow. What do you mean?
I mean, it would be easier if it was already implemented. It would also imply that it would work.
Goldeye - Wed May 27, 2009 3:58 am
Post subject:
Hold up; what's "it"?
If "it" is pyint declarations; I doubt most of the people who work with C give a damn about or notice all the py hooks. They write their .h and don't worry about python compatibility. So sure, it would be nice if it was already done; but it's something that the person who wants to utilize it knows more about than the person who originally made it.
Bak - Sun May 31, 2009 3:57 pm
Post subject:
include/player.h

IS_STANDARD is a macro defined in include/player.h as "#define IS_STANDARD(p) ((p)->type == T_CONT || (p)->type == T_VIE)"

this isn't explandable to new clients. an easy solution is just to add T_DISC to the client types enum and change the #define to "#define IS_STANDARD(p) ((p)->type == T_CONT || (p)->type == T_VIE || (p)->type == T_DISC)"

----------------------
include/game.h

There are no callbacks to tell when weapons are being fired. I took these callbacks from hz, I believe they allow weapons packet modification in-flight (for example in public in hz you don't receive weapons packets from other players if you've been killed twice in a row, thus preventing spawnkilling):

/** called when a weapon is fired */
#define CB_WEAPON "hz-weapon-0"
/** the type of CB_WEAPON
* @param a arena of the weapon
* @param p player of the weapon
* @param wpn the packet with the weapon that was fired
*/
typedef void (*WeaponFunc)(Arena *a, Player *p, struct C2SPosition *wpn);
/* pyfcb: arena, player, weapons */

/** called to check if a specific player is to receiving a weapon packet*/
#define CB_WEAPON_PLAYER "hz-weapon-player-0"
/** the type of CB_WEAPON_PLAYER
* @param a arena of the weapon
* @param p player to receive the weapon
* @param s player sending the weapon
* @param wpn the packet with the weapon that was fired
*/
typedef void (*WeaponPlayerFunc)(Arena *a, Player* p, Player *s, struct C2SPosition *wpn);
/* pfycb: arena, player, player, weapons */

--------------------
packets/login.h

prevent pragma leeching by adding

#pragma pack(push, disc_login_h, 1)
#pragma pack(1)

to the start of the file and

#pragma pack(pop, disc_login_h)

at the end of the file

also defined

#define LEN_LOGINPACKET_DISC (sizeof(struct LoginPacket) - 64)

(this probably should be generalized with a callback, though)

-------------------
core/arenaman.c

standard clients are assumed a common settings format. this limits clients to a settings format that's 11 years old. right now, on line 288 in SendArenaResponse, arenaman.c acquires the clientsetting interface just in order to send the settings and immediately release it. This should be changed to a callback so that other client types can send a different settings format

--------------
core/core.c

around line 480 should be generalized to a callback, alternatively use this code,

#ifdef CFG_RELAX_LENGTH_CHECKS
else if ( (p->type == T_VIE && l < LEN_LOGINPACKET_VIE) ||
(p->type == T_CONT && l < LEN_LOGINPACKET_CONT) ||
(p->type == T_DISC && l < LEN_LOGINPACKET_DISC))
#else
else if ( (p->type == T_VIE && l != LEN_LOGINPACKET_VIE) ||
(p->type == T_CONT && l != LEN_LOGINPACKET_CONT) ||
(p->type == T_DISC && l != LEN_LOGINPACKET_DISC))
#endif

and then around line 570

if (p->type == T_VIE)
snprintf(p->clientname, sizeof(p->clientname),
"<ss/vie client, v. %d>", pkt->cversion);
else if (p->type == T_CONT)
snprintf(p->clientname, sizeof(p->clientname),
"<continuum, v. %d>", pkt->cversion);
else if (p->type == T_DISC)
snprintf(p->clientname, sizeof(p->clientname),
"<discretion, v. %d>", pkt->cversion);

---------------------
core/fm_normal.c

line 253, "if (s >= SHIP_SPEC)" should be changed to "if (s == SHIP_SPEC)", otherwise everyone is limited to 8 ships. in discretion spec is ship 8, and 9 and up are valid playable ships. This sort of sucks, but the alternative is a massive rehaul of asss not to mention poorly-coded custom modules.

-------------------------------------

core/game.c

Added the interruptable callback macro where, depending on a parameter the callback can stop; this one is from hz, also pretty useful for getting feedback from callbacks. For example, when iterating through weapons, if a callback disables the weapon, there is no need to continue iterating (in fact modules may be confused as to why they get a weapons callback when weapon has been reset to be not a weapon)

#define DO_I_CBS(cb, arena, type, args, interrupt) \
do { \
LinkedList _a_lst; \
Link *_a_l; \
mm->LookupCallback(cb, arena, &_a_lst); \
for (_a_l = LLGetHead(&_a_lst); _a_l; _a_l = _a_l->next) \
{ \
((type)_a_l->data) args ; \
if (interrupt) break; \
} \
mm->FreeLookupResult(&_a_lst); \
} while (0)


added a function to get the maximum number of ships, which is hardcoded in a few places (as you'll see later)

// the maximum ship index allowed by a given client in a given arena
local int getMaxShipIndex(Player* p, Arena* a)
{
int rv = SHIP_SPEC;

if (p->type == T_DISC)
{
// discretion may have more or less than 8 ships!
rv = cfg->GetInt(a->cfg, "Discretion", "NumShips", SHIP_SPEC);
}

return rv;
}

around line 343, added the implementation of the weapon callback, also used in hz

...
if (pos->status & STATUS_FLASH)
{
sendtoall = TRUE;
nflags = NET_RELIABLE;
}

if (pos->weapon.type)
{
DO_I_CBS(CB_WEAPON, p->arena, WeaponFunc, (p->arena, p, pos), !pos->weapon.type);

if (!pos->weapon.type)
sendwpn = FALSE;
/* if the bounty is over 255 */
if (pos->bounty & 0xFF00)
sendwpn = TRUE;
/* if the pid is over 255 */
if (p->pid & 0xFF00)
sendwpn = TRUE;
}

if (sendwpn)
...

changed the conditional at 344 to implement the weaponplayer callback (also used in hz)


if (sendwpn)
{
int range = wpnrange[pos->weapon.type];
struct S2CWeapons wpn = {
S2C_WEAPON, pos->rotation, gtc & 0xFFFF, pos->x, pos->yspeed,
p->pid, pos->xspeed, 0, pos->status, (u8)latency,
pos->y, pos->bounty
};
struct S2CWeapons copywpn;
wpn.weapon = pos->weapon;
wpn.extra = pos->extra;
/* move this field from the main packet to the extra data,
* in case they don't match. */
wpn.extra.energy = pos->energy;
copywpn = wpn;

do_checksum(&wpn);

pd->Lock();
FOR_EACH_PLAYER_P(i, idata, pdkey)
if (i->status == S_PLAYING &&
IS_STANDARD(i) &&
i->arena == arena &&
(i != p || p->flags.see_own_posn))
{
long dist = lhypot(x1 - idata->pos.x, y1 - idata->pos.y);

if (
dist <= range ||
sendtoall ||
/* send it always to specers */
idata->speccing == p ||
/* send it always to turreters */
i->p_attached == p->pid ||
/* and send some radar packets */
( wpn.weapon.type == W_NULL &&
dist <= cfg_pospix &&
randnum > ((double)dist / (double)cfg_pospix *
(RAND_MAX+1.0))) ||
/* bots */
i->flags.see_all_posn)
{
const int plainlen = sizeof(struct S2CWeapons) - sizeof(struct ExtraPosData);
const int nrglen = plainlen + 2;
const int epdlen = sizeof(struct S2CWeapons);

wpn = copywpn;
DO_CBS(CB_WEAPON_PLAYER, p->arena, WeaponPlayerFunc,
(p->arena, i, p, pos));

if (wpn.weapon.type)
idata->wpnsent++;

if (i->p_ship == SHIP_SPEC)
{
if (idata->pl_epd.seeepd && idata->speccing == p)
{
if (len >= 32)
net->SendToOne(i, (byte*)&wpn, epdlen, nflags);
else
net->SendToOne(i, (byte*)&wpn, nrglen, nflags);
}
else if (idata->pl_epd.seenrgspec == SEE_ALL ||
(idata->pl_epd.seenrgspec == SEE_TEAM &&
p->p_freq == i->p_freq) ||
(idata->pl_epd.seenrgspec == SEE_SPEC &&
data->speccing == p))
net->SendToOne(i, (byte*)&wpn, nrglen, nflags);
else
net->SendToOne(i, (byte*)&wpn, plainlen, nflags);
}
else if (idata->pl_epd.seenrg == SEE_ALL ||
(idata->pl_epd.seenrg == SEE_TEAM &&
p->p_freq == i->p_freq))
net->SendToOne(i, (byte*)&wpn, nrglen, nflags);
else
net->SendToOne(i, (byte*)&wpn, plainlen, nflags);
}
}
pd->Unlock();
}

changed line 766 from "if (freq < 0 || freq > 9999 || ship < 0 || ship > SHIP_SPEC)" to "if (freq < 0 || freq > 9999 || ship < 0 || ship > getMaxShipIndex(p, p->arena))"

changed line 830 from "if (ship < SHIP_WARBIRD || ship > SHIP_SPEC)" to "if (ship < SHIP_WARBIRD || ship >getMaxShipIndex(p, p->arena))"

-------------------------
core/net.c

changed #define IS_OURS(p) to include T_DISC

added "int allowdisc" to struct ListenData

near line 816 added

/* cfghelp: Listen:AllowDisc, global, bool, def: 1
* Whether Discretion clients are allowed to connect to this
* port. */
ld->allowdisc = cfg->GetInt(GLOBAL, secname, "AllowDisc", 0);


near line 1843

/* certain ports might allow only one or another client */
if ((type == T_VIE && !ld->allowvie) ||
(type == T_CONT && !ld->allowcont) ||
(type == T_DISC && !ld->allowdisc))
return NULL;


near line 1887

if (type == T_VIE)
astrncpy(p->clientname, "<ss/vie client>", sizeof(p->clientname));
else if (type == T_CONT)
astrncpy(p->clientname, "<continuum>", sizeof(p->clientname));
else if (type == T_DISC)
astrncpy(p->clientname, "<discretion>", sizeof(p->clientname));
else
astrncpy(p->clientname, "<unknown game client>", sizeof(p->clientname));

---------------------------------------

thanks brain! Let me know if there's any trouble!
Doc Flabby - Sun May 31, 2009 4:54 pm
Post subject:
This is kinda oftopic, but i've managed to compile ASSS in Visual Studio, you need to download all the dependancies and play with the pre-build events but it does work. Unfortunately its loses all the external modules, and security.so is compiled with the gcc version of pthreads so it won't work, but it might be useful information for someone...Not sure if visual studio support is something we want to add for v1.5 (its a horrible mess how i got it to compile) but it is possible.
Samapico - Sun May 31, 2009 6:00 pm
Post subject:
Uh... what do you use to compile it normally?
JoWie - Sat Jun 20, 2009 5:44 am
Post subject:
in the Pppk function in game.c you find the following :

Code: Show/Hide

void Pppk(Player *p, byte *pkt, int len)
{
...
   if (pos->x == -1 && pos->y == -1)
   {
      /* position sent after death, before respawn. these aren't
       * really useful for anything except making sure the server
       * knows the client hasn't dropped, so just ignore them. */
      return;
   }
...
}


Could this be stored in the player object so we can easily find out if the player is waiting for respawn. Right now I have to guess using Kill:EnterDelay and the kill callback.

Something like:

Code: Show/Hide

void Pppk(Player *p, byte *pkt, int len)
{
...
   if (pos->x == -1 && pos->y == -1)
   {
      p->flags.waiting_for_respawn = 1;
      return;
   }
   else
   {
      p->flags.waiting_for_respawn = 0;
   }
...
}
Dr Brain - Sat Jun 20, 2009 8:22 am
Post subject:
That's a good idea. I've added a bug entry for it here: http://bitbucket.org/grelminar/asss/issue/26/

For those of you playing along at home, I've added bug entries for the majority of things I plan on doing, but I'm still missing some. I've also started the process of moving bugs over from the old Mantis bug database.
Dr Brain - Sat Jun 20, 2009 10:50 am
Post subject:
Bug DB update: I've finished porting bugs from the old Mantis tracker. I added a note to everything I ported in the old tracker, so it should be easy to see the things that I didn't move. Anything that was not moved I do not personally plan on fixing (python and soccer things, mostly). If you see an old bug that you'd still like fixed, feel free to move the bug to the new tracker, or discuss it here.

I still have some bugs from my todo-list to port. I think the only bugs from this thread that aren't in there are:

Though neither of these two are planned for 1.5.0rc1. If a bug you mentioned on this list isn't in the bug tracker, let me know.
Samapico - Sun Jun 21, 2009 4:35 pm
Post subject:
How about this:

2 new region data chunks, for LVZ's to toggle when entering / exiting a region.

These chunks can have a variable size... so you could set it to toggle a bunch of different objects at once. Positive values for objon's and negative values for objoff's, kind of like *objset. So you could have 1000, 1001, -2000,-2001
when entering the region, and -1000, -1001, 2000, 2001 when exiting it, for example.

I propose rLVI and rLVO for EnterRegion (in) and ExitRegion (out)

bytes
0-3: "rLVI" or "rLVO"
4-7: uint32: size of data (in bytes; must be multiple of 4)
Next 4xN bytes: objects to toggle in signed int32 format

Where N = size of data / 4

Note that objectID only uses 15bits in the LVZ format standard... so we could use int16's too... However, the chunk would have to be a multiple of 4 bytes anyway to follow the LVZ format. Wouldn't be much more complicated for me to use 2 bytes per object. What you think?

Quicklinks for reference:
http://wiki.minegoboom.com/index.php/LVZ_Format
http://wiki.minegoboom.com/index.php/ELVL_Format
Dr Brain - Sun Jun 21, 2009 9:38 pm
Post subject:
Talking with Arnk gave me some ideas about regions: what might be better would be a way to easily add arbitrary data to regions. Tags, for lack of a better term. These might best be represented as strings.

So, for example, you could add a tag "LVZ in" with data "+10,-20,+23" to a region. Then a module could parse the data in the tag to mean turn on objects 10 and 23, and turn off object 20. This is a lot more flexible, and would allow non-core modules to more tightly integrate with maps.

I don't want to add any core modules that I don't have to add. I'd rather add enough functionality to the core so that any module could easily do what needs to be done. The nice thing about the tag solution is that it allows a lot of uses beyond simple lvz toggling. What do you think, Samapico? Would something like this be enough?
Samapico - Sun Jun 21, 2009 11:16 pm
Post subject:
True, but LVZ toggling could be worthy to be in the core imo tongue.gif
We could have a standard module to handle it, though

I should be able to make it easy to add various tags to the regions (or the the map itself), with different data types (string, bytes, longs...)

With custom tags, the homemade modules should make sure to validate the data within the chunk, cause different people could create a tag with the same name as someone else, but with different formats.

I'm talking more about custom "chunks", actually... but a simple rATT chunk for attributes, like map attributes, could be made standard. Just like in the map ATTR chunk, you have one chunk per tag you want to add.

Also, not all the regions in the same map will necessarily have the same tags...
Arnk Kilo Dylie - Mon Jun 22, 2009 1:50 am
Post subject:
obviously to make the most use of the tags system, a mapdata function to determine all of the tags of all of the regions the player is in would be necessary. certain things like the "no flags" and "no antiwarp" switches are examples of existing hardcoded tags. one should be able to say "is a player in any region with tag x" or "get me a list of region tags that apply to player x" or "get me the subdatas associated with tag x applying to a player
JoWie - Mon Jun 22, 2009 4:04 pm
Post subject:
Speaking of regions.

in the Imapdata interface you have the function
Code: Show/Hide

int (*Contains)(Region *rgn, int x, int y);


a simple

Code: Show/Hide

int (*ContainsPlayer)(Region *rgn, Player *p);
// map->Contains(region, p->position.x >> 4, p->position.y >> 4)


could be useful
Mine GO BOOM - Mon Jun 22, 2009 7:06 pm
Post subject:
JoWie wrote:
Speaking of regions.

in the Imapdata interface you have the function ... a simple ... could be useful

Ships can have difference sizes, so if this is implemented, need to account if you want just the center of the ship, or any part of the ship, or the whole ship contained in a region.
JoWie - Wed Jun 24, 2009 9:53 am
Post subject:
its seems that net->GetClientStat crashes for Chatnet clients

backtrace of smong's nomysql module, which crashes with chatnet clients:
Code: Show/Hide

Thread 1 (Thread 0xb7d496b0 (LWP 29174)):
#0  0xb7dde9c1 in waitpid () from /lib/libc.so.6
No symbol table info available.
#1  0xb7d81b7b in ?? () from /lib/libc.so.6
No symbol table info available.
#2  0xb7d81f22 in system () from /lib/libc.so.6
No symbol table info available.
#3  0xb7ed182d in system () from /lib/libpthread.so.0
No symbol table info available.
#4  0x0809bc9c in handle_sigsegv (sig=11) at core/unixsignal.c:93
   cmd = "/bin/sh bin/backtrace bin/asss 29174", '\0' <repeats 91 times>
#5  <signal handler called>
No symbol table info available.
#6  0x0806c9e1 in GetInfo (bw=0x0, buf=0xbf8b9fa2 "", buflen=32)
    at core/bw_default.c:127
No locals.
#7  0x080601ca in GetClientStats (p=0xb2d015c0, stats=0xbf8b9f6c)
    at core/net.c:2648
   conn = (ConnData *) 0xb2d01844
#8  0xb3a905d6 in appendInfo (p=0xb2d015c0) at cnc/nomysql.c:84
   f = (FILE *) 0xb2d028f8
   fname = 0x80c9be3 "visitors.txt"
   type = 0xb7db6851 "\201ã?\f"
   fullpath = "data/visitors.txt\000??\004\a???(???\213?\234z??\037\205?Qd\002\n\b\000\000\000"
   s = {s2cn = 0, c2sn = 0, pktsent = 0, pktrecvd = 0, bytesent = 0,
  byterecvd = 0, pktdropped = 0, unused1 = 0, encname = 0x809dee3 "none",
  ipaddr = "0.0.0.0\000\000\000\000\000\000\000\000", port = 0,
  bwlimitinfo = '\0' <repeats 31 times>,
  reserved = "\000\000\004\000\000\000\004\000\000\000WIsy?(?\000\000\000\000:seesysoplogall\000?????\213?\b\000\000\000\030?\213?\206\205?\020\000?\b\000\000\000\020\000???????\v\b?\213???\004\bH?\213?!?\004\b?(?\000\000\000\000\b\000\000\000\020\000?\034\000\000\000\020\000?X?\213???\v\b?(???\v\bX?\213?i?\004\b\b\000\000\000???x?\213?!?\004\b\001\000\000\000?q\000\000?(BJ"}
#9  0xb3a90b07 in PlayerAction (p=0xb2d015c0, action=0, arena=0x0)
    at cnc/nomysql.c:209
No locals.
#10 0x08057abd in process_player_states (v=0x0) at core/core.c:342
   _a_lst = {start = 0xb2d01548, end = 0xb2d028a8}
   _a_l = (Link *) 0xb2d028a8
   player = (Player *) 0xb2d015c0
   d = (pdata *) 0xb2d01a04
   oldstatus = 6
   ns = 7
   oldstatus = 6
   requested_ship = 135225440
   player = (Player *) 0xb2d015c0
   link = (Link *) 0xb2d004d8
   actions = {start = 0xb2d004d8, end = 0xb2d004d8}
#11 0x0805a0dc in RunLoop () at core/mainloop.c:63
   ret = 1
   td = (TimerData *) 0x80dacc8
   l = (Link *) 0x80dace8
   gtc = 30929204
#12 0x0804cf9c in main (argc=1, argv=0xbf8ba254) at main/main.c:293
   code = -1081368120
#0  0xb7dde9c1 in waitpid () from /lib/libc.so.6
The program is running.  Quit anyway (and detach it)? (y or n) [answered Y; input not from terminal]


note the bw=0x0 part, this is the cause of the segfault

EDIT: shouldn't the code tag auto hide?
Initrd.gz - Wed Jun 24, 2009 7:34 pm
Post subject:
BTW, how are you going to add support for security.so?
Bak - Thu Jun 25, 2009 2:50 am
Post subject:
Initrd.gz wrote:
BTW, how are you going to add support for security.so?


I don't think they're making changes to the security module. In either case, I'm pretty sure grel has the source.
Dr Brain - Thu Jun 25, 2009 7:12 am
Post subject:
I had to change some of the things in security.so to get it to work for 64-bit already, so recompiling it isn't an issue.
Hakaku - Mon Jun 29, 2009 5:53 pm
Post subject:
Here's a vaguely related question, but does the CMD_MULTI_CHAR (aka |) actually work? From my understanding, it's suppose to allow multiple commands to be used in a single line (e.g. /?setship 3|?setfreq 1), or am I using it wrong? If it's right, then could this be added into the fix list?

On another note, would it be possible to clean up the groupdef directory? There are some commands that don't exist (?myscore), while a few others are missing (e.g. in sgcompat, ?owner). And if I may also propose an additional group for bots, with at least "unlimitedchat" and "broadcastbot" in them? It would be useful for beginners who wouldn't know to add those features because their bot is getting silenced or can't perform certain object changes.
Dr Brain - Mon Jun 29, 2009 10:52 pm
Post subject:
It was changed at some point to need to start with either /?| or /|?, I forget which, since I rarely use that functionality.

About the groupdefs, yes they should be cleaned, but it only does limited good because of the fact that they don't get changed during the upgrade process.
Hakaku - Mon Jun 29, 2009 11:20 pm
Post subject:
Dr Brain wrote:
It was changed at some point to need to start with either /?| or /|?, I forget which, since I rarely use that functionality.

Oh thanks, the first one is the correct one (/?|lag|setship...).
JoWie - Wed Jul 08, 2009 9:12 am
Post subject: Clientset
There is a bug in the security / clientset module with overrides.

If you override something and decide to wait a little while to send the settings packet, (because we already sent one 0.1 second ago). The security module keeps warning about settings checksum mismatches because we haven't sent the packet yet.

One solution would be to store what setting packet was last sent for every player.

If your interested, I have attached the modified clientset module we use (changed from asss 1.4.4). Which contains some 2 other minor changes which I needed for our custom settings system.
MikeTheNose - Sat Jul 25, 2009 4:39 pm
Post subject:
Hakaku wrote:
As MTN pointed out to me, billing-wise it's possible for ASSS to rewrite the commands locally so that they're never sent to the biller. This poses a problem since not only can you disable biller commands, but you can easily eaves drop onto what biller operators are doing.


Issue is resolved.
D1st0rt - Sat Jul 25, 2009 5:36 pm
Post subject:
MikeTheNose wrote:
[..]



Issue is resolved.


Really? I'm curious as to how you accomplished that from a technical standpoint.
Hakaku - Sat Jul 25, 2009 8:49 pm
Post subject:
He's referring to another issue, i.e. the reason why I brought that up was because I had originally aliased all of Deva's bot commands with their ASSS counterparts, to make commands more familiar to older staff. Not having billing access, I never knew that some of these commands were used by the biller, so by aliasing them, I essentially blocked them from being sent to the biller. MTN helped me resolve the blocked commands, but I was curious as to why ASSS stops these commands from being logged (cmdman.c), but doesn't stop them from being used by another module, or at least still forward them to the biller rather than blocking them entirely at the zone level.

I realize the issue with this is that it creates a biller-dependancy and is best avoided, but not everyone has knowledge of the main SSC biller itself, which we've already become dependant on.
Dr Brain - Sun Jul 26, 2009 6:02 pm
Post subject:
For the curious, commands can be routed directly to the biller using ?\command, such as ?\login.
phong - Mon Aug 10, 2009 9:07 am
Post subject:
How's it coming on 1.5 brain? Any estimated release dates? (Winter 09') icon_smile.gif
Dr Brain - Mon Aug 10, 2009 10:25 am
Post subject:
The list of bugs remaining for 1.5.0 is here.

There are 11 bugs on that list as I write this, but only #10 and #52 need significant amounts of code.

As for a release date, I expected to have this done a month ago, so clearly my estimates aren't worth much. We have come a long way though: Closed Bugs
phong - Mon Aug 10, 2009 1:37 pm
Post subject:
Thanks
JoWie - Mon Aug 17, 2009 9:44 am
Post subject:
would it be possible to add a capability or modify "bypasssecurity" in the security module so that any warnings about exe / map / setting checksum mismatches are not logged? (Unless I am missing some existing setting)

All the red warnings about subchat are getting a bit annoying
Hakaku - Fri Aug 21, 2009 5:55 pm
Post subject:
Another small request, would it be possible to add both the name of the user who was banned, along with the name of the user who performed ?kick in ?listmidbans ? Just seeing a macid along with the time left doesn't tell me much.
Cheese - Tue Sep 22, 2009 11:20 am
Post subject:
would it be possible to use the util.c file as a shim for functions?

like every time the core is recompiled, adding the current functions in util.c into the core, so that the file doesnt need to be manually added to every project?
Dr Brain - Tue Sep 22, 2009 2:31 pm
Post subject:
It's only on windows that they have to be manually added. They're not part of Linux modules, since it can take the function bodies from the loaded asss core.
Bak - Tue Sep 22, 2009 5:04 pm
Post subject:
Cheese wrote:
would it be possible to use the util.c file as a shim for functions?

like every time the core is recompiled, adding the current functions in util.c into the core, so that the file doesnt need to be manually added to every project?


Make a Util module with an interface, then you can just use that.
Anonymous - Tue Oct 06, 2009 1:08 pm
Post subject:
Argh, come on, I see only two errors left!
Anonymous - Tue Oct 06, 2009 1:38 pm
Post subject:
Well, crap, I didn't log in so I can't edit my post. Anyway. While I'm here, I might as well ask a couple questions.

Back when I was actually trying to program modules there were a couple things that would have been a MAJOR convenience to me. While neither of them are strictly necessary, they'd certainly go a long way towards making modules easier to write.

First off, I don't think there's a way to pause for a variable amount of time. I remember trying to write an event manager similar to the popular MERV event plugin, or Smong's python event module. Anyway, I'd need to take a vote, which means waiting for some set amount of time for players to actually vote. I believe I had to set a timer, break my current function, and have the timer call a new function to continue my code. Now, what I was hoping for was some function or macro to call that would just... wait. Some kind of delay function. Only I don't actually know if it's possible to have one module delay without tying up all the other modules, without using a timer. At the very least, though, I think it could be abstracted away from the user.

The other thing I remember... I don't think there was ever a CB_SPAWN. And that would've helped a lot. I remember Bak had a work around with his initial.c, and it didn't look hard. Is there a reason no one made a CB_SPAWN? It'd have to go off whenever players entered or changed ships or respawned(Bak I believe checked every time a player moved to see when they had respawned), but it seems like it should still be part of the core.

Anyway, I'm really just wondering if those things don't exist for some specific reason, or just because no one ever made them.
Dr Brain - Tue Oct 06, 2009 1:39 pm
Post subject:
Those errors are likely fixed, but have yet to be retested.

There's a few finishing touches. The hardest part will be figuring out how to package the release. I hope to have it out to you guys in a few days if everything goes smoothly.

EDIT: you reposted right before me... To answer your questions: a delay would cause the server to die horribly. Use timers. It's the only way. CB_SPAWN has been added for 1.5.0.
Animate Dreams - Tue Oct 06, 2009 5:35 pm
Post subject:
Well, I'm happy for CB_SPAWN. As for a delay, I was thinking along the lines of a sleeping thread. If I understand what sleeping is for a thread, it lets the thread pause for either a set amount of time or until it gets awoken, without making the other threads stop. I mean I'm sure the modules aren't working like threads, but I just hate having to break my logic for a 3 second pause. I guess if it's not possible though, then whatever. Life sucks. Unless you want to rewrite the core so each module runs in its own thread. Schedule for 1.6.0?
Dr Brain - Tue Oct 06, 2009 5:59 pm
Post subject:
If you want your own thread, then feel free to make one. I'm not about to quadruple the system requirements by adding threads for each module just to cater to lazy programmers.
Doc Flabby - Tue Oct 06, 2009 6:12 pm
Post subject:
Animate Dreams wrote:
If I understand what sleeping is for a thread, it lets the thread pause for either a set amount of time or until it gets awoken

Thats a really nasty way of timing, its not accurate as sleep only specifies the minimum time the thread will be paused. Its not the solution you are looking for. As brain said, a timer with a callback function is probably a better solution.
Bak - Tue Oct 06, 2009 8:34 pm
Post subject:
the main loop interface has a settimer function
All times are -5 GMT
View topic
Powered by phpBB 2.0 .0.11 © 2001 phpBB Group