Hi

I've pushed up to github update 44 to galactic dynasty.

This rejigs ore planets and industrial planets. they are identical for
now.

This also bumps up message version to 5 which will be incompatible for
all older releases, so please DO NOT UPGRADE until Avon gives the green
light.

The reason for the message bump is I've also added some extra commands
that only node 1 can use. This is you Avon :)

./GalacticDynasty -ADD 5 "Bob's BBS"

Will add node number 5, Bob's BBS to all BBS.CFG files in the league

./GalacticDynasty -DEL 5

Will remove node number 5 from all BBS.CFG files in the league

./GalacticDynasty RESET

Will reset everyones game.

Also, as Black Panther suggested, turns per day and turns in protection
are now sent every packet, and are checked each time, if it mismatches it
will ignore the packet.

I've done a bit of testing, but I won't know for sure how this will go
until it is setup :)

Andrew

--- MagickaBBS v0.6alpha (Linux/x86_64)
* Origin: Cauldron BBS - Magicka Test BBS (21:1/125)

Will add node number 5, Bob's BBS to all BBS.CFG files in the league

...

Will remove node number 5 from all BBS.CFG files in the league

I should mention, You'll still have to manually update your own BBS.CFG
(and probably after you've sent out the command)

Andrew

--- MagickaBBS v0.6alpha (Linux/x86_64)
* Origin: Cauldron BBS - Magicka Test BBS (21:1/125)

On 03/30/17, apam said the following...

I've pushed up to github update 44 to galactic dynasty.

This also bumps up message version to 5 which will be incompatible for
all older releases, so please DO NOT UPGRADE until Avon gives the green light.

I'll wait until Avon hatches it out, and states he's got it running.

Also, as Black Panther suggested, turns per day and turns in protection are now sent every packet, and are checked each time, if it mismatches it will ignore the packet.

I hope this wasn't too difficult to implement. I figured it would only be a couple of bytes in info in the packet.

I've done a bit of testing, but I won't know for sure how this will go until it is setup :)

You know we'll put it to the test. :)


---

Dan Richter
aka Black Panther
Sysop - Castle Rock BBS
telnet://castlerockbbs.com
The sparrows are flying again...

--- Mystic BBS v1.12 A31 (Windows)
* Origin: Castle Rock BBS - telnet://castlerockbbs.com (21:1/186)

I've pushed up to github update 44 to galactic dynasty.

What are the system requirements (OS and BBS) for this new door game?

Thanks!


... Computer Hacker wanted. Must have own axe.
--- MultiMail/IBMPcDos v0.43
--- SBBSecho 2.12-Linux
* Origin: CCO BBS - capcity2.synchro.net - 1-502-875-8938 (21:1/175)

What are the system requirements (OS and BBS) for this new door game?

Should run on any BBS, binaries are provided for windows, source is
provided for linux/other unix.

Andrew

--- MagickaBBS v0.6alpha (Linux/x86_64)
* Origin: Cauldron BBS - Magicka Test BBS (21:1/125)

On 03/30/17, apam pondered and said...

I've pushed up to github update 44 to galactic dynasty.

Grabbing it now.

This rejigs ore planets and industrial planets. they are identical for now.

10-4

This also bumps up message version to 5 which will be incompatible for
all older releases, so please DO NOT UPGRADE until Avon gives the green light.

Will hatch out in next 15 mins

The reason for the message bump is I've also added some extra commands that only node 1 can use. This is you Avon :)

./GalacticDynasty -ADD 5 "Bob's BBS"

Will add node number 5, Bob's BBS to all BBS.CFG files in the league

./GalacticDynasty -DEL 5

Will remove node number 5 from all BBS.CFG files in the league

./GalacticDynasty RESET

Will reset everyones game.

Thanks :) But only if they are on build 44 right?

Also, as Black Panther suggested, turns per day and turns in protection are now sent every packet, and are checked each time, if it mismatches it will ignore the packet.

So how does this work, if I have my .ini file set to 255 turns a day and 30 turns in protection and others have different settings - how does the
checking deal with that? How does the checking know who is in synch and who
is not? Does it look to the settings in the node 1 galactic.ini file to determine if all is well?

--- Mystic BBS v1.12 A31 (Windows)
* Origin: Agency BBS | telnet://agency.bbs.geek.nz (21:1/101)

On 03/31/17, Avon said the following...

So how does this work, if I have my .ini file set to 255 turns a day and 30 turns in protection and others have different settings - how does the checking deal with that? How does the checking know who is in synch and who is not? Does it look to the settings in the node 1 galactic.ini file to determine if all is well?

It's my understanding, that all of the nodes settings need to match the coordinator system settings. If you had 255 turns per day and 30 turns of protection, any packets you received with different settings would be
rejected. I'm thinking the same would happen at the node level as well though...

I think we'll need the brains of the operation to 'splain it to us. :)


---

Dan Richter
aka Black Panther
Sysop - Castle Rock BBS
telnet://castlerockbbs.com
The sparrows are flying again...

--- Mystic BBS v1.12 A31 (Windows)
* Origin: Castle Rock BBS - telnet://castlerockbbs.com (21:1/186)

I think we'll need the brains of the operation to 'splain it to us. :)

Lol.

Basically any system with a different setting to the packet it is going
to process will ignore that packet.

So if a node has a different setting and sends it to the hub, the hub
will ignore it, if a hub has a different setting to the node, the node
will ignore it. It should effectivley lock out the node, at least until
they put there settings back to normal.

It will also log to stderr if it sees a packet with incorrect values,
so you should know if someone is mucking around.

Andrew

--- MagickaBBS v0.6alpha (Linux/x86_64)
* Origin: Cauldron BBS - Magicka Test BBS (21:1/125)

Thanks :) But only if they are on build 44 right?

Yes that's correct.

Andrew

--- MagickaBBS v0.6alpha (Linux/x86_64)
* Origin: Cauldron BBS - Magicka Test BBS (21:1/125)

On 03/31/17, Black Panther pondered and said...

It's my understanding, that all of the nodes settings need to match the coordinator system settings. If you had 255 turns per day and 30 turns of protection, any packets you received with different settings would be rejected. I'm thinking the same would happen at the node level as well though...

Yeah agreed, and if they were rejected by the HUB then does it send a message back saying so or ?

I'm trying to figure out how this will work in reality if all it takes is a node changing their .ini settings and then creating a bunch of rejected packets. I'm guessing there is some kind of feedback loop to the league coordinator and the node(s) concerned?

As an aside I'm testing some wild card stuff at the moment to see if I can
get the Mystic HUB to run processing of game packets when they land in my inbound using a semaphore style of trigger. Not sure yet if it will.

Best, Paul

--- Mystic BBS v1.12 A31 (Windows)
* Origin: Agency BBS | telnet://agency.bbs.geek.nz (21:1/101)

The 21:1/100 and 21:2/100 HUBs have now been updated to Build 44 of Galactic Dynasty and new BBS.CFG files sent to all active nodes that are involved in
the game. Please drop them in to your game directory and update your games to this version, remember to leave your current .ini file alone or face having
to set it up from scratch again.

Let me know when you're updated and I will test out the new switches andrew
has added

Best, Paul

--- Mystic BBS v1.12 A31 (Windows)
* Origin: Agency BBS | telnet://agency.bbs.geek.nz (21:1/101)

On 03/31/17, apam pondered and said...

Basically any system with a different setting to the packet it is going
to process will ignore that packet.

So if a node has a different setting and sends it to the hub, the hub
will ignore it, if a hub has a different setting to the node, the node will ignore it. It should effectivley lock out the node, at least until

This sounds like everyone need to be on the same settings else lots of
packets not accepted? But it also sounds like if a change is made at the HUB then

1. all nodes must change in order to have the HUB process their packets
2. all packets sent to the nodes after a HUB update will fail until the node updates manually to match it's settings with those changed on the HUB

Is this right?

--- Mystic BBS v1.12 A31 (Windows)
* Origin: Agency BBS | telnet://agency.bbs.geek.nz (21:1/101)

If a node has different settings to the HUB (node 1) system and then changes them during the course of a day... say has 30 turns per day set, plays 5
turns, ends the game, edits the ini, sets it to 15 turns, plays another 5 rounds and ends the games...

..assuming HUB is looking for 15 turns per day, will the first lot of packets fail but the second lot of packets be accepted - within the space of one playing day?

are changes to the .ini settings taken in to account as packets on a node are created and sent out to the HUB?

How quick can nodes adjust settings to match?

Shouldn't it really be a case of some data file being sent out by node one (like what your doing I think with the add/remove user) to ensure each node
is set to x turns per day and y rounds of protection ?

Just some random thoughts / questions.

--- Mystic BBS v1.12 A31 (Windows)
* Origin: Agency BBS | telnet://agency.bbs.geek.nz (21:1/101)

1. all nodes must change in order to have the HUB process their packets
2. all packets sent to the nodes after a HUB update will fail until the updates manually to match it's settings with those changed on the HUB

That's correct. It discards the packets so it won't leave them in your
inbox, with a message 'settings mismatch'.

I didn't anticipate you'd want to change the settings mid game, I suppose
I could have it look at who the packet was from and if it's from 1 change
it's own settings and if it's not from 1 discard.

Andrew

--- MagickaBBS v0.6alpha (Linux/x86_64)
* Origin: Cauldron BBS - Magicka Test BBS (21:1/125)

How quick can nodes adjust settings to match?

Yes, nodes could change them, play the game, change them back and run maintenance it would work.

Shouldn't it really be a case of some data file being sent out by node o (like what your doing I think with the add/remove user) to ensure each n
is set to x turns per day and y rounds of protection ?

I'm not sure how this would be any different? If node 1 sends out a
packet that says what are your settings, the node could just make sure
they have the correct settings when running maintenance.

I'm not sure there is a way to make it completley anti-cheat proof, other
than watching for odd behaviour and banning systems who are obviously
cheating. That said, I would like to think everyone here is pretty easy
going and knows it's not cool to cheat in BBS games.

Ignoring the packets with changed settings really just protects against
people who are unaware that their changes impact the game, and can be
told that they need to keep there settings the same to participate.

Andrew

--- MagickaBBS v0.6alpha (Linux/x86_64)
* Origin: Cauldron BBS - Magicka Test BBS (21:1/125)

On 03/31/17, Avon said the following...

As an aside I'm testing some wild card stuff at the moment to see if I
can get the Mystic HUB to run processing of game packets when they land
in my inbound using a semaphore style of trigger. Not sure yet if it
will.

It will. That's how I have my game server set up to run. The batch file I'm running will create a 'gamedata.now' semaphore file when it detects a file in the inbox after the mail and tic files are processed. Mystic will then pick
up on the semaphore file and run the game processing batch file.

I actually had about a two minute turnaround time when I was playing around with it in the games Bill is setting up in SportNet. Both our systems are set to crash packets, and both our systems processed the packets right away. I
had to set a delay on the game processing event...


---

Dan Richter
aka Black Panther
Sysop - Castle Rock BBS
telnet://castlerockbbs.com
The sparrows are flying again...

--- Mystic BBS v1.12 A31 (Windows)
* Origin: Castle Rock BBS - telnet://castlerockbbs.com (21:1/186)

On 03/31/17, Avon said the following...

The 21:1/100 and 21:2/100 HUBs have now been updated to Build 44 of Galactic Dynasty and new BBS.CFG files sent to all active nodes that are involved in the game. Please drop them in to your game directory and update your games to this version, remember to leave your current .ini file alone or face having to set it up from scratch again.

I'm updated here. I also reset the game, in hopes I don't break it again... :)


---

Dan Richter
aka Black Panther
Sysop - Castle Rock BBS
telnet://castlerockbbs.com
The sparrows are flying again...

--- Mystic BBS v1.12 A31 (Windows)
* Origin: Castle Rock BBS - telnet://castlerockbbs.com (21:1/186)

On 03/31/17, apam pondered and said...

1. all nodes must change in order to have the HUB process their packet 2. all packets sent to the nodes after a HUB update will fail until th updates manually to match it's settings with those changed on the HUB

That's correct. It discards the packets so it won't leave them in your inbox, with a message 'settings mismatch'.

Where do I see that message logged?

I didn't anticipate you'd want to change the settings mid game, I suppose I could have it look at who the packet was from and if it's from 1 change it's own settings and if it's not from 1 discard.

That would at least allow the HUB to ensure all nodes were in sync I think :)

Best, Paul

--- Mystic BBS v1.12 A31 (Windows)
* Origin: Agency BBS | telnet://agency.bbs.geek.nz (21:1/101)

On 03/31/17, apam pondered and said...

Shouldn't it really be a case of some data file being sent out by node (like what your doing I think with the add/remove user) to ensure each is set to x turns per day and y rounds of protection ?

I'm not sure how this would be any different? If node 1 sends out a
packet that says what are your settings, the node could just make sure they have the correct settings when running maintenance.

by manually updating to some message posted in an echo by the HUB? I'm just suggesting automating that bit. or perhaps we're misunderstanding each other
- quite possible now as I am tired as I type this.

I'm not sure there is a way to make it completley anti-cheat proof, other than watching for odd behaviour and banning systems who are obviously cheating. That said, I would like to think everyone here is pretty easy going and knows it's not cool to cheat in BBS games.

Yeah , my comments were not so much directed at trying to stop cheating as I agree all here are a good bunch etc. but rather finding ways to keep the
whole interBBS game in synch and not rely on someone who may set and walk
away to update some core settings of their version of the game. That would
mean users of the game could play it and have none of their packets sent out being accepted until a sysop acted and updated. I was just looking for a way
to ensure if Node 1 sets turns etc. then the nodes would adopt those settings when an 'update' command was sent out. sorta like a reset.. dunno.. I'm tired so will stop there as I'm getting befuddled now :)

--- Mystic BBS v1.12 A31 (Windows)
* Origin: Agency BBS | telnet://agency.bbs.geek.nz (21:1/101)

On 03/31/17, Black Panther pondered and said...

It will. That's how I have my game server set up to run. The batch file I'm running will create a 'gamedata.now' semaphore file when it detects
a file in the inbox after the mail and tic files are processed. Mystic will then pick up on the semaphore file and run the game processing
batch file.

OK so as part of your toss batch you do a if *.GAL exist then create
semaphore in dir ... or similar?

--- Mystic BBS v1.12 A31 (Windows)
* Origin: Agency BBS | telnet://agency.bbs.geek.nz (21:1/101)

On 03/31/17, Black Panther pondered and said...

I'm updated here. I also reset the game, in hopes I don't break it again... :)

I've reset also at 1/100 and 1/101

Best, Paul

--- Mystic BBS v1.12 A31 (Windows)
* Origin: Agency BBS | telnet://agency.bbs.geek.nz (21:1/101)

I'm updated here. I also reset the game, in hopes I don't break it again ... :)

Hopefully the ore changes will stop that happening, at least for a little while. At anyrate I've changed the integers to unsigned now so hopefully they'll be big enough for your scores.

If not I can change them to 64 bit integers, though I think I'd rather
work on making the game lower scoring than that.

Andrew

--- MagickaBBS v0.6alpha (Linux/x86_64)
* Origin: Cauldron BBS - Magicka Test BBS (21:1/125)

Where do I see that message logged?

It gets logged to stderr, I'm not sure how to do it on windows but I just redirect it to a log file on linux. I forgot you asked about log files,
I'll make that on the list for the next version.

That would at least allow the HUB to ensure all nodes were in sync I thi
nk :)

Ok, I'll look at doing this next time.

Andrew

--- MagickaBBS v0.6alpha (Linux/x86_64)
* Origin: Cauldron BBS - Magicka Test BBS (21:1/125)

suggesting automating that bit. or perhaps we're misunderstanding each o ther
- quite possible now as I am tired as I type this.

I think that might be the case, I misunderstood you. It's been a long day
here, was up until midnight last night working on magicka then got up at
6am to continue, I know that might be normal hours for some but for me
well lets just say I'm exhausted lol

I think I understand you know, and I'll look at adding that feature.

Andrew

--- MagickaBBS v0.6alpha (Linux/x86_64)
* Origin: Cauldron BBS - Magicka Test BBS (21:1/125)

On 03/31/17, Avon said the following...

It will. That's how I have my game server set up to run. The batch fi I'm running will create a 'gamedata.now' semaphore file when it detec a file in the inbox after the mail and tic files are processed. Mysti will then pick up on the semaphore file and run the game processing batch file.

OK so as part of your toss batch you do a if *.GAL exist then create semaphore in dir ... or similar?

Yes. The way I have it set up here looks similar to this:

This is after all message packets and tic files are processed <=-

cd \bbs\mystic\echomail\in\
if exist *.* then goto sema

:sema
cd \bbs\mystic\semaphore\
copy .>> gamedata.now

When Mystic picks up on the semaphore, it will run another batch file to run the appropriate inbound/outbound for the particular game.

:start
cd \bbs\mystic\echomail\in\
if exist *.GAL goto gdyn
if exist ln*.* goto lordnet

:gdyn
cd \bbs\doors\gdyn\
galacticdynasty maintenance
goto start

:lordnet
cd \bbs\doors\lordnet\

snip <=-

At one point, I did have this incorporated into one batch file, but as I
said, it processed too quickly. With this setup, it will leave the outbound packets in the outbound directory until my next polling event.


---

Dan Richter
aka Black Panther
Sysop - Castle Rock BBS
telnet://castlerockbbs.com
The sparrows are flying again...

--- Mystic BBS v1.12 A31 (Windows)
* Origin: Castle Rock BBS - telnet://castlerockbbs.com (21:1/186)

On 03/31/17, apam said the following...

Hopefully the ore changes will stop that happening, at least for a little while. At anyrate I've changed the integers to unsigned now so hopefully they'll be big enough for your scores.

I just hope I don't get scores like that again... :)

If not I can change them to 64 bit integers, though I think I'd rather work on making the game lower scoring than that.

I agree. Let's keep the scores lower, and see if we can make it to possibly doing some battles. :)


---

Dan Richter
aka Black Panther
Sysop - Castle Rock BBS
telnet://castlerockbbs.com
The sparrows are flying again...

--- Mystic BBS v1.12 A31 (Windows)
* Origin: Castle Rock BBS - telnet://castlerockbbs.com (21:1/186)

Avon

Let me know when you're updated and I will test out the new switches
andrew has added

I have update to 44 now, the bbs.cfg was created 31/03/2017
node 21:1/152


Ian : 2nd Choice Core NZ

--- Mystic BBS v1.12 A31 (Windows)
* Origin: 2nd Choice Core|New Zealand (21:1/152)

On 04/01/17, Sneaky pondered and said...

I have update to 44 now, the bbs.cfg was created 31/03/2017
node 21:1/152

Thanks :)

--- Mystic BBS v1.12 A31 (Windows)
* Origin: Agency BBS | telnet://agency.bbs.geek.nz (21:1/101)