Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

Randomized Backstories

67 (25.9%)

Genetic Additions

98 (37.8%)

Mess Hall

50 (19.3%)

Revamped Area

44 (17%)

Total Members Voted: 257

[qwertyuiopas]

I put a comment into the main branch for future use if someone wants run-time map loading. It just explains the only change to an existing file nessecary to make it work correctly.

[Googolplexed]

As I've tried to say over PMs, the system doesn't completely work yet.
I would implement it, but it leaves the resultant station in an unplayable state

[Sukasa]

Okay guys, almost done the ESCAPE PODS update

[Evilgrim]

Rawr!
Ma I request a change log of sorts?
Please?
Or at least one that is kept up to date?

Please? :3
I volunteer to do it myself, as long as someone provides me with the information.
Or something?

Please?

[qwertyuiopas]

As I've tried to say over PMs, the system doesn't completely work yet.
I would implement it, but it leaves the resultant station in an unplayable state

I couldn't tell if you had fixed *a* problem, or *the* problem, or no problem at all, so just assumed that the lack of specifics about bugs meant that it was working fairly decently.

More importantly, it is faster to have the map loaded by BYOND anyway.

But did the map loading objects to redistribute rooms or semi-randomize the station part work? It is the more useful feature at the moment, and I didn't see issues with it yet, though haven't thouroughly tested it.

Edit: Tried it, and it had problems. However, I have an idea about how to fix that...

[x2yzh9]

Okay guys, almost done the ESCAPE PODS update

WUT? ESCAEP PODZ? YEY!

[qwertyuiopas]

(context: maploader)
Odd, it isn't working?

I'll continue to debug it. Besides, compiling gives me time to catch up on some backlogs of reading here...

[Googolplexed]

The major problems I found was that it had problems when it came to layers and random areas had no oxygen(I was getting spammed by pipe div/0 messages)

These will cause just as many problems loading small sections as they would the entire station

[qwertyuiopas]

Bug after bug, I've fought through, and yet more remain...

It was ignoring the last var setting because it didn't end in a semicolon, if an object couldn't /new properly, it(the proc, not the server) would crash trying to apply properties anyway.

Both of those are fixed, so it only makes 29 powernets, probably the normal ammount, rather than >5k, and it actually finishes.

Must get back to pipeline misconnections.

Oh, and the map itself had an error. the pipeline with a dir of 5's p_dir was 9, so although it looked fine in the editor, in-game it wouldn't connect properly, and the icon was set to what it actually was.

I suspect further similar map errors may actually be the remaining pipe bugs, but first I must check the map file itself, in case it is the loader messing up again.

I really should have debugged it more when I first wrote it

[Aryn]

Has it occurred to anyone else that the AI cannot possibly completely fulfill its laws, as it can only focus on one goal at a time? Therefore, if, say, a group of humans gave orders faster than it could carry out, or if more humans needed protecting than it could possibly protect, what happens?

[quinnr]

1. The AI can't. It is supposed to follow them to the best of its abilities.
2. Spawning a turret doesn't work.

[qwertyuiopas]

I found the (hopefully) last bug.

Unfortunately, it is the hardest to fix.

The problem is that, unlike the built-in map loading, peoperties are applied after the /New proc finishes, rather than before.

Most objects are built with mid-game spawning in consideration, so don't rely on altered defaults from the editor, but the pipes do.

This, I see, can be solved only one way, by making pipes more versatile so the point that they can be created mid-game just like cabling, and during that, take away or alter the parts that set variables in /New based on other vars.

Yes, it means that mappers need to have their pipes altered so that p_dir is set properly, but it is a required step for run-time creation in all forms, especially the player-created one.

In fact, maybe I should learn about creating branches, so that there can be a maploader/pipe-builder branch until everything is guarenteed to work correctly.

[head]

I found the (hopefully) last bug.

Unfortunately, it is the hardest to fix.

The problem is that, unlike the built-in map loading, peoperties are applied after the /New proc finishes, rather than before.

Most objects are built with mid-game spawning in consideration, so don't rely on altered defaults from the editor, but the pipes do.

This, I see, can be solved only one way, by making pipes more versatile so the point that they can be created mid-game just like cabling, and during that, take away or alter the parts that set variables in /New based on other vars.

Yes, it means that mappers need to have their pipes altered so that p_dir is set properly, but it is a required step for run-time creation in all forms, especially the player-created one.

In fact, maybe I should learn about creating branches, so that there can be a maploader/pipe-builder branch until everything is guarenteed to work correctly.

buildable pipes were on the list

[qwertyuiopas]

Well, the laziness of relying on /New to set p_dir or h_dir in the pipes and yet the map mostly having them set anyway is a huge mistake, and just correcting that should make things more consistant and one step further towards the goal(in-game pipe spawning)

The fact that it is a prerequisite to in-game map loading is irrelevant, except to me, because it's part of the reason I'm interested in getting it done

[Googolplexed]

Well branching is easy.

git branch "name of branch"
git checkout "name of branch"
<do commit work as normal>
git push "address" "name of branch"

And sukasa suggested calling New() a second time