News:

These forums are now archived - New member registrations are closed - Please join the discussion over on our Discord

Station Asteria Bugs [CLOSED]

Started by Martin Thompson, April 30, 2014, 04:43:36 AM

Previous topic - Next topic

Martin Thompson

Hey Guys,

In order to be ahead of the storm, if you experience any bugs with Station Asteria when its released today, please visit Griffins own forum and post the bugs there:

http://forums.griffinendurance.com/index.php in the bug report topic: http://forums.griffinendurance.com/viewtopic.php?f=7&t=3

He already mentioned himself that Asteria doesnt work with RPG-X Ultimate Edition as he didnt got it workign under 2.3:
http://forums.griffinendurance.com/viewtopic.php?f=9&t=4&start=10#p17


Serris

#1
Quote from: Martin Thompson on April 30, 2014, 04:43:36 AMHe already mentioned himself that Asteria doesnt work with RPG-X Ultimate Edition as he didnt got it workign under 2.3:
http://forums.griffinendurance.com/viewtopic.php?f=9&t=4&start=10#p17

This is the biggest thing everyone needs to take away from your post. Station Asteria is not compatible with our RPG-X Ultimate Edition or Standard Edition clients. It is not on our servers, nor will it be, unless Griffin or GSIO manage to hammer out a fix. The upcoming Station Leto release will be fully supported by RPG-X 2.3.

Martin Thompson

From Griffin:

QuoteIt seems to be a problem referring to the number of references or variables. As we move into 2.3 we start to see more functionality come in which has more declared variables such as the ship health system ect. These added variables designed to add functionality limit the number of custom variables and booleon's you can have on the map. The solution is simple, remove variables from the map which means entity removal. Unless they can locate and up this limit Asteria will never work in its current form past V2.2.

I was able to test this quite easily by removing the .usables and .locations scripts from the map folder. .usables contains a list of strings that get loaded into memory I assume when the map loads and that allow you to scan the func_usables and it displays the string. Remove this and the map might load. I assume that the health, turbolift and alert ect entities use some kind of global variables that are loaded regardless of whether or not the entities are present in the map. These variables are then set to nothing as the map doesn't have some of those entities for example but its still coming out of the stored variable limit. So the more functionality added in this fashion the smaller the var count for your map.

Now I cant confirm any of this as I don't have the source and have no idea how it works behind the scenes all I know is the behavior of the map and roughly how each feature would have been implemented. I am just drawing conclusions really but it seems to make sence.


John Adams

If anyone still wants the 2.2 instAller I can fnd it on the ftp but it wot be supported

SFC3

There's a reason I never got rid of 2.2!

Telex Ferra

#5
From Griffin's message, it sounds like we can deactivate scannable ents to make the map work.

That's what we did to stop parse back during beta testing for 2.1 and we could do it again.

EDIT: Also, since he says the ship health system takes up entities anyway, why not just fold his damage system into the ship health system so that it's not "double counted?"





Serris

Quote from: Telex Ferra on April 30, 2014, 08:12:01 AM
From Griffin's message, it sounds like we can deactivate scannable ents to make the map work.

That's what we did to stop parse back during beta testing for 2.1 and we could do it again.

EDIT: Also, since he says the ship health system takes up entities anyway, why not just fold his damage system into the ship health system so that it's not "double counted?"

That wouldn't really save entities, it would just change the variables from "0" to "x" amount. You're probably right about how disabling the scan entities will make the map load, but I wouldn't consider that a workable enough solution to throw that up on the server just yet. Even if we got it to load, there's no guarantee it wouldn't parse. Harry has posted on the forums, and GSIO will probably help to address the problem that's preventing Asteria from functioning. It'll just require a new rpgxEF engine iteration.

Martin Thompson

I'm sure Harry/GSIO/Griffin can hammer something out. I'll try to pitch in if possible there.


Martin Thompson

Note to everyone, be sure to post any significant bugs you find here: http://forums.griffinendurance.com/viewforum.php?f=7

Again, don't post anything regarding 2.3 as its already a known issue!