search

aspace-sim / aspace

ASpace space simulator for the PennMUSH MU* Server
11 stars 6 forks source link

Ships cannot see each other #14

Closed pandasquee closed 3 years ago

pandasquee commented 3 years ago

Hi All,

I installed the stock db and everything seems fine except no ships can see each other. The two stock ships, Yarb and Mordak start in the stock db docked on deep space 11. and when i undock them, i get undock messages on the starbase, but when the ships undock they cannot see the sb or each other. Sensors are on, but i've also noticed that when i MAIN and AUX 100 on ships, the engines aren't producing power at all. Can anyone help?

pandasquee commented 3 years ago

Please see log: https://pastebin.com/9zanjqg7

mloftis commented 3 years ago

I didn't look terribly close but a few pointers (I did mention the softcode is rough) --- @space/makeship will not set the &SPACE attrib. The @space/load included requires an at least empty &CONSOLES attrib to load a ship into sdb on startup, without that you get Lots Of Weirdness because sdb is never told to fully read the object in. To fix the SPACE attrib in an already loaded SPACE-OBJECT th sdb(p,<SDB#),1,sp) to put the thing in space 1. Objects in different spaces don't see eachother, and can be "bugged" ... they can be docked to an object in a different space when created. @space/makeship in this one also I don't think is setting up correctly -- always assumes docked/landed/connected or somesuch (might be comign from the included specs) If it's a SPACE-OBJ w/o a CONSOLES attrib you're better off fixing the space-object attribs and then re-reading it using th sdb(r,

mloftis commented 3 years ago

Also dbl check the existing STARTUP's .... ISTR @space/load like behavior in two places (on #10 and #1?) -- and maybe one of them didn't have the hasattrp(...CONSOLES...)

mike347 commented 3 years ago

Not seeing each other and not producing power sounds like space code is not iterating. Make sure space iterate is called every second as the wiki instructions indicate (hardcode).

On Sat, Sep 11, 2021, 12:36 PM Michael Loftis @.***> wrote:

Also dbl check the existing STARTUP's .... ISTR @space/load like behavior in two places (on #10 https://github.com/aspace-sim/aspace/issues/10 and #1 https://github.com/aspace-sim/aspace/issues/1?) -- and maybe one of them didn't have the hasattrp(...CONSOLES...)

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/aspace-sim/aspace/issues/14#issuecomment-917435361, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACBDFHJFSY3HKXPTGKFXIHDUBOAPFANCNFSM5D3DIEDQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

mloftis commented 3 years ago

Not seeing each other and not producing power sounds like space code is not iterating. Make sure space iterate is called every second as the wiki instructions indicate (hardcode).

Hadn't thought that iterating wasn't working hah....you can check number of objects being iterated by (as wiz) th sdb(i) -- that'll give you count of active objects AND iterates them (once) if things unstick for one cycle with a th sdb(i) then your timer isn't firing....so you make sure the 1s timer is in local.c or you build a "space clock" object in SC that iterates it from SC (Thats how we used to do it :D) &SPACE #nn=0 isn't special AFAIR and "works". undocking, setting power, etc, will all work, just nothing happens because no iterate is happening....which with STARTUP shown on #10 there could. Which SPACE num you use as "the real world" is entirely up to you. We used to use one of the other SPACEs to pre-position anything we wanted to pop in/out. (for TPing say transwarp transits....I was thinking about setting up a let the players discover real transwarp and creating a network of TW gates where the exit was into "transwarp" space and there were the other gates relatively close together, in heavy nebula, so it wasn't 6+hrs of travel time...)

pandasquee commented 3 years ago

It is not iterating, when I used th sdb(e), everything ticked and worked for a second. I am still not sure where to look in the hardcode to fix that though.

pandasquee commented 3 years ago

My local.dst entry:

{

/* Register local_timer to be called once a second. You can also

(void) initSpace(); /*< ASpace Related / }

/* Add you own runtime configuration options here, and you can set

mloftis commented 3 years ago

Only enable the 1s or the 250ms. And aspace only needs/wants the 1s. And there's more than just one place you need to make edits. Just changing the #if isn't enough. Follow the wiki.

pandasquee commented 3 years ago

I made all of the changes to local.dst according to the wiki before i compiled pennmush. I just think that I might have put that in the wrong place or not configured it correctly.

mloftis commented 3 years ago

sdb(e) doesn't tick, it just finds what sdb considers the first available SDB (which may or may not be true, because you could have S-Os not loaded) ... sdb(i) does run do_space_db_iterate -- which if you've followed the instructions -- is in local_timer in local.dst -- local.c won't get overwritten/updated by building -- it's a copy from local.dst if it doesn't exist --

We already established earlier you weren't carefully following the wiki WRT local.dst changes, and had missed even adding initSpace initially. So go back to that, make SURE you've done everything...theres some stuff for dump/shutdown and the timer along with that initSpace. And the wiki...I'll make an edit to mention there's a couple #if 0's at least in 1.8.8...

mloftis commented 3 years ago

Having the timer running 5x/sec I won't directly hurt anything with ASpace...just not sure. It was built sort of assuming about 1s iterate calls, and only has a 1s resolution (it stores the last time an sdb was updated, and uses the delta between that time and now wherever it's making calculations-over-time like movement, main reactor coming up, etc)

But you really do not want to call it more often. You also don't want to unnecessarly increase the internal definition of the maximum number of space-objects, because it walks the whole thing every time it ticks, for active sdb's with a valid type it then does all the details. sdb(i) returns that count of active+valid type back to you after calling do_space_db_iterate. On modern hardware...eh...whatever number it has as default is probably conservative (remember this was all written when ~300Mhz was smoking fast)

pandasquee commented 3 years ago

I'm sorry I'm new and trying really hard to understand this. Thanks for the patience and help. I'll go back and make sure ive added everything. I am just not sure im adding things to the correct place. for example in

/

if 1 / Change to 1 if you need local_timer functionality. /

sq_register_loop(1, local_timer, NULL, NULL);

endif

if 1 / As above, but in milliseconds */

sq_register_loop_msec(250, local_timer, NULL, NULL);

endif

}

/* Add you own runtime configuration options here, and you can set

them in mush.cnf.
*/
void

where am I supposed to add (void) do_space_db_iterate(); /*< ASpace Related / also, if i change this file do i have to ./configure or make install before sh restart?

mloftis commented 3 years ago

It tells you which aspace functions go in existing callback functions in the wiki. https://github.com/aspace-sim/aspace/wiki/local.dst-changes -- ANY HardCode (C/pennmush) change requires a recompile (make install) and at least @shutdown/reboot. The Wiki really does assume you know how to do basic C development, and basic PennMUSH development (Which is why until just five minutes ago there were no details about the gotchas). ....

Lets take this out of issues, join me over on my discord? https://discord.gg/GbX6VRmX

pandasquee commented 3 years ago

Fixed with lots of handholding from @mloftis .