Comment 15 for bug 1226558

On Sat, Sep 28, 2013 at 3:53 AM, Stephen Lyons
<email address hidden>wrote:

> The thing about area 0 seems to be we don't seem to actually explicitly
> create it! Also the code to move rooms to an area does not seem to
> update the old area to take the room FROM it - we get away with this at
> mostly at the moment because I guess the typical usage is to create a
> room and then put it into the desired area and relatively rarely does
> rooms get moved to a new area.
>
>
Do you mean that the room gets left over in the old area? This doesn't seem
to be the case right now... which case do you speak of that would break it
here?

There have been a couple of people recently who started writing mapper
scripts and have been crashing Mudlet quite often - so I'm suspicious here.

> I'd suggest ensuring that an area 0 is created with new maps, and that
> during map auditing of existing ones, we add area 0 and all rooms with
> area = 0 to that area, also I'd be minded to check that each room only
> appears in the "rooms" of one area. If we increment the map version at
> this point the user will only be hit by these extra checks once per map
> file.
>
>
I think you're using area 0 in several concepts here. Otherwise "I'd
suggest ensuring that an area 0 is created with new maps, and that during
map auditing of existing ones, we add area 0 and all rooms with area = 0 to
that area [area 0]" doens't make sense. Do you mean rooms with an unset
area... ? But that doesn't fix the "we add area 0 to area 0" logical
peculiarity.

> In general adding a room should auto-magically place it in area 0. Also
> TArea.cpp need a removeRoom method which will be used both on room
> deletion and movement to a different area. Of course calls that add or
> delete rooms from an area should also cause an update to the min/maxs
> and the ebenes (levels?) for that area - which I am not sure is
> happening universally at the present.
>
>
That'd make sense.

> Right, I'm going to brew a fresh cup of coffee and take a look at trying
> to coding this unless someone else has a solution already worked out...
>
>
I'd be a wary here, we'd better get Heikos sign-off on this. He's never
documented his design in this so you wouldn't know what else might you
break without consulting him first (and breaking the design or going
against his philosophy is something that could happen, and result in wasted
effort).

> On 27/09/13 16:50, Chris wrote:
> > So I think the best solution is to nix the use of area 0, have -1 be a
> > void area, and enumeration begin at 1. This doesn't appear to break any
> > scripts, as using area 0 actually causes scripts to break. If perusing
> > the code supports this, I'll put in this fix.
> >
>
> --
> You received this bug notification because you are a member of Mudlet
> Makers, which is subscribed to Mudlet.
> https://bugs.launchpad.net/bugs/1226558
>
> Title:
> getRoom in TArea causes seg fault on map creation
>
> Status in Mudlet the MUD client:
> New
>
> Bug description:
> Creating a new map with this code on the latest development branch
> causes this backtrace:
>
> 0 TArea::fast_ausgaengeBestimmen TArea.cpp 168 0x5128bb
> 1 TMap::setExit TMap.cpp 304 0x5281ca
> 2 TLuaInterpreter::setExit TLuaInterpreter.cpp 6650
> 0x492075
> 3 ?? C:\mingw32\lib\lua51.dll 0x66d862e0
> 4 ?? C:\mingw32\lib\lua51.dll 0x66d8ffa6
> 5 ?? C:\mingw32\lib\lua51.dll 0x66d866e0
> 6 ?? C:\mingw32\lib\lua51.dll 0x66d81590
> 7 ?? C:\mingw32\lib\lua51.dll 0x66d85ad6
> 8 ?? C:\mingw32\lib\lua51.dll 0x66d86843
> 9 ?? C:\mingw32\lib\lua51.dll 0x66d82870
> 10 TLuaInterpreter::compile TLuaInterpreter.cpp 9649
> 0x49ce7a
> 11 TScript::compileScript TScript.cpp 150 0x4b04d7
> 12 TScript::setScript TScript.cpp 143 0x4b048e
> 13 dlgTriggerEditor::saveScript dlgTriggerEditor.cpp 4282
> 0x456ad9
> 14 dlgTriggerEditor::slot_saveScriptAfterEdit
> dlgTriggerEditor.cpp 4178 0x456799
> 15 dlgTriggerEditor::slot_save_edit dlgTriggerEditor.cpp
> 6932 0x46a642
> 16 dlgTriggerEditor::qt_static_metacall moc_dlgTriggerEditor.cpp
> 509 0x57ecd9
> 17 QMetaObject::activate qobject.cpp 3479 0x4c94cd0
> 18 QMetaObject::activate qobject.cpp 3354 0x4c94672
> 19 QAction::triggered moc_qaction.cpp 356 0x11674669
> 20 QAction::activate qaction.cpp 1175 0x11673c1e
> ... <More>
>
>
> code:
>
> -------------------------------------------------
> -- Put your Lua functions here. --
> -- --
> -- Note that you can also use external Scripts --
> -------------------------------------------------
> function makeMap()
> id = 0
> for i=0,100 do
> for j=0, 100 do
> addRoom(id)
> --setRoomArea(id,0) --uncomment this and remove below call
> to avoid seg faults
> setRoomName(id, tostring(id))
> setRoomCoordinates(id, i, j, 0)
> setExit(id-1,id,1)
> setExit(id,id-1,2)
> setRoomArea(id,0)
> id = id+1
> end
> end
> end
>
> function makeLabels()
> id=1
> for i=0,100 do
> for j=0, 100 do
> --display(id)
> x,y,z = getRoomCoordinates(id)
> createMapLabel(0,tostring(id),x,y,z,0,255,0,0,0,0)
> id = id+1
> end
> end
> end
>
> --makeMap()
> --makeLabels()
> centerview(1)
>
> uncomment makeMap and it crashes. It fails when id is 1 as well, so it
> isn't because of the i-1 setExit bit. It's caused by mpRoomDB not
> being initialized because there is no area created. Even post
> creation, the room needs to be assigned to an area first before any
> calls to mpRoomDB are called, else it will seg fault. It seems like we
> need some 'void' area that has no name and is just an abyss for rooms
> waiting to be allocated to avoid breaking scripts.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mudlet/+bug/1226558/+subscriptions
>
> _______________________________________________
> Mailing list: https://launchpad.net/~mudlet-makers
> Post to : <email address hidden>
> Unsubscribe : https://launchpad.net/~mudlet-makers
> More help : https://help.launchpad.net/ListHelp
>